Skip to main content

​
Objetivo

O CaseBender é usado por equipes de segurança; por isso, a segurança do produto é tratada como um requisito de release, e não como uma lista de verificação pontual. O Programa de Garantia de Segurança combina fluxos de trabalho de desenvolvimento protegidos, testes de segurança automatizados, controles de contêineres e dependências, proveniência de releases, exceções documentadas e planejamento de avaliações independentes. Esta seção explica:
  • quais controles são executados automaticamente;
  • quais descobertas bloqueiam uma alteração ou release;
  • quais evidências cada controle produz;
  • como as exceções são administradas;
  • o que os clientes podem verificar de forma independente; e
  • onde termina a garantia automatizada.
A garantia de segurança reduz riscos; ela não comprova que o software está livre de vulnerabilidades. Badges de workflows, relatórios de scanners, SBOMs e assinaturas são evidências de controles específicos, e não certificações de segurança nem substitutos para um teste de penetração independente.

​
Visão Geral da Garantia

Alterações Protegidas

Os pull requests para branches protegidas passam por um Security Gate agregado antes do merge. Documentação disponível em inglês.

Testes em Camadas

Segredos, código-fonte, dependências, licenças, infraestrutura e todas as imagens de serviço são verificados por ferramentas independentes.

Integridade de Releases

Os workflows de release geram SBOMs, proveniência, digests imutáveis e assinaturas criptográficas. Documentação disponível em inglês.

Evidências para Clientes

Os clientes podem identificar as evidências associadas a um commit, digest de imagem ou release.

​
Ciclo de Vida Seguro das Alterações

Toda alteração proposta segue o mesmo ciclo de vida de alto nível:
Os controles são deliberadamente organizados em camadas. Por exemplo, o risco de dependências é avaliado tanto pelo banco de dados de avisos do gerenciador de pacotes quanto pelo Trivy; as imagens de contêiner são verificadas após a criação; e controles negativos determinísticos verificam se os scanners de segredos e SAST continuam rejeitando fixtures sabidamente inválidas.

​
Quando os Controles São Executados

A definição do workflow, e não esta página, é a fonte técnica definitiva para a configuração exata de gatilhos e ferramentas. Revisores autorizados do repositório podem consultar o workflow Security Scan; clientes sem acesso ao repositório devem usar as evidências específicas da versão descritas no Guia de evidências de segurança.

​
Security Gate com Bloqueio de Merge

O Security Gate agregado exige que os seguintes jobs sejam concluídos com sucesso em pull requests e pushes: O upload dos resultados dos scanners pode ser feito em caráter de melhor esforço quando o GitHub Code Security não está licenciado, mas a verificação local subjacente continua bloqueadora. Os relatórios também são preservados como artefatos do workflow para que o gate não dependa da ingestão de SARIF.

​
Testes Dinâmicos de Segurança

O job semanal de DAST usa o OWASP ZAP em uma implantação de staging dedicada. Antes do início dos testes ativos, a CI verifica:
  1. se o destino não é um placeholder, localhost ou endereço de loopback;
  2. se a resposta identifica uma implantação web do CaseBender;
  3. se a identidade de teste configurada produz uma sessão autenticada; e
  4. se o header de autenticação é fornecido por meio de segredos mascarados do repositório.
A verificação executa testes ativos autenticados e preserva o respectivo relatório. A ausência de destinos ou credenciais faz o job de DAST falhar, em vez de verificar silenciosamente uma página irrelevante. A cobertura de DAST é limitada pelas rotas e pelo estado acessíveis à identidade de teste. Ela não substitui testes manuais de autorização, isolamento entre tenants, abuso de workflows, parsers ou integrações.

​
Garantia de Contêineres

Atualmente, o CaseBender produz sete imagens de serviço. Cada Dockerfile de produção usa um build em múltiplos estágios e um usuário de runtime não root. O processo de garantia de contêineres inclui:
  • lint dos Dockerfiles;
  • remoção de dependências desnecessárias para produção;
  • verificação de vulnerabilidades antes da publicação;
  • detecção de segredos incorporados por meio da verificação de imagens;
  • seleção do digest imutável após a publicação;
  • assinatura sem chave com Cosign por meio da identidade OIDC do GitHub; e
  • verificação da assinatura em relação ao digest exato publicado.
Os workflows do Docker Hub e do GitHub Container Registry assinam o digest obtido pelos clientes, em vez de depender apenas de tags mutáveis, como latest.

​
Evidências da Cadeia de Suprimentos de Software

Os workflows de release geram vários registros complementares:
  • CycloneDX SBOM — inventário de pacotes e componentes para análise de dependências;
  • BuildKit SBOM and provenance — metadados de build emitidos com os builds de contêiner;
  • Cosign signature — identidade criptográfica vinculada a um digest de imagem imutável;
  • SBOM attestation — associação assinada entre uma imagem e seu inventário de componentes;
  • SLSA-format provenance document — revisão do código-fonte, identidade do workflow e metadados de invocação; e
  • Scanner reports — saída SARIF ou JSON retida pelo workflow aplicável.
O documento autônomo no formato SLSA consiste em metadados de build assinados. Seu subject atual está vazio; portanto, ele não está criptograficamente vinculado aos sete digests de imagem e não deve ser apresentado como proveniência no nível do artefato nem como certificação SLSA independente.

​
Tratamento de Vulnerabilidades

As descobertas são triadas de acordo com severidade, explorabilidade, modo de implantação afetado, exposição e disponibilidade de correção. Os objetivos padrão de remediação documentados pelo projeto são: Esses são objetivos internos de remediação, e não níveis de serviço contratuais, a menos que sejam incorporados a um contrato com o cliente. Quando a remediação imediata não é possível, uma exceção deve ser restrita e passível de revisão. As exceções atuais de IaC do Trivy são armazenadas em .trivyignore.yaml e incluem a descoberta, o caminho afetado, a justificativa e a data de expiração. As exceções de licença são específicas de cada pacote; a política não suprime globalmente um identificador de licença. O arquivo do repositório não deve ser interpretado como um registro completo de todas as categorias de risco de produto aceito.

​
Integridade de Ferramentas e Workflows

Os próprios controles também são protegidos:
  • GitHub Actions de terceiros são fixadas em SHAs de commit imutáveis;
  • binários e imagens de contêiner importantes dos scanners são fixados por versão ou digest;
  • instalações baseadas em lockfile usam --frozen-lockfile;
  • controles negativos de segurança detectam quando um scanner inesperadamente deixa de rejeitar uma entrada sabidamente inválida;
  • as configurações atuais de proteção de branches do GitHub rejeitam atualizações diretas que não tenham produzido as verificações de status exigidas; essa política é administrada fora do repositório de código-fonte; e
  • jobs agregados falham se um job de segurança obrigatório falhar, for cancelado ou for inesperadamente ignorado.

​
Heurística Complementar de Malware

Um workflow separado, executado após o merge, monitora alterações nos arquivos de configuração do Next.js e PostCSS em main em busca de padrões maliciosos conhecidos da cadeia de suprimentos npm e pode criar uma reversão automatizada. Esse é um controle restrito de recuperação baseado em padrões. Não é um gate de pull request, mecanismo antivírus, controle de EDR nem verificação abrangente de malware.

​
Responsabilidades do Cliente

O CaseBender pode ser implantado em infraestrutura gerenciada pelo cliente. A garantia do produto não substitui a operação segura desse ambiente. Os clientes continuam responsáveis por:
  • certificados TLS, ingress, firewall e segmentação de rede;
  • configuração do provedor de identidade, MFA e funções;
  • hardening de banco de dados, Redis, armazenamento de objetos e serviço de busca;
  • rotação de segredos e acesso às credenciais de implantação;
  • backups, monitoramento, retenção e resposta a incidentes;
  • aplicação de atualizações compatíveis e revisão das notas de release; e
  • validação dos controles em relação ao ambiente regulatório e de ameaças aplicável.
Consulte o Guia de Hardening de Implantação — disponível em inglês para obter recomendações operacionais.

​
Limites Atuais da Garantia

Em julho de 2026:
  • os workflows automatizados de SAST, SCA, segredos, licenças, IaC, contêineres, SBOM, assinatura e proveniência estão implementados;
  • o DAST autenticado em staging está configurado na CI, mas depende de um destino de staging e de uma identidade de teste mantidos;
  • os recursos SARIF e Dependency Review hospedados no GitHub dependem do licenciamento do repositório, enquanto os gates locais do Trivy e de auditoria de pacotes continuam disponíveis;
  • não se alega a existência de um relatório concluído de teste de penetração por terceiros nem de uma carta de reteste de remediação; e
  • os mapeamentos de conformidade descrevem o alinhamento dos controles, e não uma certificação independente.
O escopo proposto da avaliação independente está documentado em Escopo do Teste de Penetração Independente — disponível em inglês.

​
Documentação Relacionada