> ## 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. # Guia de Evidências de Segurança > Um guia para clientes que analisam relatórios de scanners, SBOMs, assinaturas, proveniência, exceções e o status das avaliações do CaseBender. ## Visão Geral As evidências de segurança são mais úteis quando podem ser rastreadas até o software exato que o cliente está avaliando. O CaseBender identifica builds pelo commit do Git e artefatos de contêiner pelo digest imutável. Para uma análise de garantia, comece com um dos seguintes itens: * uma versão de release do CaseBender; * o SHA do commit do Git exibido pela release; * o digest de cada imagem de contêiner implantada; ou * a execução do workflow que produziu os artefatos. Tags como `latest` são referências convenientes, mas não são identificadores estáveis de evidências. ## Catálogo de Evidências | Evidência | O que demonstra | Limitação importante | | ---------------------------------------- | --------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | Resultado do Security Gate | Os jobs de segurança obrigatórios da CI foram concluídos com sucesso para uma revisão | Abrange apenas os controles automatizados configurados | | Relatório/log do Gitleaks | Nenhum padrão de segredo correspondente permaneceu no código-fonte e no histórico verificados | Não consegue identificar todos os formatos possíveis de credenciais | | SARIF do Trivy filesystem | Descobertas de dependências para o estado verificado do repositório | Os bancos de dados de avisos e a detecção de pacotes mudam ao longo do tempo | | SARIF do Trivy container | Descobertas do sistema operacional e da aplicação em uma imagem de serviço criada | Aplica-se apenas ao digest verificado | | SARIF do Trivy IaC | Descobertas na configuração do Docker e do Kubernetes | Não valida todas as configurações da plataforma em runtime | | SARIF do Semgrep | Descobertas das regras configuradas de análise de código-fonte e taint analysis | A cobertura das regras não equivale a uma revisão manual de código | | JSON da auditoria de dependências | Avisos de dependências de produção conhecidos pelo registro de pacotes | Não abrange pacotes do sistema operacional | | JSON de licenças e resultado da política | Licenças detectadas e decisões de política específicas por pacote | A interpretação jurídica continua sendo específica de cada cliente | | CycloneDX SBOM | Componentes detectados em um repositório ou imagem | Uma SBOM é um inventário, e não uma declaração de ausência de vulnerabilidades | | Cosign signature | Uma identidade de workflow assinou um digest de imagem específico | A verificação da assinatura não avalia o comportamento da aplicação | | SBOM attestation | Uma SBOM assinada está associada a uma imagem específica | A attestation é tão precisa quanto a geração da SBOM | | SLSA-format provenance document | Revisão do código-fonte e metadados de invocação do build | O `subject` atual está vazio; o documento não está vinculado a um digest de imagem nem é certificado de forma independente | | Relatório do OWASP ZAP | Resultados das rotas autenticadas de staging acessadas pelo ZAP | Não comprova cobertura completa da API ou da lógica de negócios | | Registro de exceção | Uma descoberta foi intencionalmente delimitada, justificada e recebeu uma data de expiração | Não elimina o risco subjacente | ## Procedimento de Rastreabilidade ### 1. Registre o digest implantado Use o registro ou o runtime de contêiner para capturar o digest imutável: ```bash theme={null} docker image inspect IMAGE:TAG \ --format='{{index .RepoDigests 0}}' ``` A saída esperada é semelhante a: ```text theme={null} registry.example.com/casebender/web@sha256:... ``` ### 2. Verifique a assinatura Os workflows de release do CaseBender usam assinatura sem chave com Cosign, respaldada pelo OIDC do GitHub Actions: ```bash theme={null} cosign verify \ --certificate-identity-regexp='https://github.com/casebender/webapp/' \ --certificate-oidc-issuer='https://token.actions.githubusercontent.com' \ IMAGE@sha256:DIGEST ``` A verificação deve ser realizada em relação a um digest, e não apenas a uma tag. O canal do registro e a identidade do certificado devem corresponder à documentação de release fornecida com o artefato. ### 3. Verifique os metadados de proveniência Analise o documento de proveniência quanto a: * repositório e revisão do código-fonte; * identidade e gatilho do workflow; * timestamp do build e ator; * campo `subject` e se ele identifica o artefato em análise; e * assinatura anexada e certificado de assinatura. O documento autônomo de proveniência atual do CaseBender tem um `subject` vazio. Ele pode ser verificado como metadados de workflow assinados, mas atualmente não consegue comprovar que um determinado digest de contêiner foi produzido por essa invocação. Para rastreabilidade no nível do artefato, use o digest do registro, a assinatura da imagem e a SBOM attestation da imagem. Verifique o blob assinado antes de confiar em seu conteúdo: ```bash theme={null} cosign verify-blob \ --signature provenance.json.sig \ --certificate provenance.json.cert \ --certificate-identity-regexp='https://github.com/casebender/webapp/' \ --certificate-oidc-issuer='https://token.actions.githubusercontent.com' \ provenance.json ``` ### 4. Analise a SBOM Use a SBOM para identificar componentes diretos e transitivos relevantes para sua implantação. Os clientes podem importar o JSON CycloneDX para suas próprias ferramentas de gestão de vulnerabilidades ou ativos de software. Uma SBOM deve ser associada ao mesmo commit ou digest de imagem em análise. Uma SBOM no nível do repositório e uma SBOM no nível da imagem respondem a perguntas diferentes e não devem ser tratadas como intercambiáveis. ### 5. Analise as descobertas e exceções de segurança Confirme: * se a verificação foi concluída, em vez de ignorada; * se o relatório corresponde à revisão ou ao digest de destino; * a política de severidade usada pelo workflow; * se descobertas sem correção foram excluídas pela configuração do scanner; * se uma exceção se aplica à descoberta e ao caminho exatos; e * se a exceção ainda está dentro do período de revisão. ## Retenção de Artefatos As configurações atuais de retenção dos workflows incluem: * artefatos de scanners e auditorias: geralmente 30 dias; * artefatos de SBOM CycloneDX do repositório e materiais de assinatura: 1.095 dias; e * assinaturas e attestations do registro: retidas com o artefato de registro aplicável, sujeitas à política de ciclo de vida do registro. A retenção no ambiente do próprio cliente é controlada por esse cliente. Clientes com requisitos de auditoria mais longos devem arquivar o pacote de evidências recebido para cada release implantada. ## Pacote de Evidências Sugerido para o Cliente Para uma análise de garantia de release, o pacote relevante pode incluir: 1. identificador da release e SHA do commit; 2. digests imutáveis das imagens de serviço implantadas; 3. resultado do workflow Security Gate; 4. resultados da verificação de contêineres para esses digests; 5. SBOMs CycloneDX; 6. saída da verificação de assinatura; 7. proveniência assinada e saída da verificação; 8. registros de exceções ativas aplicáveis; 9. um resumo da remediação de vulnerabilidades; e 10. a declaração atual do status dos testes de penetração. A disponibilidade pode depender das permissões do repositório, do canal do registro, dos períodos de retenção de artefatos e dos termos contratuais de divulgação. Relatórios brutos podem conter caminhos do repositório, detalhes de dependências ou informações de infraestrutura e podem exigir transferência segura ou ocultação de dados sensíveis. ## Interpretação de um Resultado Bem-Sucedido Um workflow verde significa que os jobs configurados foram concluídos de acordo com a política codificada naquela revisão. Isso não significa que: * não exista nenhuma vulnerabilidade; * todos os caminhos da aplicação tenham sido testados; * toda a infraestrutura implantada corresponda aos templates verificados; * todas as dependências estejam livres de avisos futuros; * um terceiro tenha validado o resultado de forma independente; ou * a release esteja certificada em relação a um framework de conformidade. Para implantações que exijam maior garantia, combine evidências automatizadas com análise da arquitetura, hardening do ambiente do cliente, modelagem de ameaças e testes manuais independentes. ## Evidências de Teste de Penetração Atualmente, o CaseBender não alega possuir um relatório concluído de teste de penetração por terceiros nem uma carta de reteste de remediação. Os testes automatizados com o ZAP e o recurso de gestão de testes de penetração no produto não substituem essas evidências. O trabalho planejado, as qualificações exigidas dos testadores, as regras de engajamento e os entregáveis esperados estão documentados em [Escopo do Teste de Penetração Independente — disponível em inglês](/en/security/penetration-test-scope). ## Comunicação de uma Preocupação de Segurança Comunique suspeitas de vulnerabilidades no CaseBender para [security@casebender.com](mailto:security@casebender.com). Inclua: * versão afetada ou digest da imagem; * modo de implantação; * etapas reproduzíveis; * comportamento esperado e observado; * impacto potencial; e * qualquer material de prova de conceito adequado para tratamento seguro. Não inclua credenciais ativas, dados de clientes nem material de exploração destrutiva em uma mensagem inicial não criptografada. ## Documentação Relacionada * [Programa de Garantia de Segurança](/pt-BR/security/security-assurance) * [Segurança de Código — disponível em inglês](/en/security/code-security) * [Segurança da Cadeia de Suprimentos — disponível em inglês](/en/security/supply-chain) * [Guia de Hardening de Implantação — disponível em inglês](/en/security/hardening-guide)