compose-lint

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

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

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


Это критерии уровня Silver. Вы также можете просмотреть критерии уровня Passing или Gold.

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

        

 Основы 17/17

  • Общая

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

    compose-lint is a security-focused linter for Docker Compose files. It catches dangerous misconfigurations — exposed Docker sockets, privileged containers, missing capability restrictions, unpinned images, and more — before they reach production. Rules are grounded in the OWASP Docker Security Cheat Sheet and CIS Docker Benchmark, with every finding including specific, actionable fix guidance. Distributed on PyPI and Docker Hub; runs locally, in CI, or as a pre-commit hook.

    Используйте формат выражения лицензии 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) - это структурированная схема именования для информационных систем, программного обеспечения и пакетов. Она используется в ряде систем и баз данных для отчетов об уязвимостях.

    Single-maintainer project, intentionally narrow in scope: a security linter for Docker Compose files with PyYAML as the only runtime dependency. Supply-chain posture above typical: PyPI Trusted Publishing (OIDC, no long-lived tokens), Sigstore build attestations on every release, signed commits and tags (SSH), SHA-pinned GitHub Actions, hash-pinned CI lockfiles, and a merge-blocking ci-ok aggregate check. Continuous scanning via CodeQL, OpenSSF Scorecard, and ClusterFuzzLite. All changes flow through PRs with squash-merge and linear history on main. No cryptography is implemented; no binary artifacts are tracked.

  • Предварительные требования


    Проект ОБЯЗАН получить значок уровня Passing. [achieve_passing]

  • Основная информация на веб-сайте проекта


    В информацию о том, как внести вклад, НЕОБХОДИМО включить требования к приемлемым взносам (например, ссылку на любой требуемый стандарт кодирования). (Требуется URL) [contribution_requirements]
  • Надзор за проектом


    Проекту СЛЕДУЕТ иметь юридический механизм, через который все авторы содержательных взносов в ПО проекта подтверждают, что они имеют законное право на внесение этих взносов. Самый распространенный и легко реализуемый подход для этого заключается в использовании Developer Certificate of Origin (DCO), при котором пользователи добавляют строку "signed-off-by" в свои коммиты, а проект ссылается на веб-сайт DCO. Но этот механизм МОЖЕТ быть реализован и в качестве Лицензионного соглашения с участниками (Contributor License Agreement, CLA) или другого правового механизма. (Требуется URL) [dco]
    DCO является рекомендуемым механизмом, потому что его легко реализовать и отслеживать в исходном коде, а git напрямую поддерживает функцию "signed-off" при помощи "commit -s". Для большей эффективности лучше всего, если проектная документация объясняет, что означает "signed-off" для этого проекта. CLA - это юридическое соглашение, которое определяет условия, на которых произведения умственного труда были лицензированы для организации или проекта. Соглашение о назначении участника (contributor assignment agreement, CAA) является юридическим соглашением, которое передает права на произведения умственного труда другой стороне; проекты не обязаны иметь CAA, поскольку CAA увеличивает риск того, что потенциальные участники не будут вносить свой вклад, особенно если получатель является коммерческой организацией. Лицензии CLA от Apache Software Foundation (лицензия отдельного участника и корпоративное соглашение CLA) являются примерами CLA для проектов, считающих, что риски от такого рода CLA для проекта меньше, чем их преимущества.

    All non-bot commits must carry a Signed-off-by: trailer matching the commit author identity, certifying the Developer Certificate of Origin (https://developercertificate.org). A required CI job (Developer Certificate of Origin in .github/workflows/ci.yml) scans every commit in a PR and blocks merge if any non-bot commit lacks the trailer. Dependabot, Renovate, github-actions, and Mend bot commits are allow-listed. Policy documented in CONTRIBUTING.md: https://github.com/tmatens/compose-lint/blob/main/CONTRIBUTING.md#developer-certificate-of-origin [osps_le_01_01]



    Проект ОБЯЗАН четко определить и задокументировать модель управления проектом (способ принятия решений, включая ключевые роли). (Требуется URL) [governance]
    Требуется устоявшийся задокументированный способ принятия решений и разрешения споров. В небольших проектах это может быть просто вплоть до «владелец и лидер проекта принимает все окончательные решения». Существуют различные модели управления, включая благосклонное диктаторство и формальную меритократию; более подробно см. Governance models. В проектах успешно используются как централизованные подходы (например, с одним ведущим), так и децентрализованные (например, с групповыми ведущими). Не нужно указывать в сведениях об управлении возможность форка проекта, поскольку это всегда возможно для проектов СПО.

    URL: https://github.com/tmatens/compose-lint/blob/main/GOVERNANCE.md

    Justification: GOVERNANCE.md at the repo root documents the project's decision-making model end-to-end: a single maintainer role (with the bus factor honestly stated as 1), lazy-consensus decision rule with explicit reasonable-window guidance per change class, branch-protection rule that no change reaches main outside a PR (including the maintainer's), procedure for adding and removing maintainers, appeal procedure, and code-of-conduct enforcement chain. Cross-links to MAINTAINERS.md (canonical roster) and docs/CONTINUITY.md (access continuity).



    Проект ОБЯЗАН определить правила поведения и разместить эти правила в стандартном месте. (Требуется URL) [code_of_conduct]
    Проекты могут повысить цивилизованность их сообщества и установить ожидания относительно приемлемого поведения, приняв правила поведения. Это может помочь избежать проблем до их возникновения и сделать проект более привлекательным местом, поощряющим участие. Правила должны быть сосредоточены только на поведении в сообществе или на рабочем месте проекта. Примерами правил поведения являются правила конфликтов на проекте ядра Linux, Contributor Covenant Code of Conduct, Кодекс поведения Debian, Ubuntu Code of Conduct, Правила поведения проекта Fedora, GNOME Code Of Conduct, KDE Community Code of Conduct">, Python Community Code of Conduct, The Ruby Community Conduct Guideline и The Rust Code of Conduct.

    URL: https://github.com/tmatens/compose-lint/blob/main/.github/CODE_OF_CONDUCT.md

    Justification: The project adopts the Contributor Covenant v2.1, posted at the standard .github/CODE_OF_CONDUCT.md location that GitHub recognizes for the "Community Standards" panel. CONTRIBUTING.md links to it from the §"Maintainers" section.



    Проект ОБЯЗАН четко определять и публично документировать ключевые роли в проекте и их обязанности, включая любые задачи, которые должны выполнять эти роли. Должно быть ясно, кто имеет какую роль(и), хотя это может быть и не задокументировано соответствующим образом. (Требуется URL) [roles_responsibilities]
    Документация для управления , а также роли и обязанности могут быть в одном месте.

    CONTRIBUTING.md "Maintainers" section lists the single project maintainer (@tmatens) with repository admin, release, and security-response responsibilities. See https://github.com/tmatens/compose-lint/blob/main/CONTRIBUTING.md#maintainers [osps_gv_01_02]



    Проект ОБЯЗАН быть в состоянии продолжать работу с минимальным прерыванием, если какой-либо человек окажется недееспособен или убит. В частности, проект ОБЯЗАН быть в состоянии создавать и закрывать вопросы в трекере, принимать предложенные изменения и выпускать версии программного обеспечения через неделю после подтверждения того, что данный человек недееспособен или убит. Это МОЖЕТ быть реализовано через обеспечение кого-то ещё необходимыми ключами, паролами и законными правами для продолжения проекта. Лица, которые запускают проект СПО, МОГУТ сделать это, оставив ключи в сейфе и завещание, передающее все необходимые юридические права (например, для имен DNS). (Требуется URL) [access_continuity]

    URL: https://github.com/tmatens/compose-lint/blob/main/docs/CONTINUITY.md

    Justification: docs/CONTINUITY.md explicitly addresses the single-maintainer reality. The "short version" states that anyone can continue compose-lint by forking under the MIT license: hash-pinned requirements*.lock files, digest-pinned Docker base images, signed annotated tags, and the documented release process in docs/RELEASING.md are deliberately structured so a successor needs no private state from the original maintainer. The document then gives a per-asset access table (GitHub repo and Environments, PyPI Trusted Publisher binding, Docker Hub org composelint, repo secrets, signing keys) with recovery paths for each, plus a co-maintainer onboarding checklist and an honest "why bus factor is currently 1" section.



    Проекту СЛЕДУЕТ поддерживать «коэффициент автобуса» 2 или более. (Требуется URL) [bus_factor]
    «Коэффициент автобуса» (или «коэффициент грузовика») - это минимальное количество участников проекта, которые должны внезапно исчезнуть из проекта («попасть под автобус»), чтобы проект заглох из-за отсутствия квалифицированного или компетентного персонала. Инструмент truck-factor может оценить это для проектов на GitHub. Для получения дополнительной информации см. статью Cosentino et al. Assessing the Bus Factor of Git Repositories.

    URL: https://github.com/tmatens/compose-lint/blob/main/docs/CONTINUITY.md

    Justification: Bus factor is 1. Acknowledged honestly in GOVERNANCE.md §Roles ("The bus factor is 1; we are honest about that."). Mitigated in docs/CONTINUITY.md, which documents reproducible-build provenance (hash-pinned lockfiles, digest-pinned base images, Sigstore attestations on every release), the fork path under the MIT license, and per-asset recovery procedures (GitHub repo and Environments, PyPI Trusted Publisher binding, Docker Hub org, signing keys) so the project can continue without the current maintainer's cooperation. The procedure to add a co-maintainer is defined in GOVERNANCE.md §"Adding a maintainer" and MAINTAINERS.md §"Adding or removing a maintainer".


  • Документация


    Проект ОБЯЗАН иметь задокументированный долгосрочный план (roadmap), описывающий, что проект намеревается, а что не намеревается делать, по крайней мере на ближайший год. (Требуется URL) [documentation_roadmap]
    Проект может не достичь того, что описано в долгосрочном плане, и это нормально. Цель дорожной карты - помочь потенциальным пользователям и участникам понять намеченное направление проекта. Подробности не требуются.

    URL: https://github.com/tmatens/compose-lint/blob/main/docs/ROADMAP.md

    Justification: docs/ROADMAP.md lays out milestones 1 (shipped v0.3) through 4 (v1.0 GA) with explicit deferred items (.deb/.rpm packages, see ADR-008) and gating prerequisites (e.g., the drift-check job that must land before the real-world examples library). Milestone 2.5 (Trust Surface + Install Polish) and Milestone 3 (Remediation: --fix UX) define the next twelve-plus months of intended work; the document also names what is explicitly out of scope and why, which is the harder half of a roadmap.



    Проект ОБЯЗАН включать документацию по архитектуре (также называемой высокоуровневым дизайном) ПО, создаваемого проектом. Выберите «неприменимо» (N/A), если проект не создает программное обеспечение. (Требуется URL) [documentation_architecture]
    Архитектура ПО объясняет фундаментальную структуру программы, то есть основные компоненты программы, отношения между ними и ключевые свойства этих компонентов и отношений.

    Architecture is documented in CLAUDE.md (Parser, Rules, Findings, Formatters, Engine components and their data flow) and supplemented by Architecture Decision Records in docs/adr/. Actors: end users running the CLI, rule authors, CI systems consuming SARIF. Actions: compose file loading, rule evaluation, finding emission, formatter selection. See https://github.com/tmatens/compose-lint/blob/main/CLAUDE.md#architecture [osps_sa_01_01]



    Проект ОБЯЗАН документировать то, что пользователь может и чего он не должен ожидать с точки зрения безопасности от ПО, создаваемого проектом (его «требования безопасности»). (Требуется URL) [documentation_security]
    Это требования безопасности, выполнение которых ожидается от ПО.

    URL:https://github.com/tmatens/compose-lint/blob/main/docs/SECURITY-EXPECTATIONS.md
    docs/SECURITY-EXPECTATIONS.md (137 lines) is the user-facing "what compose-lint will and will not do" document:

    Promises: no execution of YAML contents (SafeLoader only, no eval/exec/subprocess against parsed values); no network I/O (verifiable under --network none); no mutation of inputs (read-only).
    Non-promises: not a Compose schema validator; not a runtime/image scanner; not exhaustive (rules cover known patterns from OWASP/CIS/Docker docs).
    How to verify each claim (concrete commands).
    .github/SECURITY.md header now links to docs/ASSURANCE.md and docs/SECURITY-EXPECTATIONS.md. The trio of SECURITY.md (vuln-reporting policy) + ASSURANCE.md (formal assurance case) + SECURITY-EXPECTATIONS.md (user-facing promises) covers the criterion comprehensively.



    Проект ОБЯЗАН предоставить руководство для быстрого начала работы для новых пользователей, чтобы помочь им быстро что-то сделать, используя ПО, создаваемое проект. (Требуется URL) [documentation_quick_start]
    Идея состоит в том, чтобы показать пользователям, как начать работу и и добиться, чтобы ПО что-то вообще сделало. Потенциальным пользователям это критически важно для начала работы.

    URL: https://github.com/tmatens/compose-lint/blob/main/docs/SECURITY-EXPECTATIONS.md

    Justification: docs/SECURITY-EXPECTATIONS.md is the user-facing "what compose-lint will and will not do in security terms" document. It enumerates explicit promises (will not execute YAML contents — SafeLoader only, no eval/exec/subprocess against parsed values; will not connect to the network — verifiable under --network none; will not modify your Compose files — read-only) and explicit non-promises (not a Compose schema validator, not an image/runtime scanner, not exhaustive — rules cover known patterns from OWASP/CIS/Docker docs), with concrete commands to verify each claim. The trio of .github/SECURITY.md (vuln-reporting policy) + docs/ASSURANCE.md (formal assurance case) + docs/SECURITY-EXPECTATIONS.md (user-facing promises) is cross-linked from the SECURITY.md header.



    Проект ОБЯЗАН прилагать усилия к тому, чтобы документация соответствовала текущей версии результатов проекта (включая ПО, создаваемое проектом). НЕОБХОДИМО исправлять любые известные дефекты документации, приводящие к ее непоследовательности. Если документация в целом актуальна, но ошибочно включает в себя некоторые более старые данные, которые больше не верны, просто рассматривайте это как дефект, отслеживайте и исправляйте, как обычно. [documentation_current]
    Документация МОЖЕТ включать информацию о различиях или изменениях между версиями программного обеспечения и/или ссылку на более старые версии документации. Смысл этого критерия заключается в том, что прилагаются усилия для обеспечения согласованности документации, а не в том, чтобы документация была идеальной.

    URL: https://github.com/tmatens/compose-lint/blob/main/.github/workflows/ci.yml

    Justification: Documentation currency is enforced by CI rather than by convention. The version-consistency job in ci.yml asserts that pyproject.toml and src/compose_lint/init.py declare the same version. The changelog-gate job asserts that CHANGELOG.md has a section for the version being released. docs/RELEASING.md lists every documentation surface (README copy-paste pins, action SHA pins, marketplace pin, CHANGELOG) that must move with a release; recent merge history (commits 4473fd3, 447c416, 23da963) shows those pins bumped in lockstep with each release.



    НЕОБХОДИМО размещать ссылку на любые свои достижения, включая этот значок передовой практики, на главной странице проекта и/или веб-сайте в течение 48 часов после открытого признания достижения. (Требуется URL) [documentation_achievements]
    Достижением считается любой набор внешних критериев, над выполнением которых проект специально работал, включая некоторые значки. Эта информация не обязательно должна находиться на главной странице веб-сайта проекта. Проект с использованием GitHub может помещать достижения на главную страницу хранилища кода, добавляя их в файл README.

    URL: https://github.com/tmatens/compose-lint#compose-lint

    Justification: The README header carries badges that hyperlink to every active achievement: CI status, PyPI version, Docker Hub presence, supported Python versions, MIT license, OpenSSF Scorecard, OpenSSF Best Practices Baseline level 2, and the OpenSSF Best Practices badge for this project (12472). Each badge links to the source of truth (the corresponding GitHub Actions workflow, the PyPI page, the Scorecard viewer, or the bestpractices.dev project page).


  • Общедоступность и интернационализация


    Проекту (как на сайтах проекта, так и в результатах работы проекта) СЛЕДУЕТ придерживаться передовой практики общедоступности, чтобы люди с ограниченными возможностями могли участвовать в проекте и использовать результаты проекта, где это имеет смысл. [accessibility_best_practices]
    Для веб-приложений см. Руководство по обеспечению доступности веб-контента (WCAG) 2.0 и его поддерживающий документ Understanding WCAG 2.0; см. также W3C accessibility information. Для приложений с графическим интерфейсом рассмотрите использование соответствующих вашему окружению рекомендаций по обеспечению доступности (таких как GNOME, KDE, XFCE, Android, iOS, Mac и Windows (на русском)). Некоторые приложения с текстовым интерфейсом пользователя (например, программы на ncurses) могут сделать некоторые вещи, чтобы сделать себя более доступными (например, параметр `force-arrow-cursor` в `alpine`). Большинство приложений командной строки довольно общедоступны как они есть. Этот критерий часто неприменим, например, для библиотек программ. Вот несколько примеров действий или проблем, которые следует учитывать:
    • Должны предоставляться текстовые альтернативы для любого нетекстового контента, так чтобы его можно изменить на другие необходимые формы, например крупная печать, шрифт Брайля, озвучка текста, символы или упрощенный язык (Understanding WCAG 2.0 guideline 1.1)
    • Цвет не должен использоваться в качестве единственного визуального средства передачи информации, указания на действие, запрос реакции пользователя или выделения визуальных элементов. (WCAG 2.0 guideline 1.4.1)
    • Визуальное представление текста и изображений текста должно иметь контрастность не менее 4,5:1, за исключением большого текста, случайного текста и логотипов (WCAG 2.0 guideline 1.4.3)
    • Все функциональные возможности должны быть доступны с клавиатуры (WCAG guideline 2.1)
    • GUI или веб-проект ДОЛЖНЫ тестировать, по крайней мере, одно средство чтения экрана на целевой платформе(ах) (например, NVDA, Jaws или WindowEyes в Windows; VoiceOver на Mac и iOS; Orca на Linux/BSD; TalkBack на Android). Программы с текстовым интерфейсом пользователя МОГУТ по возможности сокращать переписывание текста на экране, чтобы предотвратить лишнее чтение средствами чтения экрана.

    Justification: compose-lint is a command-line tool with no GUI, no web frontend, and no user-facing visual interface. Output is plain ASCII text (text mode), JSON (machine-readable), or SARIF (consumable by GitHub Code Scanning, which carries its own accessibility testing). The CLI emits ANSI color only when stdout is detected as a TTY (auto-disables when piped or redirected), so screen-reader users never receive escape sequences. There is no accessibility surface to test against and no FLOSS accessibility-best-practices framework that applies.



    Проекту СЛЕДУЕТ интернационализировать создаваемое ПО, чтобы обеспечить легкую локализацию под культуру, регион или язык целевой аудитории. Выберите «неприменимо» (N/A), если интернационализация (i18n) не применяется (например, ПО не генерирует текст, предназначенный для конечных пользователей, и не сортирует текст, читаемый человеком), [internationalization]
    Локализация "относится к адаптации продукта, приложения или содержимого документа для соответствия языковым, культурным и другим требованиям конкретного целевого рынка (языковому стандарту)". Интернационализация - это «проектирование и разработка продукта, приложения или содержимого документа, которые позволяют легкую локализацию под целевые аудитории, различающиеся по культуре, региону или языку». (См. «Локализация по сравнению с интернационализацией» на веб-сайте W3C.) Чтобы ПО соответствовало этому критерию, достаточно лишь интернационализации. Не требуется локализация для другого конкретного языка, так как после того, как программное обеспечение было интернационализировано, другие могут работать над локализацией.

    Justification: compose-lint targets developers reading technical findings whose authoritative grounding (OWASP Docker Security Cheat Sheet, CIS Docker Benchmark, Docker official documentation) is published exclusively in English. Localizing rule descriptions, fix guidance, and the references they cite would require translating the upstream sources, which is out of project scope. The tool emits no end-user-facing prose beyond rule findings.


  • Другое


    Если на сайтах проекта (веб-сайт, хранилище и URL-адреса загрузки) хранятся пароли для аутентификации внешних пользователей, НЕОБХОДИМО хранить пароли как итерированные хеши с отдельной "солью" для каждого пользователя с использованием алгоритма (итерированного) растяжения ключа (например, Argon2id, Bcrypt, Scrypt или PBKDF2). Выберите «неприменимо» (N/A), если сайты проекта не хранят пароли для этой цели. [sites_password_security]
    Примечание: использование GitHub автоматически выполняет этот критерий. Этот критерий применяется только к паролям, используемым для аутентификации внешних пользователей на сайтах проекта (т.н. входящей аутентификации). Если сайты проекта должны подключаться к другим сайтам (т.н. исходящая аутентификация), им может потребоваться хранить аутентифицирующие данные (пароли, ключи) для этой цели как-то иначе (поскольку хранение контрольной суммы для этой цели бесполезно). В данном случае критерий crypto_password_storage применяется к сайтам проекта, по аналогии с критерием sites_https.

    Justification: The project hosts no sites that store user passwords. Project presence is GitHub (https://github.com/tmatens/compose-lint), PyPI (https://pypi.org/project/compose-lint/), and Docker Hub (https://hub.docker.com/r/composelint/compose-lint) — every authentication surface is delegated to those parent platforms.


 Управление изменениями 1/1

  • Предыдущие версии


    Проект ОБЯЗАН поддерживать наиболее часто используемые старые версии продукта или предоставлять возможность простого перехода на более новые версии (upgrade path). Если переход затруднен, проект ОБЯЗАН задокументировать порядок обновления (например, изменившиеся интерфейсы и подробные предлагаемые шаги для обновления). [maintenance_or_update]

    URL: https://github.com/tmatens/compose-lint/blob/main/.github/SECURITY.md#supported-versions

    Justification: .github/SECURITY.md §"Supported Versions" states: "Only the latest minor release receives security fixes." Pre-1.0 SemVer rules are documented in docs/RELEASING.md (PATCH = bug fixes only; MINOR = additive changes plus new rules at non-CRITICAL severity; MAJOR = breaking changes). The upgrade path is pip install --upgrade compose-lint (PyPI) or pulling the new tag from composelint/compose-lint (Docker Hub). Every release ships a CHANGELOG entry calling out anything that changes findings (rule additions, severity adjustments, parser fixes), so users can plan upgrades against a stable contract.


 Отчеты о проблемах 3/3

  • Процесс сообщения об ошибках


    Проект ОБЯЗАН использовать трекер вопросов (issue tracker) для отслеживания отдельных вопросов. [report_tracker]

    The project uses GitHub Issues as its public issue tracker for bug reports and feature requests. The tracker is linked from README.md, CONTRIBUTING.md, and the PyPI project page.


  • Процесс отчета об уязвимостях


    Проект ОБЯЗАН отмечать автора(-ов) всех отчетов об уязвимостях, разрешенных за последние 12 месяцев, за исключением авторов, которые просят об анонимности. Выберите «неприменимо» (N/A), если в течение последних 12 месяцев не было обнаружено никаких уязвимостей. (Требуется URL) [vulnerability_report_credit]

    URL: https://github.com/tmatens/compose-lint/blob/main/.github/SECURITY.md

    Justification: .github/SECURITY.md documents the process end-to-end. Reports are filed privately via GitHub Security Advisories at https://github.com/tmatens/compose-lint/security/advisories/new (public issues are explicitly disallowed for vulnerabilities). The maintainer commits to a 7-day acknowledgement SLA, then fix coordination and advisory publication with credit. Scope (in-scope: code execution / info disclosure via crafted Compose, supply-chain tampering, exploitable vulnerable dependencies; out-of-scope: rule false positives/negatives, vulnerable test fixtures) is defined explicitly. CONTRIBUTING.md §"Maintainers" reaffirms the 7-day security-ack SLA.



    Проект ОБЯЗАН иметь документированный процесс реагирования на отчеты об уязвимостях. (Требуется URL) [vulnerability_response_process]
    Этот критерий тесно связан с критерием vulnerability_report_process, который требует документированного способа для сообщения об уязвимостях. Он также связан с vulnerability_report_response, который требует ответа на отчеты об уязвимостях в течение определенного периода времени.

    SECURITY.md documents the CVD process: private reporting via GitHub Security Advisories, acknowledgement within 7 days, coordinated fix and advisory publication with credit. See https://github.com/tmatens/compose-lint/blob/main/SECURITY.md [osps_vm_01_01]


 Качество 19/19

  • Стандарты кодирования


    Проект ОБЯЗАН задать определенные правила стиля кодирования для основных языков, которые он использует, и требовать его соблюдения от предлагаемого кода. (Требуется URL) [coding_standards]
    В большинстве случаев это делается путем ссылки на некоторые существующие руководства по стилю, возможно, с перечислением различий. Эти руководства по стилю могут включать в себя способы повышения удобочитаемости и способы снижения вероятности дефектов (включая уязвимости). Многие языки программирования имеют один или несколько широко используемых руководств по стилю. Примеры руководств по стилю включают Руководство по стилю Google и Стандарты кодирования SEI CERT.

    URL: https://github.com/tmatens/compose-lint/blob/main/pyproject.toml

    Justification: The primary language is Python 3.10+. pyproject.toml [tool.ruff.lint] selects the active rule families: PEP 8 (E, W), pyflakes (F), isort (I), pyupgrade (UP), bugbear (B), simplify (SIM), and flake8-type-checking (TCH). pyproject.toml [tool.mypy] sets strict = true. target-version = "py310". Formatting is ruff format (Black-compatible). CONTRIBUTING.md §"Code standards" enumerates the additional contributor-facing rules (Python 3.10+ stdlib only, type annotations on all public functions, plain Python types in rule code, latest stable for new dependencies).



    Проект ОБЯЗАН автоматически применять свой выбранный стиль(и) кодирования, если есть хотя бы один инструмент на СПО, который может сделать это на выбранном языке (языках). [coding_standards_enforced]
    Это МОЖЕТ быть реализовано при помощи инструмента(ов) статического анализа и/или путем пропускания кода через средства переформатирования. Во многих случаях конфигурация инструмента включена в репозиторий проекта (так как разные проекты могут выбирать разные конфигурации). Проекты МОГУТ (и, как правило, будут) допускать исключения стиля; там, где происходят исключения, они ОБЯЗАНЫ быть редки и документированы в соответствующих местах кода, чтобы эти исключения можно было пересматривать и инструменты могли автоматически обрабатывать их в будущем. Примеры таких инструментов включают ESLint (JavaScript) и Rubocop (Ruby).

    URL: https://github.com/tmatens/compose-lint/blob/main/.github/workflows/ci.yml

    Justification: Every standard above is enforced by CI on every push and pull request to main:

    lint job: ruff check src/ tests/ and ruff format --check src/ tests/.
    type-check job: mypy src/ (strict).
    test matrix: pytest on Python 3.10, 3.11, 3.12, 3.13, 3.14.
    coverage job: pytest --cov=compose_lint --cov-fail-under=80. Locally, the pre-push hook in .githooks/ blocks unsigned commits before they reach origin. Required-status-checks on main block merges if any CI gate fails.


  • Рабочая система сборки


    Системы сборки для нативных двоичных файлов ОБЯЗАНЫ учитывать соответствующие переменные (среды) для компилятора и компоновщика, переданные им (например, CC, CFLAGS, CXX, CXXFLAGS и LDFLAGS) и передавать их на вызовы компилятора и компоновщика. Система сборки МОЖЕТ расширять их дополнительными флагами; НЕДОПУСТИМО просто заменять предоставленные значения своими. Выберите «неприменимо» (N/A), если нативные двоичные файлы не создаются. [build_standard_variables]
    Должно быть легко включить специальные функции сборки, такие как Address Sanitizer (ASAN), или выполнить рекомендации по упрочнению от дистрибутивов (например, путем простого включения флагов компилятора для этого).

    Justification: compose-lint is pure Python; no native binaries are built. The Hatchling build backend produces a py3-none-any wheel. There are no compiler or linker invocations to honor CC/CFLAGS/etc.



    В системах сборки и установки СЛЕДУЕТ сохранять отладочную информацию, если передаваемые флаги требуют этого (например, не используется «install -s»). Выберите «неприменимо» (N/A), если системы сборки или установки нет (например, для типичных библиотек JavaScript), . [build_preserve_debug]
    Например, установка CFLAGS (C) или CXXFLAGS (C++) должна создавать соответствующую информацию для отладки, если эти языки используются, и ее не следует удалять во время установки. Отладочная информация необходима для поддержки и анализа, а также полезна для того, чтобы определить наличие упрочняющих функций в скомпилированных двоичных файлах.

    Justification: There is no compiler/linker step. Python source ships verbatim inside the wheel, so debugging information (source line numbers, identifiers) is inherently preserved.



    НЕДОПУСТИМО, чтобы система сборки ПО, создаваемого проектом, рекурсивно собирала подкаталоги, если в подкаталогах есть кросс-зависимости. Выберите «неприменимо» (N/A), если системы сборки или установки нет (например, типичные библиотеки JavaScript). [build_non_recursive]
    Информация о внутренних зависимостях системы сборки проекта должна быть точной, в противном случае изменения в проекте могут быть включены в сборку неправильно. Неправильные сборки могут привести к дефектам (включая уязвимости). Общей ошибкой в ​​больших системах сборки является использование «рекурсивной сборки» или «рекурсивного make», то есть иерархии подкаталогов, содержащих исходные файлы, где каждый подкаталог собирается независимо. Если только каждый из подкаталогов не является полностью независимым, это ошибка, потому что информация о зависимостях неверна.

    Justification: Hatchling traverses a single source tree (src/compose_lint/) to produce the wheel. There is no recursive Make, no sub-builds, and therefore no cross-dependency hazard.



    Проект ОБЯЗАН быть в состоянии повторить процесс генерации информации из исходных файлов и получить такой же результат с точностью до бита. Выберите «неприменимо» (N/A), если в проекте не используется сборка (например, языки сценариев, в которых исходный код используется непосредственно вместо компиляции), . [build_repeatable]
    Пользователи GCC и clang могут найти полезной опцию -frandom-seed; в некоторых случаях это может быть разрешено путем задания определенного порядка сортировки. Дополнительные предложения можно найти на сайте Reproducible builds.

    URL: https://github.com/tmatens/compose-lint/blob/main/docs/RELEASING.md

    Justification:

    Hatchling produces deterministic wheels (declared input file lists, sorted output).
    PyPI publishes happen via Trusted Publishing (OIDC) with Sigstore build attestations attached to every release — anyone can independently verify provenance.
    Every CI install uses pip install --require-hashes -r requirements.lock (or requirements-dev.lock / requirements-build.lock); the lockfiles are regenerated reproducibly using the documented uv pip compile --generate-hashes invocations in AGENTS.md §"Regenerating lockfiles".
    Every GitHub Actions uses: reference is SHA-pinned with the tag in a trailing comment (Renovate manages the bumps).
    Docker base image is digest-pinned to the OCI manifest-list digest.


  • Система установки


    Проект ОБЯЗАН предоставлять возможность легко установить и удалить ПО, создаваемое проектом, с использованием общепринятых способов. [installation_common]
    Примеры включают использование менеджера пакетов (на уровне системы или языка), «make install/uninstall» (с поддержкой DESTDIR), контейнер в стандартном формате или образ виртуальной машины в стандартном формате. Процесс установки и удаления (например, его упаковка) МОЖЕТ быть реализован третьей стороной, при условии что он построен на СПО.

    URL: https://github.com/tmatens/compose-lint#installation

    Justification: README.md §"Installation" documents multiple install paths, all using widely-recognized conventions:

    pip install compose-lint (uninstall: pip uninstall compose-lint).
    docker run --rm -v "$(pwd):/src" composelint/compose-lint (the published image is multi-arch, distroless, nonroot).
    pre-commit hook (.pre-commit-hooks.yaml exposes the compose-lint ID for repos: use).
    GitHub Action (uses: tmatens/compose-lint@v0.7.0).



    В системе установки для конечных пользователей НЕОБХОДИМО учитывать стандартные соглашения при выборе места, в которое собранные артефакты записываются при установке. Например, если она устанавливает файлы в системе POSIX, НЕОБХОДИМО учитывать переменную окружения DESTDIR. Если установочной системы или стандартного соглашения нет, выберите «неприменимо» (N/A). [installation_standard_variables]

    URL: https://github.com/tmatens/compose-lint/blob/main/pyproject.toml

    Justification: pip honors PEP 517 / PEP 668 conventions for install location (system, virtual environment, --user, pipx). The [project.scripts] entry in pyproject.toml — compose-lint = "compose_lint.cli:main" — installs the launcher to the standard bin/ of whatever environment pip is operating against. There is no custom prefix logic, no out-of-tree install hooks, no override of the standard build/install backend.



    Проект ОБЯЗАН предоставить возможность потенциальным разработчикам быстро установить все результаты проекта и поддерживать среду, необходимую для внесения изменений, включая тесты и тестовое окружение. Проект ОБЯЗАН использовать для этого общепринятые соглашения. [installation_development_quick]
    Это МОЖЕТ быть реализовано при помощи сгенерированного контейнера или установочных сценариев. Внешние зависимости обычно устанавливаются путем вызова системных и/или языковых пакетов, как описано в критерии external_dependencies.

    CONTRIBUTING.md "Development setup" documents the full build procedure (Python ≥3.10, virtualenv, editable install with dev extras). pyproject.toml declares build-system requirements. See https://github.com/tmatens/compose-lint/blob/main/CONTRIBUTING.md#development-setup [osps_do_07_01]


  • Компоненты, поддерживаемые извне


    Проект ОБЯЗАН перечислять внешние зависимости в машинночитаемом виде. (Требуется URL) [external_dependencies]
    Обычно это делается при помощи инструкций для диспетчера пакетов и/или системы сборки. Обратите внимание, что это помогает реализовать критерий installation_development_quick.

    Dependencies are ingested via pip with hash-pinned lockfiles (requirements.lock, requirements-dev.lock, requirements-build.lock) generated by uv pip compile. CI installs use pip install --require-hashes. GitHub Actions are SHA-pinned. See https://github.com/tmatens/compose-lint/blob/main/CLAUDE.md#dependency-pinning [osps_br_05_01]



    Проекты ОБЯЗАНЫ следить за своими внешними зависимостями или периодически проверять их (включая копии, сделанные для удобства) на предмет известных уязвимостей, а также исправлять уязвимости, которые могут быть использованы, или проверять невозможность их использования. [dependency_monitoring]
    Это можно сделать с помощью средств анализа происхождения/зависимостей, например Dependency-Check от OWASP, Nexus Auditor от Sonatype, Protex от Black Duck , Protecode от Synopsys и Bundler-аудит (для Ruby). Некоторые менеджеры пакетов включают в себя соответствующие механизмы. Допустимо оставлять уязвимость, если ее невозможно использовать, но такой анализ труден, и временами проще просто обновить или исправить эту часть кода.

    URL: https://github.com/tmatens/compose-lint/tree/main/.github/workflows

    Justification: Multiple layers of dependency monitoring run continuously:

    Renovate (.github/renovate.json) opens dep-bump PRs weekly across runtime deps, dev tooling, GitHub Actions SHA pins, and Docker base image digests.
    pip-audit runs in the security job of ci.yml on every push and PR (reports all severities; gating reserved for critical).
    Bandit runs in the same job for Python source-level vulnerability patterns.
    CodeQL (.github/workflows/codeql.yml) runs on every push/PR and weekly on schedule.
    OpenSSF Scorecard (.github/workflows/scorecard.yml) runs weekly and publishes SARIF.
    Docker Scout (.github/workflows/scout-scan.yml) scans the published image; .vex/ ships OpenVEX statements for downstream consumers.
    ClusterFuzzLite (.clusterfuzzlite/, fuzz/fuzz_compose.py) fuzzes the parser on every PR.



    Проект ОБЯЗАН:
    1. позволять легко идентифицировать и обновлять повторно используемые компоненты, поддерживаемые извне; или
    2. использовать стандартные компоненты, предоставляемые системой или языком программирования.
    В этом случае, если уязвимость обнаружена в повторно используемом компоненте, будет легко обновить этот компонент. [updateable_reused_components]
    Типичным способом выполнить этот критерий является использование предоставляемых операционной системой и языком программирования систем управления пакетами. Многие свободные программы распространяются с «подсобными библиотеками», которые являются локальными копиями стандартных библиотек (возможно, форков библиотек). Само по себе это нормально. Однако, если программа *должна* использовать эти локальные копии/форки, то обновление «стандартных» библиотек через системное обновление безопасности оставит эти дополнительные копии по-прежнему уязвимыми. Это особенно актуально для облачных систем; если провайдер облака обновляет свои «стандартные» библиотеки, но программа их не собирается использовать, обновления фактически не помогут. См., например, "Chromium: Why it isn't in Fedora yet as a proper package" от Тома Каллавея.

    Direct Python dependencies are declared in pyproject.toml (dependencies and the [project.optional-dependencies] table). Fully-resolved hash-pinned lockfiles (requirements.lock, requirements-dev.lock, requirements-build.lock) are committed for reproducible CI installs. See https://github.com/tmatens/compose-lint/blob/main/pyproject.toml [osps_qa_02_01]



    Проекту СЛЕДУЕТ избегать использования нерекомендуемых (deprecated) или устаревших (obsolete) функций и API в тех случаях, когда альтернативы на СПО доступны в используемом наборе технологий («стек технологий» проекта) и для подавляющего большинства пользователей, поддерживаемых проектом (т.е. так чтобы пользователи могли быстро воспользоваться этой альтернативой). [interfaces_current]

    URL: https://github.com/tmatens/compose-lint/blob/main/pyproject.toml

    Justification:

    pyproject.toml sets target-version = "py310"; ruff's UP (pyupgrade) rules auto-flag deprecated stdlib idioms (e.g., typing.List → list).
    The CI test matrix runs Python 3.10 through 3.14, so any deprecation surfacing at the latest interpreter fails CI.
    The parser uses yaml.SafeLoader (the safe, current API), never the deprecated yaml.load(..., Loader=...) shape.
    mypy strict catches use of deprecated typing aliases that have moved.


  • Набор автотестов


    НЕОБХОДИМО применять автоматический набор тестов к каждому коммиту в общий репозиторий по крайней мере для одной ветки. Этот набор тестов ОБЯЗАН создавать отчет об успешном или неудачном тестировании. [automated_integration_testing]
    Это требование можно рассматривать как подмножество test_continuous_integration, но сосредоточенное только на тестировании, без требования непрерывной интеграции.

    CI runs the full pytest suite across Python 3.10–3.14 on every PR via .github/workflows/ci.yml; the aggregate ci-ok check is required by the main branch ruleset, blocking merge unless tests pass. [osps_qa_06_01]



    Проект ОБЯЗАН добавить регрессионные тесты к автоматизированному набору тестов по крайней мере на 50% ошибок, исправленных в течение последних шести месяцев. [regression_tests_added50]

    URL: https://github.com/tmatens/compose-lint/blob/main/CONTRIBUTING.md

    Justification: CONTRIBUTING.md §"PR expectations" mandates: "Update tests. New rules need positive and negative tests. Bug fixes need a regression test." Reviewer-enforced; the maintainer rejects bug-fix PRs that don't include the regression test in the same commit. The pull-request template surfaces this expectation at PR-creation time. Bug-fix commits in git log consistently land with their regression test in the same commit, comfortably exceeding the 50% threshold.



    Проект ОБЯЗАН иметь автоматические тестовые пакеты на СПО, которые обеспечивают покрытие не менее 80% инструкций кода, если есть хотя бы один инструмент на СПО, который может измерять этот критерий на выбранном языке. [test_statement_coverage80]
    Для измерения тестового покрытия существует множество средств на СПО, включая gcov/lcov, Blanket.js, Istanbul и JCov. Обратите внимание, что соответствие этому критерию не является гарантией того, что тестовый пакет является исчерпывающим; вместо этого, несоответствие этому критерию является сильным индикатором плохого набора тестов.

    URL: https://github.com/tmatens/compose-lint/blob/main/.github/workflows/ci.yml

    Justification: Statement coverage is measured in CI on every push and PR and gated at ≥80%:

    pyproject.toml adds pytest-cov==7.1.0 to the [dev] extras and configures [tool.coverage.run] (source = compose_lint, statement coverage, parallel = true) plus [tool.coverage.report] (fail_under = 80, show_missing, sensible excludes for TYPE_CHECKING / NotImplementedError / # pragma: no cover).
    The coverage job in .github/workflows/ci.yml runs pytest --cov=compose_lint --cov-report=term-missing --cov-fail-under=80 on Python 3.13. The threshold is duplicated at the workflow level so a config drift cannot silently lower it. The job is in the ci-ok rollup so branch protection enforces it.
    A subprocess-coverage shim (coverage_subprocess.pth + COVERAGE_PROCESS_START) ensures coverage measures the python -m compose_lint subprocesses spawned by test_cli.py and test_integration.py. Measured statement coverage on Linux CI is approximately 93%.
    CONTRIBUTING.md §"Local quality checks" documents the local coverage command for contributors.


  • Тестирование новых функций


    Проект ОБЯЗАН иметь формальную задокументированную политику о том, что при добавлении существенной новой функциональности НЕОБХОДИМО добавлять тесты для новой функциональности в набор автоматических тестов. [test_policy_mandated]

    URL: https://github.com/tmatens/compose-lint/blob/main/CONTRIBUTING.md

    Justification: CONTRIBUTING.md §"Adding a new rule" lists the test obligation as step 5 of the new-rule checklist: "Add test file tests/test_CL{NNNN}.py with both positive (triggers) and negative (clean) cases. Negative cases must include at least one hardened-but-unusual configuration the rule must not flag." §"PR expectations" generalizes the rule: tests required for new functionality, regression tests required for bug fixes. The PR template links back to CONTRIBUTING.md so contributors see the policy at PR-creation time.



    Проект ОБЯЗАН включать в свои документированные инструкции для предложений об изменениях политику, по которой для существенной новой функциональности должны добавляться тесты. [tests_documented_added]
    Однако даже неформальное правило приемлемо, если тесты добавляются на практике.

    Documented in CONTRIBUTING.md §"Adding a new rule" (test file is step 5 of the checklist) and §"PR expectations" ("Update tests. New rules need positive and negative tests. Bug fixes need a regression test."). The PR template links back to CONTRIBUTING.md.


  • Флаги предупреждений


    Проекты ОБЯЗАНЫ быть максимально строгими с предупреждениями в ПО, создаваемом проектом, где это целесообразно. [warnings_strict]
    Некоторые предупреждения не могут быть эффективно задействованы в некоторых проектах. Что необходимо в этом критерии - это доказательства того, что проект стремится включать флаги предупреждений там, где это возможно, чтобы ошибки обнаруживались на ранней стадии.

    mypy runs with strict = true (the maximum setting: enables all optional strict flags). ruff selects broad rule families including B (bugbear correctness checks) and UP (pyupgrade modernization) in addition to the defaults. Formatting drift is also an error (ruff format --check).


 Безопасность 13/13

  • Знание безопасной разработки


    Проект ОБЯЗАН реализовывать принципы безопасного дизайна (из критерия «know_secure_design»), где это применимо. Выберите «неприменимо» (N/A), если проект не создает программное обеспечение. [implement_secure_design]
    Например, результаты проекта должны иметь отказоустойчивые значения по умолчанию (доступ по умолчанию должен быть запрещен, а установка проектов по умолчанию должна быть в защищенной конфигурации). Также должно использоваться полное отграничение (любой доступ, который может быть ограничен, должен проверяться на достаточность прав доступа и не иметь обходных путей). Обратите внимание, что в некоторых случаях принципы будут противоречить друг другу, и в этом случае необходимо делать выбор (например, многочисленность механизмов может усложнять дизайн, противореча принципу экономичности/простоты механизма).

    Secure design principles applied throughout:

    Least privilege: single runtime dep (PyYAML); CI workflows declare permissions: {} deny-all and per-job least-privilege scopes; published Docker image is distroless, runs as nonroot uid 65532, drops all capabilities by documented invocation.
    Input validation: LineLoader(yaml.SafeLoader) — never yaml.load() — rejects malformed/unsafe YAML and Python-object tags. Engine validates that services: exists and is a mapping (ADR-013). Rules receive plain Python primitives; parser-specific types never leak into rule code.
    Fail-secure: usage errors and parse failures exit 2 (distinct from "findings present" exit 1). Default --fail-on=HIGH errs on the side of breaking the build.
    Defense in depth: mypy strict + ruff B (bugbear) + Bandit + CodeQL + ClusterFuzzLite fuzzing + pip-audit + Scorecard, layered.
    Secure defaults: pre-commit hook fails closed; GitHub Action runs without arguments and lints repository defaults; Docker image entrypoint is the linter (no shell).
    Supply-chain security: Trusted Publishing (no long-lived PyPI tokens), Sigstore attestations, hash-pinned lockfiles, SHA-pinned actions, signed git tags, OIDC for Docker Hub.
    References: README §"Security posture", SECURITY.md §"Supply Chain", docs/adr/003-yaml-parsing.md, docs/adr/006-exit-codes.md, docs/adr/009-runtime-base-image.md.


  • Основы правильного использования криптографии

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

    В ПО, создаваемом проектом, НЕДОПУСТИМО делать механизмы безопасности по умолчанию зависимыми от криптографических алгоритмов или режимов с известными серьезными слабостями (например, криптографический алгоритм хеширования SHA-1 или режим CBC в SSH). [crypto_weaknesses]
    Проблемы, связанные с режимом CBC в SSH, обсуждаются в описании уязвимости CERT: SSH CBC.

    N/A — compose-lint is a static Docker Compose linter. The software produced implements no cryptographic protocols, algorithms, password storage, or key/nonce generation. Sole runtime dependency is PyYAML.



    Проекту СЛЕДУЕТ поддерживать несколько криптографических алгоритмов, чтобы пользователи могли быстро переключиться, если один из них поврежден. Общие симметричные ключевые алгоритмы включают AES, Twofish и Serpent. Общие алгоритмы контрольных сумм (хешей) включают SHA-2 (SHA-224, SHA-256, SHA-384 и SHA-512) и SHA-3. [crypto_algorithm_agility]

    compose-lint implements no cryptographic algorithms in its product code. PyYAML, the sole runtime dependency, performs no crypto. Mark N/A.



    Проект ОБЯЗАН поддерживать хранение данных для аутентификации (например, паролей и динамических токенов) и закрытых криптографических ключей в файлах, отдельных от остальной информации (например, файлов конфигурации, баз данных и журналов) и позволять пользователям их обновление и замену без перекомпиляции кода. Выберите «неприменимо» (N/A), если проект никогда не работает с данными аутентификации и закрытыми криптографическими ключами. [crypto_credential_agility]

    compose-lint implements no cryptographic algorithms in its product code. PyYAML, the sole runtime dependency, performs no crypto. Mark N/A.



    В ПО, создаваемом проектом, СЛЕДУЕТ поддерживать безопасные протоколы для всех сетевых коммуникаций, такие как SSHv2 или новее, TLS1.2 или новее (HTTPS), IPsec, SFTP и SNMPv3. По умолчанию СЛЕДУЕТ отключать небезопасные протоколы, такие как FTP, HTTP, telnet, SSLv3 или более ранние версии, и SSHv1, и разрешать их только в том случае, если пользователь явным образом это задаёт. Если программное обеспечение, созданное проектом, не поддерживает сетевые коммуникации, выберите «неприменимо» (N/A). [crypto_used_network]

    compose-lint performs no network communication at runtime. The CLI reads files from disk and writes findings to stdout/stderr. Mark N/A.



    Если ПО, создаваемое проектом, поддерживает или использует TLS, ему СЛЕДУЕТ поддерживать как минимум версию TLS 1.2. Примечание: предшественник TLS называется SSL. Если программное обеспечение не использует TLS, выберите «неприменимо» (N/A). [crypto_tls12]

    No TLS use. Mark N/A.



    В ПО, создаваемом проектом, НЕОБХОДИМО выполнять проверку сертификата TLS по умолчанию при использовании TLS, в том числе в подресурсах. Если программное обеспечение не использует TLS, выберите «неприменимо» (N/A). [crypto_certificate_verification]
    Обратите внимание, что неправильная проверка сертификата TLS является распространенной ошибкой. Для дальнейших сведений см. "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" Мартина Георгиева и др. и "Do you trust this application?" Майкла Катанзаро.

    No TLS use. Mark N/A.



    В ПО, создаваемом проектом, НЕОБХОДИМО, если поддерживается TLS, выполнять проверку сертификата TLS по умолчанию при использовании TLS, в том числе в подресурсах. Если программное обеспечение не использует TLS, выберите «неприменимо» (N/A). [crypto_verification_private]

    No TLS use. Mark N/A.


  • Безопасный выпуск


    Проект ОБЯЗАН криптографически подписывать выпуски результатов проекта, предназначенные для широкого использования, и ОБЯЗАН иметь задокументированный процесс, объясняющий пользователям, как они могут получить общедоступные ключи подписи и проверить подпись(и) выпусков. НЕДОПУСТИМО размещать закрытый ключ для этих подписей на сайте(сайтах), используемом для прямого распространения ПО для общественности. Выберите «неприменимо» (N/A), если выпуски не предназначены для широкого использования. [signed_releases]
    Результаты проекта включают как исходный код, так и любые сгенерированные результаты, если это применимо (например, исполняемые файлы, пакеты и контейнеры). Сгенерированные результаты МОГУТ быть подписаны отдельно от исходного кода. Подписывание МОЖЕТ быть реализовано как подписанные теги git (с использованием криптографических цифровых подписей). Проекты МОГУТ предоставлять генерируемые результаты отдельно от таких инструментов, как git, но в этих случаях отдельные результаты ОБЯЗАНЫ быть отдельно подписаны.

    PyPI releases include Sigstore build attestations generated via Trusted Publishing (OIDC) — each wheel and sdist is accompanied by a signed attestation. Git tags are SSH-signed. Verify via PyPI's attestation viewer or python -m sigstore verify. See https://github.com/tmatens/compose-lint/blob/main/SECURITY.md [osps_br_06_01]



    ЖЕЛАТЕЛЬНО, чтобы в системе контроля версий каждый важный тег версии (тег, который является частью основного выпуска, минорной версии или исправляет общедоступные уязвимости) подписывался криптографической подписью и поддавался проверке, как описано в критерииsigned_releases. [version_tags_signed]

    Every release tag is git tag -s SSH-signed annotated. publish.yml verify-tag job now performs three checks (the previously-noted "follow-up" is closed):

    Annotated tag (git cat-file -t returns tag, not commit).
    Reachable from origin/main.
    SSH signature verifies against .github/allowed_signers (added in PR #202; key namespace-scoped to git so it cannot be reused for arbitrary SSH signing if leaked). Pre-flight handles missing/empty allowed_signers with an explicit error pointing at the rotation procedure in GOVERNANCE.md.
    End-to-end provenance chain is now: SSH-verified annotated tag → reachable-from-main → CI build → Sigstore attestation → PyPI / Docker Hub.


  • Другие вопросы безопасности


    В результатах проекта НЕОБХОДИМО проверять любой ввод из потенциально ненадежных источников, чтобы убедиться, что они действительны (*белый список*), и отклонять недействительный ввод, если вообще есть какие-либо ограничения на данные. [input_validation]
    Обратите внимание, что сравнения ввода со списком «плохих форматов» (также известным как *черный список*) обычно недостаточно, потому что злоумышленники часто могут обойти черный список. В частности, числа преобразуются во внутренние форматы, а затем проверяются, находятся ли они между их минимальным и максимальным (включительно), а текстовые строки проверяются, чтобы убедиться, что они являются допустимыми текстовыми шаблонами (например, действительный UTF-8, длина, синтаксис и т. д.). От некоторых данных может требоваться, чтобы они были «хоть чем-нибудь» (например, загрузчик файлов), но такое обычно случается редко.

    Parser: LineLoader(yaml.SafeLoader) rejects unsafe YAML constructs (Python-object tags, arbitrary class instantiation). Documented in ADR-003.
    Engine: validates that services: exists and is a mapping; emits a usage error (exit 2) otherwise. ADR-013 covers the missing-services-key handling.
    Rules: receive only plain Python primitives; rule code does not reach back to parser internals.
    Allowlist nature: rules check for known-bad patterns, not arbitrary input shapes; the allowlist for what counts as "valid Compose" is delegated to authoritative Compose schema (the linter is intentionally lenient on schema compliance to focus on security findings — see feedback_scope_security_not_style memory).
    Fuzzing: fuzz/fuzz_compose.py runs continuously via ClusterFuzzLite (.clusterfuzzlite/) on every PR, attacking the parser surface with adversarial input.



    В ПО, создаваемом проектом, СЛЕДУЕТ использовать механизмы упрочнения безопасности (hardening), чтобы дефекты программного обеспечения с меньшей вероятностью приводили к уязвимостям в безопасности. [hardening]
    Механизмы упрочнения могут включать HTTP-заголовки, такие как Content Security Policy (CSP), флаги компилятора для противостояния атакам (например, -fstack-protector) или флаги компилятора, устраняющие неопределенное поведение. Для наших целей политика наименьших привилегий не считается механизмом упрочнения (использовать наименьшие достаточные привилегии важно, но этому посвящён отдельный критерий).

    Memory-safe language: pure Python. Type system enforcement: mypy --strict in CI. Lint-level hardening: ruff B (bugbear correctness rules), UP (pyupgrade), SIM (simplify), TCH (type-checking) — all run on every PR. Runtime container hardening: published Docker image is distroless, multi-arch, nonroot (uid 65532); README documents the fully-hardened invocation (--read-only --cap-drop ALL --security-opt no-new-privileges:true --network none --user 65532:65532 --pids-limit 256). CI workflow hardening: every workflow declares permissions: {} deny-all at top; jobs request only the scopes they need; every uses: is SHA-pinned with a trailing tag comment. Supply-chain hardening: PyPI Trusted Publishing (no long-lived tokens), hash-pinned lockfiles, signed annotated tags, Sigstore attestations, cosign-signed Docker images.



    Проект ОБЯЗАН предоставить обоснование того, что требования безопасности соблюдаются проектом. В обоснование НЕОБХОДИМО включить: описание модели угроз, четкое указание границ доверия, доказательство того, что использовались принципы безопасного дизайна, и доказательство того, что слабости в безопасности реализации нейтрализованы. (Требуется URL) [assurance_case]
    Обоснованием является «документальное подтверждение, которое дает убедительное и корректное доказательство того, что указанный набор критических заявлений относительно свойств системы адекватно оправдан для данного приложения в данной среде» (перевод выдержки из "Software Assurance Using Structured Assurance Case Models", Thomas Rhodes et al, NIST Interagency Report 7608). Границы доверия - это границы, на которых меняется уровень доверия к данным или выполнению кода, например границы сервера в типичном веб-приложении. В обосновании обычно перечисляются принципы безопасного проектирования (такие как Saltzer and Schroeer) и общие слабости безопасности в реализации (такие как OWASP Top 10 или CWE/SANS Top 25), и показывается, как противодействовать каждой из них. Полезным примером может служить обоснование для BadgeApp. Этот критерий связан с documentation_security, documentation_architecture и implement_secure_design.

    Threat surface assessed and documented across the project: SECURITY.md defines scope and out-of-scope; the architecture is deliberately minimal (PyYAML only runtime dependency, read-only file processing, no network, no eval); adversarial inputs (malformed YAML, billion-laughs-style attacks, crafted anchor/merge chains) are exercised by ClusterFuzzLite continuous fuzzing. Supply-chain surface hardened via Trusted Publishing, Sigstore attestations, signed commits/tags, SHA-pinned actions, hash-pinned lockfiles. See https://github.com/tmatens/compose-lint/blob/main/SECURITY.md [osps_sa_03_01]


 Анализ 2/2

  • Статический анализ кода


    Проект ОБЯЗАН использовать хотя бы один инструмент статического анализа с правилами или подходами для поиска распространенных уязвимостей в анализируемом языке или окружении, если есть хотя бы один инструмент на СПО, который может реализовать этот критерий на выбранном языке. [static_analysis_common_vulnerabilities]
    Инструменты статического анализа, специально предназначенные для поиска распространенных уязвимостей, с большей вероятностью найдут их. Тем не менее, использование любых статических инструментов обычно помогает найти какие-то проблемы, поэтому мы предлагаем, но не требуем этого для получения базового значка.

    Bandit and CodeQL both implement vulnerability-pattern rules. Bandit scans for the Python-specific common-weakness patterns (B-series: shell injection, insecure deserialization, weak crypto calls, hardcoded secrets, etc.). CodeQL's default query suite covers OWASP/CWE categories (injection, path traversal, SSRF, XSS).


  • Динамический анализ кода


    Если ПО, создаваемое проектом, включает ПО, написанное с использованием небезопасного языка (например, C или C++), тогда проект ОБЯЗАН регулярно использовать хотя бы один динамический инструмент (например, фаззер или сканер веб-приложения) в сочетании с механизмом для обнаружения проблем безопасности памяти, таких как перезапись буфера. Выберите «неприменимо» (N/A), если проект не создает ПО, написанное на небезопасном языке. [dynamic_analysis_unsafe]
    Примерами механизмов обнаружения проблем безопасности памяти являются Address Sanitizer (ASAN) (доступен в GCC и LLVM), Memory Sanitizer и valgrind. Другие потенциально используемые инструменты включают Thread Sanitizer и Undefined Behavior Sanitizer. Достаточно широкое использование утверждений (assertions) тоже может быть приемлемо.

    compose-lint is written in pure Python (a memory-safe language) with PyYAML as the sole runtime dependency. No C/C++/unsafe-Rust code is produced or shipped.



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

Владелец анкеты на значок проекта: Todd Matens.
2026-04-12 08:08:52 UTC, последнее изменение сделано 2026-05-03 00:49:57 UTC. Последний раз условия для получения значка были выполнены 2026-04-19 05:15:06 UTC.