> ## Documentation Index > Fetch the complete documentation index at: https://docs.casebender.com/llms.txt > Use this file to discover all available pages before exploring further. # Programa de Garantia de Segurança > Como o CaseBender testa alterações, bloqueia regressões de segurança, protege artefatos de release e comunica evidências de garantia aos clientes. ## 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 Os pull requests para branches protegidas passam por um Security Gate agregado antes do merge. Documentação disponível em inglês. Segredos, código-fonte, dependências, licenças, infraestrutura e todas as imagens de serviço são verificados por ferramentas independentes. Os workflows de release geram SBOMs, proveniência, digests imutáveis e assinaturas criptográficas. Documentação disponível em inglês. 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: ```text theme={null} Developer change → Pull request → Build and functional checks → Parallel security controls → Aggregate Security Gate → Protected-branch review and merge → Pre-publish image scan → Digest-based publication and signing → Deployment readiness verification → Scheduled reassessment ``` 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 | Evento | Atividade de garantia | | ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Pull request para `main` ou `production` | Security Gate completo de código-fonte, dependências, licenças, IaC, Dockerfiles e sete imagens | | Push para `main` | Security Gate, geração de SBOM e workflows de artefatos da branch principal | | Build de contêiner publicado | Verificação de vulnerabilidades antes da publicação, captura de digest imutável, criação de assinatura e verificação de assinatura | | Programação semanal | Workflow de segurança completo e verificação autenticada do ambiente de staging pelo OWASP ZAP quando o destino e a identidade de teste necessários estão configurados | | Atualização de dependência | Aplicam-se os mesmos gates de pull request; o GitHub Dependency Review também é aplicado quando o licenciamento do repositório o permite | 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](https://github.com/casebender/webapp/actions/workflows/security-scan.yml); 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](/pt-BR/security/security-evidence). ## 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: | Controle | Escopo | Condição de bloqueio | | ------------------------ | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | | Gitleaks | Código-fonte atual e histórico completo do Git | Padrão de segredo detectado | | Trivy filesystem scan | Repositório e manifestos de dependências | Vulnerabilidade HIGH ou CRITICAL não aceita e com correção disponível | | Trivy container scan | Imagens de web, API, ingestion, worker, workflow processor, MISP processor e search sync | Vulnerabilidade de imagem HIGH ou CRITICAL não aceita e com correção disponível | | Hadolint | Todos os sete Dockerfiles | Violação da política de Dockerfiles | | Trivy IaC scan | Dockerfiles e configuração do Kubernetes | Configuração incorreta de segurança HIGH ou CRITICAL | | ESLint security rules | TypeScript e JavaScript da aplicação web | Erro de regra de segurança | | Semgrep | Regras de TypeScript, Next.js, OWASP, injection, XSS, secrets e security-audit | Descoberta de severidade ERROR ou falha do scanner | | License policy | Dependências do repositório | Licença bloqueadora não aprovada ou relatório malformado/vazio | | `pnpm audit` | Dependências de produção | Aviso HIGH ou CRITICAL | | SBOM generation | Workspace completo | Falha na geração do CycloneDX | | Security control tests | Fixtures geradas de segredos e código inseguro | O scanner não rejeita uma fixture sabidamente inválida | | GitHub Dependency Review | Delta de dependências do pull request, quando licenciado | Nova vulnerabilidade HIGH/CRITICAL ou licença negada | 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: | Severity | Target | | -------- | -------- | | Critical | 24 horas | | High | 7 dias | | Medium | 30 dias | | Low | 90 dias | 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](/en/security/hardening-guide) 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](/en/security/penetration-test-scope). ## Documentação Relacionada * [Segurança de Código — disponível em inglês](/en/security/code-security) — configuração de scanners, DAST, licenças e gestão de vulnerabilidades * [Segurança da Cadeia de Suprimentos — disponível em inglês](/en/security/supply-chain) — dependências, imagens, SBOMs, assinatura e proveniência * [Guia de Evidências de Segurança](/pt-BR/security/security-evidence) — tipos de evidências e como interpretá-los * [Arquitetura de Segurança — disponível em inglês](/en/security/architecture) — projeto de segurança da aplicação e da implantação * [Escopo do Teste de Penetração Independente — disponível em inglês](/en/security/penetration-test-scope) — cobertura planejada da avaliação manual