Baseline de Segurança do Repositório
O repositório usa controles em camadas para que segurança do código-fonte, risco de dependências, qualidade de código e compatibilidade do pacote sejam avaliados de forma independente.
O GitHub CodeQL Default Setup é a fonte autoritativa de alerts em Security > Code scanning para este repositório.
.github/workflows/codeql.yml complementa o Default Setup validando a análise semântica de C# contra o contrato explícito de build do repositório em pull requests direcionados à main, pushes para main, agendamento semanal e execuções manuais. O workflow usa build manual, o SDK selecionado por global.json e o mesmo contrato de build Release de ComplexityAnalysis.Analyzers.slnx usado pelo CI.
Como o GitHub não processa análises CodeQL de configurações avançadas enquanto o Default Setup está habilitado, o workflow versionado intencionalmente não envia seu SARIF para o Code Scanning. Ele executa a suite padrão de alta precisão, armazena o SARIF gerado como artifact temporário do workflow para diagnóstico/evidência de auditoria e mantém permissões somente leitura com apenas contents: read e security-events: read.
Suites mais amplas podem ser avaliadas depois que os findings iniciais forem compreendidos; novos ruídos não devem ser escondidos apenas para manter a automação verde.
Dependency Review
Seção intitulada “Dependency Review”O Dependency Review é um gate bloqueante de pull request. Ele rejeita novas dependências com vulnerabilidades de severidade high ou superior e, intencionalmente, não usa continue-on-error.
Esse controle avalia o delta de dependências do pull request. Ele complementa, e não substitui, NuGet Audit, Dependabot, SonarQube Cloud, testes do analyzer/pacote e CodeQL.
Dependabot
Seção intitulada “Dependabot”O Dependabot mantém:
- dependências NuGet, incluindo as restrições explícitas de compatibilidade Roslyn do repositório;
- o .NET SDK declarado em
global.json; - referências de GitHub Actions.
Pull requests de atualização automática devem passar pelos mesmos gates aplicáveis de qualidade, compatibilidade, pacote, performance e segurança das mudanças manuais.
Política de supply chain dos workflows
Seção intitulada “Política de supply chain dos workflows”Actions alteradas em trabalhos sensíveis de segurança devem usar SHA completo com comentário legível da versão. Checkouts somente leitura devem desabilitar a persistência de credenciais.
O hardening de workflows não deve renomear jobs obrigatórios sem necessidade. O ruleset ativo depende dos nomes estáveis de checks documentados em quality-gates.md.
Provenance de release e SBOM
Seção intitulada “Provenance de release e SBOM”O workflow Release do analyzer e os workflows independentes Release ComplexityAnalysis.Tool e Release ComplexityAnalysis.Mcp geram uma SBOM SPDX
2.3 a partir do .nupkg exato produzido por seus jobs de build. Cada par
package/SBOM é enviado como um artifact de workflow, e o mesmo .nupkg baixado
é reutilizado para NuGet.org, GitHub Packages, attestations e GitHub Release.
O job github-release usa GitHub OIDC com permissões mínimas de attestation para criar:
- uma attestation de build provenance para o
.nupkgpublicado e sua SBOM SPDX independente; - uma SBOM attestation SPDX cujo subject é o
.nupkgpublicado.
O arquivo independente ComplexityAnalysis.Analyzers.<version>.sbom.spdx.json também é anexado à GitHub Release.
Para verificação byte a byte, use o .nupkg anexado à GitHub Release. Um registry pode adicionar metadados de repository signing após a publicação, alterando legitimamente os bytes do package baixado.
Verifique a build provenance do package da GitHub Release com GitHub CLI:
gh attestation verify ComplexityAnalysis.Analyzers.<version>.nupkg \ --repo rodri-oliveira-dev/complexity-analyzers \ --signer-workflow rodri-oliveira-dev/complexity-analyzers/.github/workflows/release.ymlVerifique explicitamente a SBOM attestation SPDX 2.3 com:
gh attestation verify ComplexityAnalysis.Analyzers.<version>.nupkg \ --repo rodri-oliveira-dev/complexity-analyzers \ --signer-workflow rodri-oliveira-dev/complexity-analyzers/.github/workflows/release.yml \ --predicate-type https://spdx.dev/Document/v2.3As attestations comprovam a procedência dos artifacts e vinculam a SBOM ao digest do package. Elas complementam, e não substituem, testes de package, CodeQL, Dependency Review, NuGet auditing, Trusted Publishing e review humano.
Para a CLI, substitua por ComplexityAnalysis.Tool.<version>.nupkg e pelo
signer workflow
rodri-oliveira-dev/complexity-analyzers/.github/workflows/release-tool.yml nos
comandos de verificação. As tags da CLI usam o namespace independente
tool-v<version>.
Para o MCP, substitua por ComplexityAnalysis.Mcp.<version>.nupkg e pelo signer
workflow
rodri-oliveira-dev/complexity-analyzers/.github/workflows/release-mcp.yml.
As tags MCP usam mcp-v<version>, e suas GitHub Releases não são marcadas como a
release genérica mais recente do repositório.