compose-lint

Projetos que seguem as melhores práticas abaixo podem se autocertificar voluntariamente e mostrar que alcançaram um selo de melhores práticas da Open Source Security Foundation (OpenSSF).

Não existe um conjunto de práticas que possa garantir que o software nunca terá defeitos ou vulnerabilidades; mesmo métodos formais podem falhar se as especificações ou suposições estiverem erradas. Nem existe qualquer conjunto de práticas que possa garantir que um projeto sustentará uma comunidade de desenvolvimento saudável e bem-funcionada. No entanto, seguir as melhores práticas pode ajudar a melhorar os resultados dos projetos. Por exemplo, algumas práticas permitem revisão multipessoal antes do lançamento, o que pode ajudar a encontrar vulnerabilidades técnicas difíceis de encontrar e ajudar a construir confiança e desejo de interação repetida entre desenvolvedores de diferentes empresas. Para ganhar um selo, todos os critérios DEVE e NÃO DEVE devem ser atendidos, todos os critérios DEVERIA devem ser atendidos OU não atendidos com justificativa, e todos os critérios SUGERIDO devem ser atendidos OU não atendidos (queremos que sejam considerados pelo menos). Se você quiser inserir texto de justificativa como um comentário genérico, em vez de ser uma justificativa de que a situação é aceitável, inicie o bloco de texto com '//' seguido de um espaço. Feedback é bem-vindo via site do GitHub como questões ou pull requests Há também uma lista de discussão para discussão geral.

Fornecemos com prazer as informações em vários idiomas, no entanto, se houver qualquer conflito ou inconsistência entre as traduções, a versão em inglês é a versão autoritativa.
Se este é o seu projeto, por favor mostre o status do seu selo na página do seu projeto! O status do selo se parece com isto: O nível do selo para o projeto 12472 é silver Aqui está como incorporá-lo:
Você pode mostrar o status do seu selo incorporando isto no seu arquivo markdown:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/12472/badge)](https://www.bestpractices.dev/projects/12472)
ou incorporando isto no seu HTML:
<a href="https://www.bestpractices.dev/projects/12472"><img src="https://www.bestpractices.dev/projects/12472/badge"></a>


Estes são os critérios de nível Prata. Você também pode visualizar os critérios de nível Aprovação ou Ouro.

Baseline Series: Nível Básico 1 Nível Básico 2 Nível Básico 3

        

 Fundamentos 17/17

  • Geral

    Observe que outros projetos podem usar o mesmo nome.

    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.

    Use o formato de expressão de licença SPDX; exemplos incluem "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" e "(BSD-2-Clause OR Ruby)". Não inclua aspas simples ou aspas duplas.
    Se houver mais de uma linguagem, liste-as como valores separados por vírgula (espaços opcionais) e ordene-as da mais usada para a menos usada. Se houver uma longa lista, liste pelo menos as três primeiras mais comuns. Se não houver linguagem (por exemplo, este é um projeto apenas de documentação ou apenas de teste), use o caractere único "-". Use uma capitalização convencional para cada linguagem, por exemplo, "JavaScript".
    O Common Platform Enumeration (CPE) é um esquema de nomenclatura estruturado para sistemas de tecnologia da informação, software e pacotes. Ele é usado em vários sistemas e bancos de dados ao relatar vulnerabilidades.

    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.

  • Pré-requisitos


    O projeto DEVE alcançar um distintivo de nível aprovado. [achieve_passing]

  • Conteúdo básico do site do projeto


    As informações sobre como contribuir DEVEM incluir os requisitos para contribuições aceitáveis (por exemplo, uma referência a qualquer padrão de codificação obrigatório). (URL obrigatória) [contribution_requirements]
  • Supervisão do projeto


    O projeto DEVERIA ter um mecanismo legal onde todos os desenvolvedores de quantidades não triviais de software do projeto afirmem que estão legalmente autorizados a fazer essas contribuições. A abordagem mais comum e facilmente implementada para fazer isso é usando um Developer Certificate of Origin (DCO), onde os usuários adicionam "signed-off-by" em seus commits e o projeto faz link para o site do DCO. No entanto, isso PODE ser implementado como um Contributor License Agreement (CLA) ou outro mecanismo legal. (URL obrigatória) [dco]
    O DCO é o mecanismo recomendado porque é fácil de implementar, rastreado no código-fonte e o git suporta diretamente um recurso "signed-off" usando "commit -s". Para ser mais eficaz, é melhor que a documentação do projeto explique o que "signed-off" significa para aquele projeto. Um CLA é um acordo legal que define os termos sob os quais obras intelectuais foram licenciadas para uma organização ou projeto. Um contributor assignment agreement (CAA) é um acordo legal que transfere direitos em uma obra intelectual para outra parte; os projetos não são obrigados a ter CAAs, já que ter CAA aumenta o risco de que contribuidores potenciais não contribuam, especialmente se o receptor for uma organização com fins lucrativos. Os CLAs da Apache Software Foundation (a licença de contribuidor individual e o CLA corporativo) são exemplos de CLAs, para projetos que determinam que os riscos desses tipos de CLAs para o projeto são menores do que seus benefícios.

    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]



    O projeto DEVE definir e documentar claramente seu modelo de governança do projeto (a forma como toma decisões, incluindo papéis-chave). (URL obrigatória) [governance]
    É necessário haver alguma forma bem estabelecida e documentada de tomar decisões e resolver disputas. Em projetos pequenos, isso pode ser tão simples quanto "o proprietário do projeto e líder toma todas as decisões finais". Existem vários modelos de governança, incluindo ditador benevolente e meritocracia formal; para mais detalhes, consulte Modelos de governança. Tanto abordagens centralizadas (por exemplo, mantenedor único) quanto descentralizadas (por exemplo, grupo de mantenedores) foram usadas com sucesso em projetos. As informações de governança não precisam documentar a possibilidade de criar um fork do projeto, já que isso é sempre possível para projetos FLOSS.

    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).



    O projeto DEVE adotar um código de conduta e publicá-lo em um local padrão. (URL obrigatória) [code_of_conduct]
    Os projetos podem ser capazes de melhorar a civilidade de sua comunidade e estabelecer expectativas sobre conduta aceitável adotando um código de conduta. Isso pode ajudar a evitar problemas antes que ocorram e tornar o projeto um lugar mais acolhedor para encorajar contribuições. Isso deve se concentrar apenas no comportamento dentro da comunidade/local de trabalho do projeto. Exemplos de códigos de conduta são o código de conduta do kernel Linux, o Contributor Covenant Code of Conduct, o Código de Conduta Debian, o Código de Conduta Ubuntu, o Código de Conduta Fedora, o Código de Conduta GNOME, o Código de Conduta da Comunidade KDE, o Código de Conduta da Comunidade Python, A Diretriz de Conduta da Comunidade Ruby e O Código de Conduta do Rust.

    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.



    O projeto DEVE definir e documentar publicamente de forma clara os papéis-chave no projeto e suas responsabilidades, incluindo quaisquer tarefas que esses papéis devem executar. DEVE estar claro quem tem qual(is) papel(is), embora isso possa não ser documentado da mesma forma. (URL obrigatória) [roles_responsibilities]
    A documentação para governança e papéis e responsabilidades pode estar em um único lugar.

    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]



    O projeto DEVE ser capaz de continuar com interrupção mínima se qualquer pessoa morrer, ficar incapacitada ou, de outra forma, não puder ou não quiser continuar o suporte do projeto. Em particular, o projeto DEVE ser capaz de criar e fechar issues, aceitar mudanças propostas e lançar versões do software, dentro de uma semana após a confirmação da perda de suporte de qualquer indivíduo. Isso PODE ser feito garantindo que outra pessoa tenha quaisquer chaves, senhas e direitos legais necessários para continuar o projeto. Indivíduos que executam um projeto FLOSS PODEM fazer isso fornecendo chaves em um cofre e um testamento fornecendo quaisquer direitos legais necessários (por exemplo, para nomes DNS). (URL obrigatória) [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.



    O projeto DEVERIA ter um "bus factor" de 2 ou mais. (URL obrigatória) [bus_factor]
    Um "bus factor" (também conhecido como "truck factor") é o número mínimo de membros do projeto que precisam desaparecer repentinamente de um projeto ("ser atropelados por um ônibus") antes que o projeto pare devido à falta de pessoal conhecedor ou competente. A ferramenta truck-factor pode estimar isso para projetos no GitHub. Para mais informações, consulte Assessing the Bus Factor of Git Repositories de Cosentino et al.

    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".


  • Documentação


    O projeto DEVE ter um roadmap documentado que descreva o que o projeto pretende fazer e não fazer por pelo menos o próximo ano. (URL obrigatória) [documentation_roadmap]
    O projeto pode não alcançar o roadmap, e isso é aceitável; o objetivo do roadmap é ajudar usuários e contribuidores potenciais a entender a direção pretendida do projeto. Não precisa ser detalhado.

    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.



    O projeto DEVE incluir documentação da arquitetura (também conhecida como design de alto nível) do software produzido pelo projeto. Se o projeto não produz software, selecione "não aplicável" (N/A). (URL obrigatória) [documentation_architecture]
    Uma arquitetura de software explica as estruturas fundamentais de um programa, ou seja, os principais componentes do programa, os relacionamentos entre eles e as principais propriedades desses componentes e relacionamentos.

    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]



    O projeto DEVE documentar o que o usuário pode e não pode esperar em termos de segurança do software produzido pelo projeto (seus "requisitos de segurança"). (URL obrigatória) [documentation_security]
    Estes são os requisitos de segurança que o software deve atender.

    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.



    O projeto DEVE fornecer um guia de "início rápido" para novos usuários para ajudá-los a fazer algo rapidamente com o software. (URL obrigatória) [documentation_quick_start]
    A ideia é mostrar aos usuários como começar e fazer o software fazer qualquer coisa. Isso é extremamente importante para que potenciais usuários comecem.

    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.



    O projeto DEVE fazer um esforço para manter a documentação consistente com a versão atual dos resultados do projeto (incluindo software produzido pelo projeto). Quaisquer defeitos de documentação conhecidos que a tornem inconsistente DEVEM ser corrigidos. Se a documentação estiver geralmente atualizada, mas erroneamente incluir algumas informações antigas que não são mais verdadeiras, trate isso apenas como um defeito, então rastreie e corrija como de costume. [documentation_current]
    A documentação PODE incluir informações sobre diferenças ou mudanças entre versões do software e/ou link para versões antigas da documentação. A intenção deste critério é que um esforço seja feito para manter a documentação consistente, não que a documentação deva ser perfeita.

    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.



    A página inicial do repositório do projeto e/ou site DEVE identificar e criar hiperlinks para quaisquer conquistas, incluindo este selo de melhores práticas, dentro de 48 horas do reconhecimento público de que a conquista foi alcançada. (URL obrigatória) [documentation_achievements]
    Uma conquista é qualquer conjunto de critérios externos que o projeto trabalhou especificamente para atender, incluindo alguns selos. Esta informação não precisa estar na página inicial do site do projeto. Um projeto usando o GitHub pode colocar conquistas na página inicial do repositório adicionando-as ao arquivo 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).


  • Acessibilidade e internacionalização


    O projeto (tanto os sites do projeto quanto os resultados do projeto) DEVERIA seguir as melhores práticas de acessibilidade para que pessoas com deficiências ainda possam participar do projeto e usar os resultados do projeto quando for razoável fazê-lo. [accessibility_best_practices]
    Para aplicações web, veja as Diretrizes de Acessibilidade para Conteúdo Web (WCAG 2.0) e seu documento de apoio Understanding WCAG 2.0; veja também informações de acessibilidade do W3C. Para aplicações GUI, considere usar as diretrizes de acessibilidade específicas do ambiente (como Gnome, KDE, XFCE, Android, iOS, Mac e Windows). Algumas aplicações TUI (por exemplo, programas `ncurses`) podem fazer certas coisas para se tornarem mais acessíveis (como a configuração `force-arrow-cursor` do `alpine`). A maioria das aplicações de linha de comando são bastante acessíveis como estão. Este critério é frequentemente N/A, por exemplo, para bibliotecas de programas. Aqui estão alguns exemplos de ações a tomar ou questões a considerar:
    • Forneça alternativas de texto para qualquer conteúdo não textual para que possa ser transformado em outras formas que as pessoas precisam, como letras grandes, braille, fala, símbolos ou linguagem mais simples (diretriz WCAG 2.0 1.1)
    • A cor não é usada como o único meio visual de transmitir informações, indicar uma ação, solicitar uma resposta ou distinguir um elemento visual. (diretriz WCAG 2.0 1.4.1)
    • A apresentação visual de texto e imagens de texto tem uma razão de contraste de pelo menos 4.5:1, exceto para texto grande, texto incidental e logotipos (diretriz WCAG 2.0 1.4.3)
    • Torne toda a funcionalidade disponível a partir de um teclado (diretriz WCAG 2.1)
    • Um projeto GUI ou baseado na web DEVERIA testar com pelo menos um leitor de tela nas plataformas de destino (por exemplo, NVDA, Jaws ou WindowEyes no Windows; VoiceOver no Mac & iOS; Orca no Linux/BSD; TalkBack no Android). Programas TUI PODEM trabalhar para reduzir o redesenho para evitar leitura redundante por leitores de tela.

    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.



    O software produzido pelo projeto DEVERIA ser internacionalizado para permitir fácil localização para a cultura, região ou idioma do público-alvo. Se a internacionalização (i18n) não se aplicar (por exemplo, o software não gera texto destinado a usuários finais e não classifica texto legível por humanos), selecione "não aplicável" (N/A). [internationalization]
    Localização "refere-se à adaptação de um produto, aplicação ou conteúdo de documento para atender aos requisitos de idioma, cultura e outros de um mercado-alvo específico (um locale)". Internacionalização é o "projeto e desenvolvimento de um produto, aplicação ou conteúdo de documento que permite fácil localização para públicos-alvo que variam em cultura, região ou idioma". (Veja "Localization vs. Internationalization" do W3C.) O software atende a este critério simplesmente sendo internacionalizado. Nenhuma localização para outro idioma específico é necessária, pois uma vez que o software foi internacionalizado, é possível para outros trabalharem na localização.

    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.


  • Outro


    Se os sites do projeto (site, repositório e URLs de download) armazenam senhas para autenticação de usuários externos, as senhas DEVEM ser armazenadas como hashes iterados com um salt por usuário usando um algoritmo de extensão de chave (iterado) (por exemplo, Argon2id, Bcrypt, Scrypt ou PBKDF2). Se os sites do projeto não armazenam senhas para este propósito, selecione "não aplicável" (N/A). [sites_password_security]
    Observe que o uso do GitHub atende a este critério. Este critério aplica-se apenas a senhas usadas para autenticação de usuários externos nos sites do projeto (também conhecida como autenticação de entrada). Se os sites do projeto precisam fazer login em outros sites (também conhecida como autenticação de saída), eles podem precisar armazenar tokens de autorização para esse propósito de forma diferente (já que armazenar um hash seria inútil). Isso aplica o critério crypto_password_storage aos sites do projeto, semelhante a 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.


 Controle de Mudanças 1/1

  • Versões anteriores


    O projeto DEVE manter as versões mais antigas do produto mais frequentemente usadas ou fornecer um caminho de atualização para versões mais recentes. Se o caminho de atualização for difícil, o projeto DEVE documentar como realizar a atualização (por exemplo, as interfaces que mudaram e etapas sugeridas detalhadas para ajudar na atualização). [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.


 Relatórios 3/3

  • Processo de relato de bugs


    O projeto DEVE usar um rastreador de questões para rastrear questões individuais. [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.


  • Processo de relato de vulnerabilidades


    O projeto DEVE dar crédito ao(s) relator(es) de todos os relatórios de vulnerabilidade resolvidos nos últimos 12 meses, exceto para o(s) relator(es) que solicitarem anonimato. Se não houve vulnerabilidades resolvidas nos últimos 12 meses, selecione "não aplicável" (N/A). (URL obrigatória) [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.



    O projeto DEVE ter um processo documentado para responder a relatos de vulnerabilidades. (URL obrigatória) [vulnerability_response_process]
    Isso está fortemente relacionado a vulnerability_report_process, que exige que haja uma forma documentada de relatar vulnerabilidades. Também está relacionado a vulnerability_report_response, que exige resposta a relatos de vulnerabilidades dentro de um determinado prazo.

    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]


 Qualidade 19/19

  • Padrões de codificação


    O projeto DEVE identificar os guias de estilo de codificação específicos para as linguagens primárias que utiliza, e exigir que as contribuições geralmente estejam em conformidade com eles. (URL obrigatória) [coding_standards]
    Na maioria dos casos, isso é feito referenciando algum(ns) guia(s) de estilo existente(s), possivelmente listando diferenças. Esses guias de estilo podem incluir maneiras de melhorar a legibilidade e maneiras de reduzir a probabilidade de defeitos (incluindo vulnerabilidades). Muitas linguagens de programação têm um ou mais guias de estilo amplamente utilizados. Exemplos de guias de estilo incluem guias de estilo do Google e Padrões de Codificação 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).



    O projeto DEVE aplicar automaticamente seu(s) estilo(s) de codificação selecionado(s) se houver pelo menos uma ferramenta FLOSS que possa fazer isso na(s) linguagem(ns) selecionada(s). [coding_standards_enforced]
    Isso PODE ser implementado usando ferramenta(s) de análise estática e/ou forçando o código através de reformatadores de código. Em muitos casos, a configuração da ferramenta está incluída no repositório do projeto (já que projetos diferentes podem escolher configurações diferentes). Os projetos PODEM permitir exceções de estilo (e normalmente permitirão); onde ocorrem exceções, elas DEVEM ser raras e documentadas no código em suas localizações, para que essas exceções possam ser revisadas e para que as ferramentas possam tratá-las automaticamente no futuro. Exemplos de tais ferramentas incluem ESLint (JavaScript), Rubocop (Ruby) e devtools check (R).

    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.


  • Sistema de compilação funcional


    Os sistemas de compilação para binários nativos DEVEM honrar as variáveis de compilador e vinculador (ambiente) relevantes passadas para eles (por exemplo, CC, CFLAGS, CXX, CXXFLAGS e LDFLAGS) e passá-las para invocações de compilador e vinculador. Um sistema de compilação PODE estendê-las com flags adicionais; ele NÃO DEVE simplesmente substituir valores fornecidos pelos seus próprios. Se nenhum binário nativo estiver sendo gerado, selecione "não aplicável" (N/A). [build_standard_variables]
    Deve ser fácil habilitar recursos especiais de compilação como Address Sanitizer (ASAN), ou cumprir as melhores práticas de proteção de distribuição (por exemplo, ativando facilmente flags de compilador para fazê-lo).

    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.



    O sistema de compilação e instalação DEVERIA preservar informações de depuração se elas forem solicitadas nas flags relevantes (por exemplo, "install -s" não é usado). Se não houver sistema de compilação ou instalação (por exemplo, bibliotecas JavaScript típicas), selecione "não aplicável" (N/A). [build_preserve_debug]
    Por exemplo, definir CFLAGS (C) ou CXXFLAGS (C++) deve criar as informações de depuração relevantes se essas linguagens forem usadas, e elas não devem ser removidas durante a instalação. Informações de depuração são necessárias para suporte e análise, e também úteis para medir a presença de recursos de proteção nos binários compilados.

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



    O sistema de compilação do software produzido pelo projeto NÃO DEVE compilar recursivamente subdiretórios se houver dependências cruzadas nos subdiretórios. Se não houver sistema de compilação ou instalação (por exemplo, bibliotecas JavaScript típicas), selecione "não aplicável" (N/A). [build_non_recursive]
    As informações de dependência interna do sistema de compilação do projeto precisam ser precisas, caso contrário, mudanças no projeto podem não compilar corretamente. Compilações incorretas podem levar a defeitos (incluindo vulnerabilidades). Um erro comum em sistemas de compilação grandes é usar uma "compilação recursiva" ou "make recursivo", isto é, uma hierarquia de subdiretórios contendo arquivos fonte, onde cada subdiretório é compilado independentemente. A menos que cada subdiretório seja totalmente independente, isso é um erro, porque as informações de dependência estão incorretas.

    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.



    O projeto DEVE ser capaz de repetir o processo de geração de informações a partir de arquivos fonte e obter exatamente o mesmo resultado bit a bit. Se nenhuma compilação ocorrer (por exemplo, linguagens de script onde o código fonte é usado diretamente em vez de ser compilado), selecione "não aplicável" (N/A). [build_repeatable]
    Usuários de GCC e clang podem achar útil a opção -frandom-seed; em alguns casos, isso pode ser resolvido forçando algum tipo de ordenação. Mais sugestões podem ser encontradas no site reproducible build.

    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.


  • Sistema de instalação


    O projeto DEVE fornecer uma maneira de instalar e desinstalar facilmente o software produzido pelo projeto usando uma convenção comumente utilizada. [installation_common]
    Exemplos incluem usar um gerenciador de pacotes (no nível do sistema ou da linguagem), "make install/uninstall" (suportando DESTDIR), um contêiner em formato padrão, ou uma imagem de máquina virtual em formato padrão. O processo de instalação e desinstalação (por exemplo, seu empacotamento) PODE ser implementado por terceiros, desde que seja FLOSS.

    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).



    O sistema de instalação para usuários finais DEVE honrar convenções padrão para selecionar o local onde os artefatos compilados são escritos no momento da instalação. Por exemplo, se instalar arquivos em um sistema POSIX, ele DEVE honrar a variável de ambiente DESTDIR. Se não houver sistema de instalação ou convenção padrão, selecione "não aplicável" (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.



    O projeto DEVE fornecer uma maneira para desenvolvedores em potencial instalarem rapidamente todos os resultados do projeto e ambiente de suporte necessário para fazer alterações, incluindo os testes e ambiente de teste. Isso DEVE ser realizado com uma convenção comumente utilizada. [installation_development_quick]
    Isso PODE ser implementado usando um contêiner gerado e/ou script(s) de instalação. Dependências externas normalmente seriam instaladas invocando gerenciador(es) de pacotes do sistema e/ou da linguagem, conforme 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]


  • Componentes mantidos externamente


    O projeto DEVE listar dependências externas de uma forma processável por computador. (URL obrigatória) [external_dependencies]
    Tipicamente isso é feito usando as convenções do gerenciador de pacotes e/ou sistema de compilação. Note que isso ajuda a implementar 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]



    Os projetos DEVEM monitorar ou verificar periodicamente suas dependências externas (incluindo cópias de conveniência) para detectar vulnerabilidades conhecidas, e corrigir vulnerabilidades exploráveis ou verificá-las como não exploráveis. [dependency_monitoring]
    Isso pode ser feito usando uma ferramenta de análise de origem / ferramenta de verificação de dependências / ferramenta de análise de composição de software como OWASP's Dependency-Check, Sonatype's Nexus Auditor, Synopsys' Black Duck Software Composition Analysis e Bundler-audit (para Ruby). Alguns gerenciadores de pacotes incluem mecanismos para fazer isso. É aceitável se a vulnerabilidade dos componentes não puder ser explorada, mas esta análise é difícil e às vezes é mais fácil simplesmente atualizar ou corrigir a parte.

    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.



    "O projeto DEVE:
    1. facilitar a identificação e atualização de componentes mantidos externamente reutilizados; ou
    2. usar os componentes padrão fornecidos pelo sistema ou linguagem de programação.
    Então, se uma vulnerabilidade for encontrada em um componente reutilizado, será fácil atualizar esse componente." [updateable_reused_components]
    Uma maneira típica de atender a este critério é usar sistemas de gerenciamento de pacotes do sistema e da linguagem de programação. Muitos programas FLOSS são distribuídos com "bibliotecas de conveniência" que são cópias locais de bibliotecas padrão (possivelmente bifurcadas). Por si só, isso é bom. No entanto, se o programa *deve* usar essas cópias locais (bifurcadas), então atualizar as bibliotecas "padrão" como uma atualização de segurança deixará essas cópias adicionais ainda vulneráveis. Isso é especialmente um problema para sistemas baseados em nuvem; se o provedor de nuvem atualizar suas bibliotecas "padrão", mas o programa não as usar, então as atualizações na verdade não ajudam. Veja, por exemplo, "Chromium: Why it isn't in Fedora yet as a proper package" by Tom Callaway.

    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]



    O projeto DEVERIA evitar usar funções e APIs obsoletas ou desatualizadas onde alternativas FLOSS estejam disponíveis no conjunto de tecnologia que usa (sua "pilha de tecnologia") e para uma supermaioria dos usuários que o projeto suporta (para que os usuários tenham acesso pronto à alternativa). [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.


  • Conjunto de testes automatizados


    Uma suíte de testes automatizada DEVE ser aplicada a cada check-in em um repositório compartilhado para pelo menos um branch. Esta suíte de testes DEVE produzir um relatório sobre sucesso ou falha do teste. [automated_integration_testing]
    Este requisito pode ser visto como um subconjunto de test_continuous_integration, mas focado apenas em testes, sem exigir integração contínua.

    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]



    O projeto DEVE adicionar testes de regressão a uma suíte de testes automatizada para pelo menos 50% dos bugs corrigidos nos últimos seis meses. [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.



    O projeto DEVE ter suíte(s) de teste automatizada(s) FLOSS que forneçam pelo menos 80% de cobertura de instruções se houver pelo menos uma ferramenta FLOSS que possa medir este critério na linguagem selecionada. [test_statement_coverage80]
    Muitas ferramentas FLOSS estão disponíveis para medir cobertura de testes, incluindo gcov/lcov, Blanket.js, Istanbul, JCov e covr (R). Note que atender a este critério não é uma garantia de que a suíte de testes seja completa, em vez disso, falhar em atender a este critério é um forte indicador de uma suíte de testes pobre.

    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.


  • Teste de novas funcionalidades


    O projeto DEVE ter uma política escrita formal de que, à medida que uma nova funcionalidade importante é adicionada, testes para a nova funcionalidade DEVEM ser adicionados a uma suíte de testes automatizada. [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.



    O projeto DEVE incluir, em suas instruções documentadas para propostas de mudança, a política de que testes devem ser adicionados para novas funcionalidades importantes. [tests_documented_added]
    Contudo, mesmo uma regra informal é aceitável desde que os testes estejam sendo adicionados na prática.

    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.


  • Sinalizadores de aviso


    Os projetos DEVEM ser maximamente rigorosos com avisos no software produzido pelo projeto, onde for prático. [warnings_strict]
    Alguns avisos não podem ser efetivamente habilitados em alguns projetos. O que é necessário é evidência de que o projeto está se esforçando para habilitar flags de avisos onde puder, de forma que erros sejam detectados cedo.

    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).


 Segurança 13/13

  • Conhecimento de desenvolvimento seguro


    O projeto DEVE implementar princípios de projeto seguro (de "know_secure_design"), quando aplicável. Se o projeto não está produzindo software, selecione "não aplicável" (N/A). [implement_secure_design]
    Por exemplo, os resultados do projeto devem ter padrões à prova de falhas (decisões de acesso devem negar por padrão, e a instalação dos projetos deve ser segura por padrão). Eles também devem ter mediação completa (todo acesso que possa ser limitado deve ser verificado quanto à autoridade e não ser contornável). Note que em alguns casos os princípios entrarão em conflito, caso em que uma escolha deve ser feita (por exemplo, muitos mecanismos podem tornar as coisas mais complexas, contrariando a "economia de mecanismo" / mantenha simples).

    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.


  • Usar práticas criptográficas boas e básicas

    Observe que alguns softwares não precisam usar mecanismos criptográficos. Se o seu projeto produzir software que (1) inclui, ativa ou habilita funcionalidade de criptografia, e (2) pode ser liberado dos Estados Unidos (EUA) para fora dos EUA ou para um não cidadão dos EUA, você pode ser legalmente obrigado a tomar algumas etapas extras. Normalmente isso envolve apenas o envio de um e-mail. Para mais informações, consulte a seção de criptografia de Understanding Open Source Technology & US Export Controls.

    Os mecanismos de segurança padrão dentro do software produzido pelo projeto NÃO DEVEM depender de algoritmos criptográficos ou modos com fraquezas sérias conhecidas (por exemplo, o algoritmo de hash criptográfico SHA-1 ou o modo CBC em SSH). [crypto_weaknesses]
    Preocupações sobre o modo CBC em SSH são discutidas em CERT: SSH CBC vulnerability.

    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.



    O projeto DEVERIA suportar múltiplos algoritmos criptográficos, para que os usuários possam mudar rapidamente se um for quebrado. Algoritmos de chave simétrica comuns incluem AES, Twofish e Serpent. Alternativas comuns de algoritmos de hash criptográfico incluem SHA-2 (incluindo SHA-224, SHA-256, SHA-384 E SHA-512) e 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.



    O projeto DEVE suportar o armazenamento de credenciais de autenticação (como senhas e tokens dinâmicos) e chaves criptográficas privadas em arquivos que são separados de outras informações (como arquivos de configuração, bancos de dados e logs), e permitir que os usuários as atualizem e substituam sem recompilação de código. Se o projeto nunca processar credenciais de autenticação e chaves criptográficas privadas, selecione "não aplicável" (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.



    O software produzido pelo projeto DEVERIA suportar protocolos seguros para todas as suas comunicações de rede, como SSHv2 ou posterior, TLS1.2 ou posterior (HTTPS), IPsec, SFTP e SNMPv3. Protocolos inseguros como FTP, HTTP, telnet, SSLv3 ou anterior, e SSHv1 DEVERIAM estar desabilitados por padrão, e apenas habilitados se o usuário configurá-lo especificamente. Se o software produzido pelo projeto não suportar comunicações de rede, selecione "não aplicável" (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.



    O software produzido pelo projeto DEVERIA, se suportar ou usar TLS, suportar pelo menos a versão TLS 1.2. Observe que o predecessor do TLS era chamado SSL. Se o software não usar TLS, selecione "não aplicável" (N/A). [crypto_tls12]

    No TLS use. Mark N/A.



    O software produzido pelo projeto DEVE, se suportar TLS, realizar a verificação de certificado TLS por padrão ao usar TLS, incluindo em sub-recursos. Se o software não usar TLS, selecione "não aplicável" (N/A). [crypto_certificate_verification]
    Observe que a verificação incorreta de certificado TLS é um erro comum. Para mais informações, consulte "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" por Martin Georgiev et al. e "Do you trust this application?" por Michael Catanzaro.

    No TLS use. Mark N/A.



    O software produzido pelo projeto DEVE, se suportar TLS, realizar a verificação de certificado antes de enviar cabeçalhos HTTP com informações privadas (como cookies seguros). Se o software não usar TLS, selecione "não aplicável" (N/A). [crypto_verification_private]

    No TLS use. Mark N/A.


  • Lançamento seguro


    O projeto DEVE assinar criptograficamente os lançamentos dos resultados do projeto destinados ao uso generalizado, e DEVE haver um processo documentado explicando aos usuários como eles podem obter as chaves públicas de assinatura e verificar a(s) assinatura(s). A chave privada para essa(s) assinatura(s) NÃO DEVE estar em site(s) usado(s) para distribuir diretamente o software ao público. Se os lançamentos não forem destinados ao uso generalizado, selecione "não aplicável" (N/A). [signed_releases]
    Os resultados do projeto incluem tanto o código-fonte quanto quaisquer entregáveis gerados quando aplicável (por exemplo, executáveis, pacotes e contêineres). Os entregáveis gerados PODEM ser assinados separadamente do código-fonte. Estes PODEM ser implementados como tags git assinadas (usando assinaturas digitais criptográficas). Os projetos PODEM fornecer resultados gerados separadamente de ferramentas como git, mas nesses casos, os resultados separados DEVEM ser assinados separadamente.

    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]



    É SUGERIDO que no sistema de controle de versão, cada tag de versão importante (uma tag que faz parte de um lançamento principal, lançamento menor ou corrige vulnerabilidades publicamente observadas) seja criptograficamente assinada e verificável conforme descrito em 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.


  • Outras questões de segurança


    Os resultados do projeto DEVEM verificar todas as entradas de fontes potencialmente não confiáveis para garantir que sejam válidas (uma *lista de permissões*), e rejeitar entradas inválidas, se houver quaisquer restrições sobre os dados. [input_validation]
    Observe que comparar a entrada com uma lista de "formatos inválidos" (também conhecida como *lista de negação*) normalmente não é suficiente, porque os atacantes muitas vezes podem contornar uma lista de negação. Em particular, os números são convertidos em formatos internos e então verificados se estão entre o mínimo e o máximo (inclusive), e as strings de texto são verificadas para garantir que sejam padrões de texto válidos (por exemplo, UTF-8 válido, comprimento, sintaxe, etc.). Alguns dados podem precisar ser "qualquer coisa" (por exemplo, um carregador de arquivos), mas estes normalmente seriam raros.

    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.



    Mecanismos de proteção DEVERIAM ser usados no software produzido pelo projeto para que defeitos de software tenham menos probabilidade de resultar em vulnerabilidades de segurança. [hardening]
    Os mecanismos de proteção podem incluir cabeçalhos HTTP como Content Security Policy (CSP), flags de compilador para mitigar ataques (como -fstack-protector), ou flags de compilador para eliminar comportamento indefinido. Para nossos propósitos, o privilégio mínimo não é considerado um mecanismo de proteção (privilégio mínimo é importante, mas separado).

    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.



    O projeto DEVE fornecer um caso de garantia que justifique por que seus requisitos de segurança são atendidos. O caso de garantia DEVE incluir: uma descrição do modelo de ameaças, identificação clara dos limites de confiança, um argumento de que os princípios de projeto seguro foram aplicados e um argumento de que fraquezas comuns de segurança na implementação foram combatidas. (URL obrigatória) [assurance_case]
    Um caso de garantia é "um corpo documentado de evidências que fornece um argumento convincente e válido de que um conjunto específico de reivindicações críticas sobre as propriedades de um sistema são adequadamente justificadas para uma dada aplicação em um dado ambiente" ("Software Assurance Using Structured Assurance Case Models", Thomas Rhodes et al, NIST Interagency Report 7608). Limites de confiança são fronteiras onde os dados ou a execução muda seu nível de confiança, por exemplo, os limites de um servidor em uma aplicação web típica. É comum listar princípios de projeto seguro (como Saltzer e Schroeer) e fraquezas comuns de segurança na implementação (como o OWASP top 10 ou CWE/SANS top 25), e mostrar como cada um é combatido. O caso de garantia do BadgeApp pode ser um exemplo útil. Isso está relacionado a documentation_security, documentation_architecture e 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]


 Análise 2/2

  • Análise estática de código


    O projeto DEVE usar pelo menos uma ferramenta de análise estática com regras ou abordagens para procurar vulnerabilidades comuns na linguagem ou ambiente analisado, se houver pelo menos uma ferramenta FLOSS que possa implementar este critério na linguagem selecionada. [static_analysis_common_vulnerabilities]
    Ferramentas de análise estática que são especificamente projetadas para procurar vulnerabilidades comuns são mais propensas a encontrá-las. Dito isso, usar quaisquer ferramentas estáticas normalmente ajudará a encontrar alguns problemas, então estamos sugerindo mas não exigindo isso para o nível de selo 'passing'.

    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).


  • Análise dinâmica de código


    Se o software produzido pelo projeto incluir software escrito usando uma linguagem insegura em memória (por exemplo, C ou C++), então pelo menos uma ferramenta dinâmica (por exemplo, um fuzzer ou scanner de aplicação web) DEVE ser rotineiramente usada em combinação com um mecanismo para detectar problemas de segurança de memória, como estouros de buffer. Se o projeto não produzir software escrito em uma linguagem insegura em memória, escolha "não aplicável" (N/A). [dynamic_analysis_unsafe]
    Exemplos de mecanismos para detectar problemas de segurança de memória incluem Address Sanitizer (ASAN) (disponível no GCC e LLVM), Memory Sanitizer e valgrind. Outras ferramentas potencialmente usadas incluem thread sanitizer e undefined behavior sanitizer. Assertivas generalizadas também funcionariam.

    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.



Estes dados estão disponíveis sob o Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Isso significa que um Destinatário de Dados pode compartilhar os Dados, com ou sem modificações, desde que o Destinatário de Dados disponibilize o texto deste acordo com os Dados compartilhados. Por favor, dê crédito a Todd Matens e aos contribuidores do selo de melhores práticas OpenSSF.

Entrada de selo do projeto de propriedade de: Todd Matens.
Entrada criada em 2026-04-12 08:08:52 UTC, última atualização em 2026-05-03 00:49:57 UTC. Selo de aprovação alcançado pela última vez em 2026-04-19 05:15:06 UTC.