IBM Cloud Docs
script de coleta de provas

script de coleta de provas

O script collect-evidence ajuda os adotantes, usuários e colaboradores a enviar seus dados de conformidade para o fluxo de dados do DevSecOps Gerenciamento de mudanças.

O script executa as tarefas a seguir:

  • Tenta processar quaisquer anexos como resultados, e cria problemas de incidentes a partir desses resultados. Um número limitado de formatos de saída de ferramentas são suportados.
  • Se forem encontradas questões, o script avalia seus períodos de carência (datas de vencimento) e estados de isenção.
  • Cria um ativo de evidência no armário de provas.
  • Cria a própria evidência, e anexa os problemas e forneceu anexos.

Para um status de success ou failure, se nenhum anexo for passado por dentro collect-evidence, o pipeline-logs para aquela tarefa em particular e o estágio são capturados como um anexo.

O script collect-evidence é fornecido pelo pipeline. Ele não precisa ser instalado. O script tem as seguintes dependências:

  • bash
  • libstdc++ shared library
  • libgcc shared library

Certise-se de que as dependências estão instaladas na imagem base que usa esta ferramenta para relatar evidências.

Uso

O script collect-evidence requer os seguintes parâmetros:

  • --tool-type O ID da ferramenta que fornece dados de evidência. Por exemplo: "owasp-zap-ui", "cra"
  • --evidence-type A ID do tipo de evidência. Por exemplo: com.ibm.image_vulnerability_scan, com.ibm.unit_tests
  • --asset-key A chave em ativos de pipelinectl. Para os seguintes comandos load_artifact <key> ou load_repo <key>
  • --asset-type O tipo de ativo a partir de pipelinectl e pode ser um dos seguintes tipos: repo, artifact
  • --status O status da evidência e pode ser um dos seguintes: success, pending, failure
  • --assets Especifique diversos pares de chave de ativo e de tipo de ativo Por exemplo, é possível usar o --assets asset-key1:asset-type1 --assets asset-key2:asset-type2 Se você usar essa opção, não especifique asset-key e asset-type separadamente.

O parâmetro a seguir é opcional:

  • --attachment O arquivo a ser processado como um resultado e anexado à evidência O parâmetro pode ser especificado várias vezes para vários arquivos. Para assinatura de imagem, certifique-se de que o arquivo de assinatura esteja anexado usando o parâmetro --attachment. O arquivo de assinatura deve incluir os detalhes da assinatura, como a ID da chave, o algoritmo e o resumo assinado. Os formatos comuns incluem JSON ou TXT.
  • --meta Metadados arbitrários a serem adicionados às evidências. O parâmetro aceita pares de valor 'key = value' e pode ser especificado várias vezes. Você pode incluir metadados relevantes para o processo de assinatura de imagem, como o ambiente de assinatura ou qualquer configuração específica usada durante a assinatura.
  • --additional-comment O comentário que é incluído em um problema se um pipeline falhou.

Use o seguinte comando para obter ajuda:

collect-evidence --help

Valor de retorno

collect-evidence saídas a string de status de evidência avaliada em STDOUT (uma das success, failure ou pending). Esse valor avaliado depende dos anexos de resultado processado, problemas de incidentes encontrados e possível correção dessas questões, por exemplo, ter um conjunto de data de vencimento ou uma etiqueta isenta. Para obter mais informações, consulte Problemas de Incidente.

# example on how to read the output into a variable in bash

read -r status < <(collect-evidence "${evidence_params[@]}")

echo $status # success

Exemplo de uso

collect-evidence \
  --tool-type "sonarqube" \
  --evidence-type "com.ibm.static_scan" \
  --asset-type "repo" \
  --asset-key "app-repo" \
  --status "success" \
  --attachment ./sonarqube-result-1.json \
  --attachment ./sonarqube-result-2.json \
  --meta environment=staging

collect-evidence \
  --tool-type "ciso-code-signing" \
  --evidence-type "com.ibm.cloud.image_signing" \
  --asset-type "artifact" \
  --asset-key "signed-image" \
  --status "success" \
  --attachment ./signature.json \   # The signature details in JSON format
  --attachment "./${artifact}.fingerprint" \ #  The fingerprint is a hash value generated from the artifact, ensuring integrity and authenticity.
  --meta environment=production

Formatos de ferramentas suportados

A implementação atual suporta atualmente as seguintes ferramentas (fornecidas como o parâmetro --tool-type ):

  • cra IBM Analisador de risco de código
  • va Vulnerability Advisor para IBM Cloud Container Registry
  • gosec GoLang Scanner de Segurança
  • xray JFrog Xray-Vulnerability Scanning & Container Security
  • owasp-zap Procurador De Ataque OWASP Zed (ZAP)
  • owasp-zap-ui OWASP Zed Attack Proxy UI (ZAP UI)
  • sonarqube SonarQube varredura
  • peer-review Varredura de revisão de peer
  • twistlock TwistLock
  • mend Varredura Final
  • checkov Varredura de Checkov
  • cra-tf Code Risk Analyzer para Terraform
  • tfsec Scanner de segurança do Terraform
  • fips-scanner Scanner Fips (Federal Information Processing Standards)
  • detect-secrets Detecção de segredos
  • ferramenta de assinatura de código CISO ciso-code-signing
  • sysdig varredura do Sysdig
  • cyclonedx CycloneDX. A detecção de ferramentas para o gerenciamento de problemas será realizada com base nos metadados do CycloneDX aqui.

Os metadados do CycloneDX são Detecção de ferramentas para gerenciamento de problemas

Se o script collect-evidence for chamado com um tipo de ferramenta que não é suportado, o script não tentem processar os anexos. Adicionalmente, o tratamento de emissão é ignorado, e a coleta de provas não é interrompida.

Se o seu script fornece um anexo a partir de uma ferramenta suportada, mas o anexo não pode ser processado, o tratamento de emissão é ignorado e a coleta de evidências não é interrompida.

Tipo de evidência

Você pode configurar o tipo de evidência usando o parâmetro --evidence-type. Você pode configurar qualquer tipo, mas o IBM Cloud® Security and Compliance Center suporta os seguintes tipos de evidência:

  • com.ibm.unit_tests
  • com.ibm.detect_secrets
  • com.ibm.branch_protection
  • com.ibm.static_scan
  • com.ibm.code_vulnerability_scan
  • com.ibm.code_bom_check
  • com.ibm.code_cis_check
  • com.ibm.cloud.image_vulnerability_scan
  • com.ibm.cloud.image_signing
  • com.ibm.dynamic_scan
  • com.ibm.cloud.image_signing
  • com.ibm.acceptance_tests
  • com.ibm.prod_change_request
  • com.ibm.close_change_reques

Requisitos de ativos

As provas que são coletadas com esta ferramenta fazem parte do trabalho de coleta de provas do V2 e das atualizações de armário de provas relacionadas.

Este novo método focaliza-se em evidências baseadas em ativos, significando que as evidências estão conectadas ao artefato e repo através das varreduras e testes que executam sobre esses artefatos ou repos, e produziram resultados para provas. Por exemplo:

  • Um repo com um determinado commit torna-se um ativo commit, que é escaneado, criando evidências para o ativo commit.
  • Usando o mesmo repo e commit, uma imagem é construída. A imagem se torna um ativo que está relacionado com o ativo de origem, o repo e commit.
  • A imagem é escaneada, e evidências são criadas. Todos os resultados da varredura estão conectados através das evidências, seu ativo e os ativos relacionados.

Para fazer todo esse trabalho em conjunto, os ativos que são fornecidos com os parâmetros --asset-type e --asset-key devem obedecer a alguns requisitos:

repo ativos adicionados usando o comando save_repo

Verifique a referência de comandos para obter informações de uso exato.

Campos necessários:

  • url O repositório URL.
  • commit O commit SHA.

artifact ativos adicionados usando o comando save_artifact

Verifique a referência de comandos para obter informações de uso exato.

Campos necessários:

  • name O nome do artefato Por exemplo, para uma imagem, inclua o registro, o namespace e a imagem (exemplo: us.icr.io/team-images/service).

  • digest O resumo do artefato (exemplo: sha256:a2292ed2b82c7a51d7d180c3187dbb0f7cc9ab385a68484c4f117e994acd6192).

    Mudanças necessárias em save_artifact para não imagens: a evidência de coleta agora suporta todos os tipos de ativos. Para coletar evidências para trabalhar em qualquer tipo de ativo save_artifact deve salvar explicitamente o ativo com type, por exemplo, zip save_artifact artifact-1 type=zip .... No script de coleta de evidências, o asset-type deve ser um artefato e o tipo é consultado a partir do artefato. Para que esse processo funcione, a inclusão de ativo do bloqueador de cacau foi modificada para incluir ativo de qualquer tipo. Depois de salvo, o script de evidência de coleta pode ser chamado como abaixo:

    collect-evidence --tool-type toolType --evidence-type artifact --asset-key artifact-1 ...

    Consulte nosso aplicativo de amostra para implementação de amostra para deployment tipo https://github.ibm.com/one-pipeline/hello-compliance-app

    Com essas mudanças, o script collect-evidence processa todos os tipos de artefatos, incluindo artefatos de imagem e não imagem.

Coleção de evidências em lote

Cada parte da coleção de evidências envolve chamadas de rede para criar ou recuperar um ativo A evidência é armazenada dentro do repositório de evidência e do depósito IBM Cloud Object Storage, se configurado. Isso poderia potencialmente levar a atingir os limites de taxa no servidor Git Para minimizar a necessidade de chamadas de rede, as evidências agora podem ser salvas no sistema de arquivos até o final do pipeline e coletadas em massa usando cocoa locker evidence publish. No momento da coleta de evidências, a evidência não é salva no armário de evidências, mas gravada em um cache local para ser recuperada e salva no armário em um ponto posterior. Devido a isso, a evidência não pode ser visualizada usando o comando cocoa locker evidence get neste ponto No entanto, os anexos (se houver) são salvos no armário de evidências durante a coleta de evidências e podem ser visualizados usando o comando attachment URL ou cocoa locker attachment get.

Esse recurso é controlado pelo sinalizador batched-evidence-collection e é ativado por padrão em pipelines de IC, CD e CC É possível desativá-lo configurando a propriedade do ambiente batched-evidence-collection para 0

Quando a sinalização estiver ativada, assegure-se de que as imagens de estágio contenham git, pois a CLI do git mantém as evidências dentro do sistema de arquivos até sua publicação

Diversos ativos em coletar-evidência

Ao usar a evidência de coleta, é possível configurar a coleção simultânea de evidências para diversos ativos Você inicia a coleção de evidências usando a sinalização --assets, que especifica vários pares de chave de ativo e de tipo de ativo Por exemplo, input --assets asset-key1:asset-type1 --assets asset-key2:asset-type2. Se você escolher essa opção, não indique chave de ativo e tipo de ativo separadamente.

Lembre-se destes pontos-chave sobre a coleção de diversos ativos:

  • status, attachment, tool-type, evidence-type e upload-logs são constantes em todos os ativos.
  • Por padrão, quando você designa diversos ativos, o processamento de evidência segue o fluxo anterior Se você especificar um único ativo, o processamento de evidência ocorrerá por meio de um fluxo específico para a ferramenta ou anexo.
  • No caso de falha, os problemas são criados por ativo Esses problemas são encerrados após uma nova execução bem-sucedida da coleção de evidências O encerramento está correlacionado com os ativos que você especificou.
  • Um arquivo de evidência singular é gerado, que apresenta um ID que abrange todos os ativos combinados.