Kollect

Проекты, которые следуют приведенным ниже лучшим практикам, могут добровольно и самостоятельно оценить себя и продемонстрировать, что они получили значок Open Source Security Foundation (OpenSSF).

Не существует набора практик, гарантирующего, что у программного обеспечения никогда не будет недостатков или уязвимостей; даже формальные методы могут не помочь, если спецификации или допущения ошибочны. Также не существует какой-либо практики, которая могла бы гарантировать, что проект будет поддерживать здоровое и хорошо функционирующее сообщество разработчиков. Однако следующие хорошие правила могут помочь улучшить результаты проектов. Например, некоторые правила описывают ревью несколькими участниками перед выпуском, что может помочь найти технические уязвимости, которые было бы сложно найти другим способом, и помочь построить доверие и желание дальнейшего взаимодействия между разработчиками из разных компаний. Чтобы получить значок, нужно выполнить все критерии с ключевыми словами "НЕОБХОДИМО"/"ОБЯЗАН"/"НЕДОПУСТИМО", все критерии со словом "СЛЕДУЕТ" либо должны удовлетворяться, либо должно быть приведено обоснование их невыполнения, и все критерии со словом "ЖЕЛАТЕЛЬНО" могут быть удовлетворены ИЛИ неудовлетворены (желательно, чтобы они были хотя бы рассмотрены). Если вы хотите ввести общий комментарий вместо объяснения, почему текущая ситуация приемлема, начните текст с '//' и пробела. Приветствуется обратная связь через сайт на GitHub в виде issues или pull requests. Существует также список рассылки для общих вопросов.

Мы с удовольствием предоставляем информацию на нескольких языках, однако, если есть какой-либо конфликт или несоответствие между переводами, английская версия является авторитетной.
Если это ваш проект, пожалуйста, отобразите статус вашего базового значка на странице проекта! Статус базового значка выглядит так: Базовый уровень значка для проекта 13106 - in_progress Вот как встроить базовый значок:
Вы можете показать статус базового значка, вставив это в ваш файл markdown:
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/13106/baseline)](https://www.bestpractices.dev/projects/13106)
или вставив это в ваш HTML:
<a href="https://www.bestpractices.dev/projects/13106"><img src="https://www.bestpractices.dev/projects/13106/baseline"></a>


Это критерии Базового Уровня 3. Это критерии версии v2026.02.19.

Baseline Series: Базовый уровень 1 Базовый Уровень 2 Базовый Уровень 3

        

 Основы

  • Общая

    Обратите внимание, что другие проекты могут использовать то же имя.

    Kollect is a Kubernetes operator that turns selected live cluster state into a durable, queryable inventory. It watches resources by GVK, extracts attributes with CEL or JSONPath, aggregates them, and exports snapshots to pluggable sinks (Git, Postgres, Kafka/NATS, object stores). Inventory is declared as CRDs per team namespace, not custom code.

    Используйте формат выражения лицензии SPDX; примеры включают «Apache-2.0», «BSD-2-Clause», «BSD-3-Clause», «GPL-2.0+», «LGPL-3.0+», «MIT» и «(BSD-2-Clause OR Ruby)».
    Если используется более одного языка, перечислите их через запятую (пробелы необязательны), и отсортируйте их от наиболее до наименее используемого. Если список длинный, пожалуйста, перечислите по крайней мере три наиболее распространенных. Если языка нет (например, это проект только для документации или только для тестирования), используйте один символ «-» (минус). Для каждого языка используйте общепринятую капитализацию названия, например «JavaScript».
    Common Platform Enumeration (CPE) - это структурированная схема именования для информационных систем, программного обеспечения и пакетов. Она используется в ряде систем и баз данных для отчетов об уязвимостях.

    Pre-beta open-source project (MIT, v1alpha1 API). Primary artifact is the operator container image at ghcr.io/konih/kollect plus a Helm chart. Documentation at https://konih.github.io/kollect/. Security disclosures via SECURITY.md (private email, not public issues). Solo-maintainer OSS; vulnerability reports and dependency updates handled through Dependabot, govulncheck, and signed releases per ADR-0705.

 Элементы управления 19/21 ●

  • Элементы управления


    Достаточно для значка!

    Когда задаче назначаются разрешения в конвейере CI/CD, исходный код или конфигурация ДОЛЖНЫ назначать только минимальные привилегии, необходимые для соответствующей деятельности. [OSPS-AC-04.02]
    Настройте конвейеры CI/CD проекта так, чтобы по умолчанию назначать пользователям и службам наименьшие доступные разрешения, повышая разрешения только когда это необходимо для конкретных задач. В некоторых системах контроля версий это может быть возможно на уровне организации или репозитория. Если нет, установите разрешения на верхнем уровне конвейера.

    Workflows default to permissions: contents: read. Elevated permissions are scoped per job only where required (release job: contents: write, packages: write, id-token: write; docs deploy: pages: write). ADR-0705 documents the least-privilege model.


    Достаточно для значка!

    Конвейеры CI/CD, принимающие входные данные от доверенных коллабораторов, ДОЛЖНЫ санировать и проверять эти входные данные перед их использованием в конвейере. [OSPS-BR-01.04]
    Конвейеры CI/CD должны санировать (заключать в кавычки, экранировать или завершаться при ожидаемых значениях) все входные данные коллабораторов при явном выполнении рабочих процессов. Хотя коллабораторы в целом являются доверенными, ручные входные данные для рабочего процесса не могут быть проверены и могут быть использованы в злоумышленных целях при захвате учётной записи или угрозе изнутри.

    https://github.com/konih/kollect/blob/main/.github/workflows/release.yaml

    Trusted collaborator inputs are validated before use. Release workflow_dispatch tag input is checked against a semver regex. Checkout uses pinned SHAs and persist-credentials: false. No untrusted metadata is passed directly into privileged steps without validation.


    Достаточно для значка!

    Когда создается официальный релиз, все активы в этом релизе ДОЛЖНЫ быть четко связаны с идентификатором релиза или другим уникальным идентификатором для актива. [OSPS-BR-02.02]
    Назначьте уникальный идентификатор версии каждому программному активу, произведенному проектом, следуя единообразному соглашению об именовании или схеме нумерации. Примеры включают SemVer, CalVer или идентификатор git-коммита.

    Достаточно для значка!

    НЕОБХОДИМО, чтобы проект определил политику управления секретами и учетными данными, используемыми проектом. Политика должна включать руководства по хранению, доступу и ротации секретов и учетных данных. [OSPS-BR-07.02]
    Задокументируйте, как секреты и учетные данные управляются и используются в рамках проекта. Это должно включать подробную информацию о том, как хранятся секреты (например, с использованием инструмента управления секретами), как контролируется доступ, и как секреты ротируются или обновляются. Убедитесь, что конфиденциальная информация не встроена в исходный код и не хранится в системах контроля версий.

    https://github.com/konih/kollect/blob/main/docs/adr/0104-security-model.md https://github.com/konih/kollect/blob/main/GUIDELINES.md https://github.com/konih/kollect/blob/main/SECURITY.md

    Secret policy is documented across ADR-0104 and GUIDELINES: credentials only via Kubernetes secretRef, never in CR specs, status, logs, or events; resolved via BuildContext at reconcile time. SECURITY.md covers scanning for accidental commits (gitleaks) and supply-chain handling. Rotation is operational (update the Kubernetes Secret and re-run connection tests) rather than a formal calendar schedule.


    Достаточно для значка!

    Когда проект выпустил релиз, документация проекта ДОЛЖНА содержать инструкции по проверке целостности и подлинности активов релиза. [OSPS-DO-03.01]
    Инструкции в проекте должны содержать информацию об используемой технологии, командах для выполнения и ожидаемом выводе. По возможности избегайте хранения этой документации в том же месте, что и конвейер сборки и выпуска, чтобы избежать компрометации как программного обеспечения, так и документации для проверки целостности программного обеспечения в случае единичного нарушения безопасности.

    https://github.com/konih/kollect/blob/main/docs/RELEASE.md https://github.com/konih/kollect/blob/main/.github/release-notes-install.md

    Release documentation includes cosign verify commands, sha256sum -c checksums.txt, Sigstore bundle verification, and gh attestation verify for images and GitHub Release assets.


    Достаточно для значка!

    Когда проект выпустил релиз, документация проекта ДОЛЖНА содержать инструкции по проверке ожидаемой личности человека или процесса, создающего программный релиз. [OSPS-DO-03.02]
    Ожидаемая личность может быть в форме идентификаторов ключей, используемых для подписи, эмитента и личности из сертификата sigstore или других подобных форм. По возможности избегайте хранения этой документации в том же месте, что и конвейер сборки и выпуска, чтобы избежать компрометации как программного обеспечения, так и документации для проверки целостности программного обеспечения в случае единичного нарушения безопасности.

    https://github.com/konih/kollect/blob/main/docs/RELEASE.md

    Verification instructions use cosign with --certificate-oidc-issuer https://token.actions.githubusercontent.com and --certificate-identity-regexp '^https://github.com/konih/kollect/.+' to confirm releases were signed by the project's GitHub Actions workflow identity.


    Достаточно для значка!

    Когда проект выпустил релиз, документация проекта ДОЛЖНА включать описательное заявление о масштабе и сроках поддержки для каждого релиза. [OSPS-DO-04.01]
    Для информирования о масштабе и сроках поддержки выпущенных программных активов проекта, проект должен иметь файл SUPPORT.md, раздел "Поддержка" в SECURITY.md или другую документацию, объясняющую жизненный цикл поддержки, включая ожидаемую продолжительность поддержки для каждого релиза, типы предоставляемой поддержки (например, исправления ошибок, обновления безопасности) и любые соответствующие политики или процедуры получения поддержки.

    https://github.com/konih/kollect/blob/main/SECURITY.md

    SECURITY.md defines supported versions: main and the latest tagged release only. README notes pre-beta status. This is a minimal support statement; expand if you want clearer LTS language.


    Достаточно для значка!

    Когда проект выпустил релиз, документация проекта ДОЛЖНА предоставлять описательное заявление о том, когда релизы или версии больше не будут получать обновления безопасности. [OSPS-DO-05.01]
    Для информирования о масштабе и сроках поддержки исправлений безопасности, проект должен иметь SUPPORT.md или другую документацию, объясняющую политику проекта в отношении обновлений безопасности.

    https://github.com/konih/kollect/blob/main/SECURITY.md

    SECURITY.md states that only the latest release tag receives security support; older tags are unsupported. No separate EOL calendar exists yet, but the policy is explicit.


    Недостаточно для значка.

    Пока проект активен, документация проекта ДОЛЖНА содержать политику, согласно которой участники кода проверяются перед предоставлением повышенных разрешений на доступ к критическим ресурсам. [OSPS-GV-04.01]
    Опубликуйте исполняемую политику в документации проекта, которая требует, чтобы участники кода были проверены и одобрены до предоставления повышенных разрешений на доступ к критическим ресурсам, таким как одобрение слияния или доступ к секретам. Рекомендуется, чтобы проверка включала установление обоснованной линии идентичности, такой как подтверждение связи участника с известной доверенной организацией.

    https://github.com/konih/kollect/blob/main/docs/adr/0705-release-supply-chain.md

    There is no documented policy requiring human review before granting escalated repository permissions to new collaborators. ADR-0705 explicitly defers multi-person review gates for the solo-maintainer workflow. To meet this: add a short policy in CONTRIBUTING.md or SECURITY.md covering collaborator onboarding and permission escalation.


    Достаточно для значка!

    Когда проект выпустил релиз, все скомпилированные выпущенные программные активы ДОЛЖНЫ поставляться со списком компонентов программного обеспечения (Software Bill of Materials). [OSPS-QA-02.02]
    Рекомендуется автоматически генерировать SBOM во время сборки с использованием инструмента, который был проверен на точность. Это позволяет пользователям получать эти данные стандартизированным способом наряду с другими проектами в их среде.

    https://github.com/konih/kollect/releases https://github.com/konih/kollect/blob/main/.github/workflows/release.yaml

    Each GitHub Release publishes sbom.spdx.json and sbom-ui.spdx.json. OCI images on GHCR also carry SPDX SBOM attestations via actions/attest.


    Достаточно для значка!

    Когда проект выпустил релиз, состоящий из нескольких репозиториев исходного кода, все подпроекты ДОЛЖНЫ применять требования безопасности, которые являются столь же строгими или более строгими, чем первичная кодовая база. [OSPS-QA-04.02]
    Любые дополнительные репозитории кода подпроектов, созданные проектом и скомпилированные в релиз, должны применять требования безопасности в соответствии со статусом и целями соответствующей кодовой базы. В дополнение к следованию соответствующим требованиям OSPS Baseline, это может включать требование проверки безопасности, обеспечение отсутствия уязвимостей и обеспечение отсутствия известных проблем безопасности.

    The released software is built from a single authoritative repository (konih/kollect). No multi-repo release comprising subprojects with separate codebases.


    Достаточно для значка!

    Пока проект активен, документация проекта ДОЛЖНА четко документировать, когда и как выполняются тесты. [OSPS-QA-06.02]
    Добавьте раздел в документацию по участию в проекте, объясняющий, как запускать тесты локально и как запускать тесты в конвейере CI/CD. Документация должна объяснять, что тестируют тесты и как интерпретировать результаты.

    https://github.com/konih/kollect/blob/main/docs/development/testing.md https://github.com/konih/kollect/blob/main/CONTRIBUTING.md https://github.com/konih/kollect/blob/main/.github/workflows/ci.yaml

    The test suite is MIT-licensed FLOSS in the same repository. CONTRIBUTING.md and testing.md document how to run task test, task coverage, task test-integration, and task test:e2e. GitHub Actions CI runs these gates on every push and pull request. [test]


    Достаточно для значка!

    Пока проект активен, документация проекта ДОЛЖНА включать политику, согласно которой все значительные изменения программного обеспечения, производимого проектом, должны добавлять или обновлять тесты функциональности в автоматизированном наборе тестов. [OSPS-QA-06.03]
    Добавьте раздел в документацию по участию в проекте, объясняющий политику добавления или обновления тестов. Политика должна объяснять, что представляет собой значительное изменение и какие тесты должны быть добавлены или обновлены.

    ttps://github.com/konih/kollect/blob/main/CONTRIBUTING.md https://github.com/konih/kollect/blob/main/docs/development/testing.md

    CONTRIBUTING.md maps contributors to the testing strategy document and lists task coverage in the PR preflight checklist. testing.md documents which test tier blocks merge for each change type, including the rule that new sink backends must reach L3 before merge. [tests_documented_added]


    Недостаточно для значка.

    Когда совершается коммит в основную ветку, система контроля версий проекта ДОЛЖНА требовать как минимум одного одобрения изменений человеком, не являющимся автором, перед слиянием. [OSPS-QA-07.01]
    Настройте систему контроля версий проекта так, чтобы она требовала как минимум одного одобрения изменений человеком, не являющимся автором, перед слиянием в релизную или основную ветку. Это можно достичь, требуя, чтобы запрос на включение изменений был рассмотрен и одобрен как минимум одним другим участником, прежде чем его можно будет объединить.

    https://github.com/konih/kollect/blob/main/docs/adr/0705-release-supply-chain.md

    Branch protection does not require pull-request reviews (required_pull_request_reviews: null). The sole maintainer can push directly to main (enforce_admins: false). ADR-0705 documents this as an intentional solo-maintainer deferral. CI gates substitute for human review but do not satisfy this specific control.


    Достаточно для значка!

    Когда проект выпустил релиз, проект ДОЛЖЕН выполнить моделирование угроз и анализ поверхности атаки для понимания и защиты от атак на критические пути кода, функции и взаимодействия внутри системы. [OSPS-SA-03.02]
    Моделирование угроз - это деятельность, при которой проект рассматривает кодовую базу, связанные процессы и инфраструктуру, интерфейсы, ключевые компоненты и "думает как хакер", проводя мозговой штурм о том, как система может быть взломана или скомпрометирована. Каждая выявленная угроза перечисляется, чтобы проект мог затем подумать о том, как проактивно избежать или закрыть любые бреши/уязвимости, которые могут возникнуть. Убедитесь, что это обновляется для новых функций или критических изменений.

    https://github.com/konih/kollect/blob/main/docs/adr/0104-security-model.md https://github.com/konih/kollect/blob/main/docs/ARCHITECTURE.md

    ADR-0104 consolidates the threat model (secret leakage, MITM, RBAC escalation, over-broad access) and mitigations across critical paths. ARCHITECTURE.md documents reconciliation, sink export, and multi-tenant boundaries. This is project-level analysis, not a per-release checklist; no formal "threat model updated at each release" process exists.


    Достаточно для значка!

    Пока активен, любые уязвимости в программных компонентах, не затрагивающие проект, ДОЛЖНЫ быть учтены в документе VEX, дополняющем отчет об уязвимостях деталями о неэксплуатируемости. [OSPS-VM-04.02]
    Создайте поток VEX, сообщающий о статусе эксплуатируемости известных уязвимостей, включая детали оценки или любые меры по смягчению, препятствующие выполнению уязвимого кода.

    https://github.com/konih/kollect/blob/main/docs/adr/0104-security-model.md https://github.com/konih/kollect/blob/main/docs/ARCHITECTURE.md

    ADR-0104 consolidates the threat model (secret leakage, MITM, RBAC escalation, over-broad access) and mitigations across critical paths. ARCHITECTURE.md documents reconciliation, sink export, and multi-tenant boundaries. This is project-level analysis, not a per-release checklist; no formal "threat model updated at each release" process exists.


    Достаточно для значка!

    Пока активна, документация проекта ДОЛЖНА включать политику, определяющую порог для устранения результатов SCA, связанных с уязвимостями и лицензиями. [OSPS-VM-05.01]
    Задокументируйте в проекте политику, определяющую порог для устранения результатов SCA, связанных с уязвимостями и лицензиями. Включите процесс выявления, приоритизации и устранения этих результатов.

    https://github.com/konih/kollect/blob/main/docs/security/sca-remediation-policy.md https://github.com/konih/kollect/blob/main/SECURITY.md

    The project publishes a dedicated SCA remediation policy that defines thresholds for both vulnerabilities and licenses. Vulnerability SLAs: Critical 7 days, High 30 days, Medium 90 days, Low by next minor release, plus zero-tolerance gates for reachable CVEs (govulncheck) and fixable CRITICAL/HIGH in release images (Trivy). License classes: Allow, Review (90 days to confirm), Deny (remove before merge or within 30 days). SECURITY.md links to this policy under “Dependency and license policy (SCA)”.


    Достаточно для значка!

    Пока активна, документация проекта ДОЛЖНА включать политику для устранения нарушений SCA до любого релиза. [OSPS-VM-05.02]
    Задокументируйте в проекте политику для устранения применимых результатов анализа состава программного обеспечения перед любым релизом и добавьте проверки статуса, которые подтверждают соответствие этой политике перед релизом.

    https://github.com/konih/kollect/blob/main/docs/adr/0705-release-supply-chain.md https://github.com/konih/kollect/blob/main/.github/workflows/release.yaml

    Trivy scans release images and fails the release workflow on fixable CRITICAL/HIGH findings. Merges to main (from which releases are tagged) require green preflight and test CI jobs including govulnchec


    Достаточно для значка!

    Пока активны, все изменения в кодовой базе проекта ДОЛЖНЫ автоматически оцениваться на соответствие задокументированной политике по вредоносным зависимостям и известным уязвимостям в зависимостях, а затем блокироваться в случае нарушений, за исключением случаев, когда они объявлены и подавлены как неэксплуатируемые. [OSPS-VM-05.03]
    Создайте проверку статуса в системе контроля версий проекта, которая запускает инструмент анализа состава программного обеспечения для всех изменений в кодовой базе. Требуйте, чтобы проверка статуса проходила успешно, прежде чем изменения могут быть объединены.

    https://github.com/konih/kollect/blob/main/.github/workflows/ci.yaml https://github.com/konih/kollect/blob/main/SECURITY.md

    Every push and PR runs govulncheck (task vulncheck), which blocks merge on failure. Dependabot security updates generate automated patch PRs. Documented suppression path for confirmed non-exploitable findings is inline in SECURITY.md (not VEX-formatted).


    Достаточно для значка!

    Пока активна, документация проекта ДОЛЖНА включать политику, определяющую порог для устранения результатов SAST. [OSPS-VM-06.01]
    Задокументируйте в проекте политику, определяющую порог для устранения результатов статического тестирования безопасности приложений (SAST). Включите процесс выявления, приоритизации и устранения этих результатов.

    https://github.com/konih/kollect/blob/main/CONTRIBUTING.md https://github.com/konih/kollect/blob/main/.github/workflows/ci.yaml

    The lint job fails CI on any golangci-lint finding; main is protected and requires green preflight and test checks before merge. CodeQL results appear under GitHub Security → Code scanning and are triaged before release. No open medium-or-higher static-analysis findings are outstanding. [static_analysis_fixed]


    Достаточно для значка!

    Пока активны, все изменения в кодовой базе проекта ДОЛЖНЫ автоматически оцениваться на соответствие задокументированной политике по слабым местам безопасности и блокироваться в случае нарушений, за исключением случаев, когда они объявлены и подавлены как неэксплуатируемые. [OSPS-VM-06.02]
    Создайте проверку статуса в системе контроля версий проекта, которая запускает инструмент статического тестирования безопасности приложений (SAST) для всех изменений в кодовой базе. Требуйте, чтобы проверка статуса проходила успешно, прежде чем изменения могут быть объединены.

    https://github.com/konih/kollect/blob/main/.github/workflows/ci.yaml https://github.com/konih/kollect/blob/main/.github/workflows/codeql.yaml https://github.com/konih/kollect/blob/main/SECURITY.md

    Releases are tagged from main after required CI passes. Every push and PR runs golangci-lint v2 (task lint) including gosec, staticcheck, govet, and errcheck. CodeQL analyzes Go on every push/PR to main and weekly. Release images are scanned with Trivy before publish. All tools are FLOSS. [static_analysis]



Эти данные доступны по лицензии Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Это означает, что получатель данных может распространять данные с изменениями или без них, при условии, что получатель данных предоставляет текст данного соглашения вместе с распространяемыми данными. Пожалуйста, укажите в качестве источника Konrad Heimel и участников OpenSSF Best Practices badge.

Владелец анкеты на значок проекта: Konrad Heimel.
2026-06-05 19:46:16 UTC, последнее изменение сделано 2026-06-05 21:03:36 UTC. Последний раз условия для получения значка были выполнены 2026-06-05 20:55:11 UTC.