BadgeApp

Fundamentos

Geral

Qual é o nome legível do projeto?
Observe que outros projetos podem usar o mesmo nome.

Qual é uma breve descrição do projeto?

Package manager for AI coding skills — search, install, and sync SKILL.md skills across Claude Code, Windsurf, and Cursor

Qual é a URL do projeto (como um todo)?
https://jonnyeclectic.github.io/boost

Qual é a URL do repositório de controle de versão (pode ser a mesma URL do projeto)?
https://github.com/jonnyeclectic/boost

Sob qual(is) licença(s) o projeto é liberado?
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.

Qual(is) linguagem(ns) de programação são usadas para implementar o projeto?
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".

Qual é o nome Common Platform Enumeration (CPE) do projeto (se houver um)?
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.

Outros comentários gerais sobre o projeto:

Controles 19/21 ●

Controles

Criterion [OSPS-AC-04.02]
Atendido

Não atendido

N/A

?

Quando um trabalho recebe permissões em um pipeline de CI/CD, o código-fonte ou configuração DEVE atribuir apenas os privilégios mínimos necessários para a atividade correspondente. ^{[OSPS-AC-04.02]}
Configure os pipelines de CI/CD do projeto para atribuir as menores permissões disponíveis a usuários e serviços por padrão, elevando as permissões apenas quando necessário para tarefas específicas. Em alguns sistemas de controle de versão, isso pode ser possível no nível organizacional ou de repositório. Se não, defina permissões no nível superior do pipeline.

Least privilege is the default and it is audited. Every workflow declares a permissions: block; ci.yml and publish.yml default to contents: read at workflow level and grant write scopes only on the single job that needs them (publish.yml's guard job holds contents: read while the release job holds the write scopes and the PyPI Trusted-Publishing OIDC). zizmor's excessive-permissions audit runs as a required check on every pull request, so a job granted more than it needs fails the build rather than merging. https://github.com/jonnyeclectic/boost/blob/main/.github/workflows/publish.yml

Criterion [OSPS-BR-01.04]
Atendido

Não atendido

N/A

?

Os pipelines de CI/CD que aceitam entradas de colaboradores confiáveis DEVEM sanitizar e validar essas entradas antes de usá-las no pipeline. ^{[OSPS-BR-01.04]}
Os pipelines de CI/CD devem sanitizar (citar, escapar ou sair com valores esperados) todas as entradas de colaboradores em execuções explícitas de workflow. Embora os colaboradores sejam geralmente confiáveis, as entradas manuais em um workflow não podem ser revisadas e podem ser abusadas por uma tomada de conta ou ameaça interna.

No workflow uses pull_request_target, so a fork's pull request runs with a read-only token and no secret access. Secrets are bound at job level and never interpolated into a run: block. Three checks enforce this rather than convention: zizmor (template-injection and dangerous-triggers audits, with every suppression documented by reason in .github/zizmor.yml), actionlint, and shellcheck — which actionlint shells out to, and which is pinned in the lint toolchain precisely because actionlint silently skips every run: block when shellcheck is absent and still exits 0. Documented in SECURITY.md: https://github.com/jonnyeclectic/boost/blob/main/SECURITY.md#secrets-and-credentials

Criterion [OSPS-BR-02.02]
Atendido

Não atendido

N/A

?

Quando um lançamento oficial for criado, todos os ativos dentro desse lançamento DEVEM estar claramente associados ao identificador de lançamento ou outro identificador único para o ativo. ^{[OSPS-BR-02.02]}
Atribua um identificador de versão único a cada ativo de software produzido pelo projeto, seguindo uma convenção de nomenclatura ou esquema de numeração consistente. Exemplos incluem SemVer, CalVer ou id de commit do git.

Versions come from setuptools-scm reading git tags, so there is no hand-maintained version constant to fall out of sync and a version is unique by construction. 'boost --version' reports it. [version_unique]

Criterion [OSPS-BR-07.02]
Atendido

Não atendido

N/A

?

O projeto DEVE definir uma política para gerenciar segredos e credenciais usadas pelo projeto. A política deve incluir diretrizes para armazenar, acessar e rotacionar segredos e credenciais. ^{[OSPS-BR-07.02]}
Documente como segredos e credenciais são gerenciados e usados dentro do projeto. Isso deve incluir detalhes sobre como os segredos são armazenados (por exemplo, usando uma ferramenta de gerenciamento de segredos), como o acesso é controlado e como os segredos são rotacionados ou atualizados. Certifique-se de que informações sensíveis não sejam codificadas diretamente no código-fonte ou armazenadas em sistemas de controle de versão.

SECURITY.md § Secrets and credentials is the policy, covering storage, access and rotation: releases use no stored token (PyPI Trusted Publishing mints a short-lived OIDC identity, so there is nothing to rotate or steal); every secret that does exist is optional and every job reading one skips itself when absent; secrets never reach untrusted code; an optional token is rotated on suspicion of exposure or when the holder's access is removed, revoked at the issuing service before being replaced or deleted; and gitleaks fails the build on a committed secret. MAINTAINERS.md carries the table of who holds which credential. https://github.com/jonnyeclectic/boost/blob/main/SECURITY.md#secrets-and-credentials

Criterion [OSPS-DO-03.01]
Atendido

Não atendido

N/A

?

Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE conter instruções para verificar a integridade e autenticidade dos ativos de lançamento. ^{[OSPS-DO-03.01]}
As instruções no projeto devem conter informações sobre a tecnologia usada, os comandos a serem executados e a saída esperada. Quando possível, evite armazenar essa documentação no mesmo local que o pipeline de construção e lançamento para evitar que uma única violação comprometa tanto o software quanto a documentação para verificar a integridade do software.

Every release is signed with SLSA build provenance at build time. publish.yml runs actions/attest-build-provenance over dist/* after 'twine check' and before the PyPI upload, so the exact bytes published are the bytes signed, and the attestation records which workflow built which artifact from which commit. Upload to PyPI additionally uses Trusted Publishing (a short-lived OIDC identity, no stored token). A CycloneDX SBOM is generated per released wheel and attached to the GitHub release. Verification instructions: https://github.com/jonnyeclectic/boost/blob/main/docs/verifying-releases.md [osps_br_06_01] [signed_releases]

Criterion [OSPS-DO-03.02]
Atendido

Não atendido

N/A

?

Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE conter instruções para verificar a identidade esperada da pessoa ou processo que criou o lançamento de software. ^{[OSPS-DO-03.02]}
A identidade esperada pode estar na forma de IDs de chave usados para assinar, emissor e identidade de um certificado sigstore ou outras formas similares. Quando possível, evite armazenar essa documentação no mesmo local que o pipeline de construção e lançamento para evitar que uma única violação comprometa tanto o software quanto a documentação para verificar a integridade do software.

Every release is signed with SLSA build provenance at build time. publish.yml runs actions/attest-build-provenance over dist/* after 'twine check' and before the PyPI upload, so the exact bytes published are the bytes signed, and the attestation records which workflow built which artifact from which commit. Upload to PyPI additionally uses Trusted Publishing (a short-lived OIDC identity, no stored token). A CycloneDX SBOM is generated per released wheel and attached to the GitHub release. Verification instructions: https://github.com/jonnyeclectic/boost/blob/main/docs/verifying-releases.md [osps_br_06_01] [signed_releases]

Criterion [OSPS-DO-04.01]
Atendido

Não atendido

N/A

?

Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE incluir uma declaração descritiva sobre o escopo e a duração do suporte para cada lançamento. ^{[OSPS-DO-04.01]}
Para comunicar o escopo e a duração do suporte para os ativos de software lançados pelo projeto, o projeto deve ter um arquivo SUPPORT.md, uma seção "Support" em SECURITY.md ou outra documentação explicando o ciclo de vida do suporte, incluindo a duração esperada de suporte para cada lançamento, os tipos de suporte fornecidos (por exemplo, correções de bugs, atualizações de segurança) e quaisquer políticas ou procedimentos relevantes para obter suporte.

SUPPORT.md § What is supported states the scope and duration plainly: only the latest release is supported, there are no backport branches and no long-term-support line, and the supported answer for an older version is to upgrade. It also names the supported environments (operating systems and Python versions), which are exactly what CI runs on every pull request, and states that Python 3.11 and earlier are not supported. https://github.com/jonnyeclectic/boost/blob/main/SUPPORT.md#what-is-supported

Criterion [OSPS-DO-05.01]
Atendido

Não atendido

N/A

?

Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE fornecer uma declaração descritiva de quando lançamentos ou versões não receberão mais atualizações de segurança. ^{[OSPS-DO-05.01]}
Para comunicar o escopo e a duração do suporte para correções de segurança, o projeto deve ter um SUPPORT.md ou outra documentação explicando a política do projeto para atualizações de segurança.

SUPPORT.md § When a version stops receiving security updates answers it in one line: the moment a newer release exists. boost cuts a release on every merge to main, so maintaining an older supported line would mean supporting hundreds of versions, and the document says so rather than implying a support window it does not offer. If a release fixes a publicly known vulnerability the release notes name it. https://github.com/jonnyeclectic/boost/blob/main/SUPPORT.md#when-a-version-stops-receiving-security-updates

Criterion [OSPS-GV-04.01]
Atendido

Não atendido

N/A

?

Enquanto ativo, a documentação do projeto DEVE ter uma política de que colaboradores de código sejam revisados antes de conceder permissões elevadas a recursos sensíveis. ^{[OSPS-GV-04.01]}
Publique uma política aplicável na documentação do projeto que exija que colaboradores de código sejam revisados e aprovados antes de receberem permissões elevadas a recursos sensíveis, como aprovação de merge ou acesso a segredos. É recomendado que a verificação inclua estabelecer uma linhagem justificável de identidade, como confirmar a associação do contribuidor com uma organização confiável conhecida.

MAINTAINERS.md § Becoming a maintainer is the published policy, and step 2 is the criterion: 'Review before the grant — the lead maintainer reviews that history and proposes the change in a public issue, naming the scope of access being granted and why. Existing maintainers may object there.' It also requires a track record first, least privilege at the grant (write access is a separate decision from repository administration, which is separate again from anything touching the release path), and that the file is updated in the same change — an access grant not recorded there has not happened. The same review applies when an existing maintainer is given more access. https://github.com/jonnyeclectic/boost/blob/main/MAINTAINERS.md#becoming-a-maintainer

Criterion [OSPS-QA-02.02]
Atendido

Não atendido

N/A

?

Quando o projeto tiver feito um lançamento, todos os ativos de software compilados lançados DEVEM ser entregues com uma lista de materiais de software. ^{[OSPS-QA-02.02]}
É recomendado gerar automaticamente SBOMs no momento da compilação usando uma ferramenta que foi verificada quanto à precisão. Isso permite que os usuários ingiram esses dados de forma padronizada junto com outros projetos em seu ambiente.

Every release carries a CycloneDX SBOM, generated at build time by .github/workflows/sbom.yml and attached to the GitHub Release as boost-sbom.cdx.json. Verified rather than assumed: the three most recent releases (v1.2.31, v1.2.30, v1.2.29) each carry that asset. Worth stating because this control was inert for 253 releases — it was triggered by release: [published], an event created with GITHUB_TOKEN, which never chains to another workflow; it now runs on workflow_run after the release workflow. https://github.com/jonnyeclectic/boost/releases

Criterion [OSPS-QA-04.02]
Atendido

Não atendido

N/A

?

Quando o projeto tiver feito um lançamento compreendendo múltiplos repositórios de código-fonte, todos os subprojetos DEVEM impor requisitos de segurança que sejam tão rigorosos ou mais rigorosos que a base de código principal. ^{[OSPS-QA-04.02]}
Quaisquer repositórios de código de subprojeto adicionais produzidos pelo projeto e compilados em um lançamento devem impor requisitos de segurança conforme aplicável ao status e intenção da respectiva base de código. Além de seguir os requisitos correspondentes da Linha de Base OSPS, isso pode incluir exigir uma revisão de segurança, garantir que esteja livre de vulnerabilidades e garantir que esteja livre de problemas de segurança conhecidos.

boost is a single source-code repository. A release comprises one repository and has no subprojects, so there is no second codebase whose security requirements could be weaker. https://github.com/jonnyeclectic/boost

Criterion [OSPS-QA-06.02]
Atendido

Não atendido

N/A

?

Enquanto ativo, a documentação do projeto DEVE documentar claramente quando e como os testes são executados. ^{[OSPS-QA-06.02]}
Adicione uma seção à documentação de contribuição que explique como executar os testes localmente e como executar os testes no pipeline de CI/CD. A documentação deve explicar o que os testes estão testando e como interpretar os resultados.

Four tiers: tests/unit and tests/functional (pytest; the functional suite drives the real CLI in-process), tests/smoke.sh (170 end-to-end checks through the ./boost shim), and a Gherkin BDD suite of 11 features / 47 scenarios. [test]

Criterion [OSPS-QA-06.03]
Atendido

Não atendido

N/A

?

Enquanto ativo, a documentação do projeto DEVE incluir uma política de que todas as mudanças importantes no software produzido pelo projeto devem adicionar ou atualizar testes da funcionalidade em um conjunto de testes automatizados. ^{[OSPS-QA-06.03]}
Adicione uma seção à documentação de contribuição que explique a política para adicionar ou atualizar testes. A política deve explicar o que constitui uma mudança importante e quais testes devem ser adicionados ou atualizados.

The policy is mandated by automation rather than by convention, which is the stronger form. CONTRIBUTING.md states that behaviour changes need tests and that anything under boost_cli/core is mutation-tested; the changed-line coverage gate and the mutation gate then enforce it as required status checks, so a change adding major functionality without tests cannot be merged into main even by the maintainer - main is protected and takes changes only through a pull request that has passed the full gate. [test_policy_mandated]

Criterion [OSPS-QA-07.01]
Atendido

Não atendido

N/A

?

Quando um commit for feito no branch principal, o sistema de controle de versão do projeto DEVE exigir pelo menos uma aprovação humana não-autora das mudanças antes do merge. ^{[OSPS-QA-07.01]}
Configure o sistema de controle de versão do projeto para exigir pelo menos uma aprovação humana não-autora das mudanças antes de fazer merge no branch de lançamento ou principal. Isso pode ser alcançado exigindo que um pull request seja revisado e aprovado por pelo menos um outro colaborador antes que possa ser feito o merge.

boost has one maintainer (MAINTAINERS.md states this plainly rather than implying a committee), so there is no non-author human who could approve a change. The main branch ruleset requires a pull request and requires 21 named status checks to pass before merging, but it cannot require an approval that nobody is available to give. This is the same single fact behind the OpenSSF passing-level two_person_review, bus_factor and contributors_unassociated criteria, all also answered Unmet. It is a recruiting problem rather than a configuration one, and configuring a second account to supply the approval would defeat the criterion rather than satisfy it. https://github.com/jonnyeclectic/boost/blob/main/docs/code-review.md

Criterion [OSPS-SA-03.02]
Atendido

Não atendido

N/A

?

Quando o projeto tiver feito um lançamento, o projeto DEVE realizar uma modelagem de ameaças e análise de superfície de ataque para entender e proteger contra ataques em caminhos de código críticos, funções e interações dentro do sistema. ^{[OSPS-SA-03.02]}
Modelagem de ameaças é uma atividade onde o projeto analisa a base de código, processos e infraestrutura associados, interfaces, componentes-chave e "pensa como um hacker" e faz um brainstorming de como o sistema pode ser quebrado ou comprometido. Cada ameaça identificada é listada para que o projeto possa então pensar em como evitar proativamente ou fechar quaisquer lacunas/vulnerabilidades que possam surgir. Certifique-se de que isso seja atualizado para novos recursos ou mudanças críticas.

https://github.com/jonnyeclectic/boost/blob/main/docs/security-design.md is that assessment. It identifies the most likely and impactful problems for a CLI that clones third-party repositories and writes files into the directories an AI agent reads - path traversal via attacker-controlled frontmatter, command injection through skill and tap names, archive extraction escapes, link following, untrusted deserialization, supply-chain and CI-action compromise - and pairs each with the mitigation in the codebase. It also states the residual risks plainly, including the most important one: boost can give provenance, integrity and a diff, but cannot vet what a skill instructs an agent to do. [osps_sa_03_01] [assurance_case]

Criterion [OSPS-VM-04.02]
Atendido

Não atendido

N/A

?

Enquanto ativo, quaisquer vulnerabilidades nos componentes de software que não afetam o projeto DEVEM ser contabilizadas em um documento VEX, aumentando o relatório de vulnerabilidade com detalhes de não-explorabilidade. ^{[OSPS-VM-04.02]}
Estabeleça um feed VEX comunicando o status de explorabilidade de vulnerabilidades conhecidas, incluindo detalhes de avaliação ou quaisquer mitigações em vigor impedindo que código vulnerável seja executado.

boost does not publish a VEX feed. Non-exploitable findings are triaged and suppressed with a recorded reason in the tool that raised them — CodeQL dismissals carry a written justification, .github/zizmor.yml documents every suppression by reason, and the gitleaks allowlist covers only boost's own synthetic scanner test fixtures — but that is not a machine-readable VEX document a consumer could ingest, and answering Met on the strength of it would overstate what exists.

Criterion [OSPS-VM-05.01]
Atendido

Não atendido

N/A

?

Enquanto ativo, a documentação do projeto DEVE incluir uma política que defina um limite para remediação de descobertas de SCA relacionadas a vulnerabilidades e licenças. ^{[OSPS-VM-05.01]}
Documente uma política no projeto que defina um limite para remediação de descobertas de SCA relacionadas a vulnerabilidades e licenças. Inclua o processo para identificar, priorizar e remediar essas descobertas.

https://github.com/jonnyeclectic/boost/blob/main/docs/dependencies.md documents the monitoring and the thresholds. Dependabot proposes upgrades; pip-audit fails the build when a resolved dependency matches a known OSV or PyPI advisory and also runs on a weekly schedule so a newly published advisory against unchanged code is still caught; OSV-Scanner runs diffed against the base branch and fails on what a pull request adds; a licence gate fails on a licence outside the allowed set; and a CycloneDX SBOM is generated per released wheel. pip-audit and osv-scan are both required checks. The runtime has no third-party dependency to monitor, which is the strongest form of this. [dependency_monitoring]

Criterion [OSPS-VM-05.02]
Atendido

Não atendido

N/A

?

Enquanto ativo, a documentação do projeto DEVE incluir uma política para abordar violações de SCA antes de qualquer lançamento. ^{[OSPS-VM-05.02]}
Documente uma política no projeto para abordar os resultados aplicáveis de Análise de Composição de Software antes de qualquer lançamento, e adicione verificações de status que confirmem a conformidade com essa política antes do lançamento.

https://github.com/jonnyeclectic/boost/blob/main/docs/dependencies.md documents the monitoring and the thresholds. Dependabot proposes upgrades; pip-audit fails the build when a resolved dependency matches a known OSV or PyPI advisory and also runs on a weekly schedule so a newly published advisory against unchanged code is still caught; OSV-Scanner runs diffed against the base branch and fails on what a pull request adds; a licence gate fails on a licence outside the allowed set; and a CycloneDX SBOM is generated per released wheel. pip-audit and osv-scan are both required checks. The runtime has no third-party dependency to monitor, which is the strongest form of this. [dependency_monitoring]

Criterion [OSPS-VM-05.03]
Atendido

Não atendido

N/A

?

Enquanto ativo, todas as alterações na base de código do projeto DEVEM ser automaticamente avaliadas em relação a uma política documentada para dependências maliciosas e vulnerabilidades conhecidas em dependências, e então bloqueadas em caso de violações, exceto quando declaradas e suprimidas como não exploráveis. ^{[OSPS-VM-05.03]}
Crie uma verificação de status no sistema de controle de versão do projeto que execute uma ferramenta de Análise de Composição de Software em todas as alterações na base de código. Exija que a verificação de status seja aprovada antes que as alterações possam ser mescladas.

https://github.com/jonnyeclectic/boost/blob/main/docs/dependencies.md documents the monitoring and the thresholds. Dependabot proposes upgrades; pip-audit fails the build when a resolved dependency matches a known OSV or PyPI advisory and also runs on a weekly schedule so a newly published advisory against unchanged code is still caught; OSV-Scanner runs diffed against the base branch and fails on what a pull request adds; a licence gate fails on a licence outside the allowed set; and a CycloneDX SBOM is generated per released wheel. pip-audit and osv-scan are both required checks. The runtime has no third-party dependency to monitor, which is the strongest form of this. [dependency_monitoring]

Criterion [OSPS-VM-06.01]
Atendido

Não atendido

N/A

?

Enquanto ativo, a documentação do projeto DEVE incluir uma política que defina um limite para remediação de resultados de SAST. ^{[OSPS-VM-06.01]}
Documente uma política no projeto que defina um limite para remediação de resultados de Teste de Segurança de Aplicação Estática (SAST). Inclua o processo para identificar, priorizar e remediar esses resultados.

Findings are fixed, or dismissed with a written proof of why they are false positives - never dismissed for convenience. The project keeps that discipline recorded publicly on its roadmap, including the explicit rule that supply-chain posture metrics must not be filed as false positives just to clear the inbox. [static_analysis_fixed]

Criterion [OSPS-VM-06.02]
Atendido

Não atendido

N/A

?

Enquanto ativo, todas as alterações na base de código do projeto DEVEM ser automaticamente avaliadas em relação a uma política documentada para fraquezas de segurança e bloqueadas em caso de violações, exceto quando declaradas e suprimidas como não exploráveis. ^{[OSPS-VM-06.02]}
Crie uma verificação de status no sistema de controle de versão do projeto que execute uma ferramenta de Teste de Segurança de Aplicação Estática (SAST) em todas as alterações na base de código. Exija que a verificação de status seja aprovada antes que as alterações possam ser mescladas.

Several tools, all required checks, all run before every release - which is every merge to main. CodeQL does semantic analysis on push, on pull request and weekly (https://github.com/jonnyeclectic/boost/blob/main/.github/workflows/codeql.yml). ruff's S/flake8-bandit family is Python SAST covering shell=True, tempfile.mktemp, unsafe YAML loading and weak hashing. mypy and pyright are two independent type checkers, the second adding None-flow and narrowing analysis over core/. zizmor audits the GitHub Actions workflows for excessive permissions and unpinned action refs. import-linter enforces the architectural layering. SonarCloud is additionally wired up as an optional, non-blocking dashboard. [static_analysis]

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 Jonathan Reyes e aos contribuidores do selo de melhores práticas OpenSSF.

boost

Fundamentos

Geral

Controles 19/21 ●

Controles