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
Procedimento de Rastreabilidade
1. Registre o digest implantado
Use o registro ou o runtime de contêiner para capturar o digest imutável:
A saída esperada é semelhante a:
2. Verifique a assinatura
Os workflows de release do CaseBender usam assinatura sem chave com Cosign, respaldada pelo OIDC do GitHub Actions:
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.
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:
- identificador da release e SHA do commit;
- digests imutáveis das imagens de serviço implantadas;
- resultado do workflow Security Gate;
- resultados da verificação de contêineres para esses digests;
- SBOMs CycloneDX;
- saída da verificação de assinatura;
- proveniência assinada e saída da verificação;
- registros de exceções ativas aplicáveis;
- um resumo da remediação de vulnerabilidades; e
- 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.
Comunicação de uma Preocupação de Segurança
Comunique suspeitas de vulnerabilidades no CaseBender para 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
