Pipeline de conformidade contínua

O pipeline de conformidade contínua (pipeline CC) varre periodicamente os artefatos implementados e seus repositórios de origem.

O pipeline CC processa as entradas a partir do repo inventário usando o valor environment-tag para determinar qual é o estado implementado mais recente para olhar. Após a digitalização e a execução de verificações de artefatos e repositórios de origem, o pipeline cria um novo problema de incidente ou atualiza as questões de incidentes existentes no repositório de incidentes. Por fim, usando essas questões e os resultados, o pipeline coleta evidências e resume as evidências, portanto, o Security and Compliance Center pode atualizar o status de conformidade dos artefatos encontrados.

Estágios e tarefas

A tabela abaixo lista as tarefas executadas em um pipeline CC. Além disso, a tabela também fornece uma visão geral de cada um desses estágios:

Tarefa ou Estágio: refere-se ao nome do estágio conforme definido no arquivo de configuração .pipeline-config.yaml.
Descrição simples: fornece uma explicação concisa das ações executadas durante a execução do estágio.
Customização permitida: isso indica se os usuários têm a flexibilidade para modificar ou substituir o comportamento padrão do estágio inserindo um script customizado no arquivo .pipeline-config.yaml.
Implementação de referência padrão: Isso indica se oDevSecOps pipelines vêm com uma implementação predefinida ou padrão para o estágio. Notavelmente, para certos estágios como unit-tests ou setup, oDevSecOps pipeline não oferece nenhuma implementação pronta para uso. Em vez disso, os usuários precisam fornecer scripts customizados ou código customizado para os requisitos de seus aplicativos
Coleção de evidência: indica se o estágio executa a coleção de evidência padrão. QuandoDevSecOpsGasoduto fornecer uma implementação de referência para um estágio, a coleta de evidências é realizada imediatamente. No entanto, se o Usuário optar por modificar ou substituir esses estágios predefinidos, eles deverão assegurar que suas implementações customizadas incluam a coleta de evidência apropriada A mesma responsabilidade recai sobre os usuários nas etapas em que oDevSecOps pipeline não fornece uma implementação pronta para uso, exigindo que eles realizem a coleta de evidências. A coluna indica a entidade (Usuário / Pipeline) responsável por executar a coleta de evidências...
Ignorar permitido (aplicável à versão> = v10): isso indica se os usuários podem optar por não executar esse estágio configurando a propriedade ignorar como true no .pipeline-config.yaml No entanto, recomenda-se cuidado ao usar esse recurso, especialmente para estágios designados para coletar evidências. Ignorar tais estágios pode levar à ausência de evidências essenciais para a construção.

Estágios e tarefas do pipeline de conformidade contínua
Tarefa ou estágio	Descrição curta	Customização permitida em `.pipeline-config.yaml`	Implementação de referência padrão	Coleta de evidências	Ignorar permitido
`start`	Configure o ambiente de pipeline	Não	Sim	Pipeline	Não
`setup`	Configure seu ambiente de construção e de teste	Sim	Não	Não	Não
`detect-secrets`	Executar varredura de segredos de detecção no código do aplicativo.	Sim	Sim	Pipeline	Não
`static-scan`	Execute o código de varredura estática no código do aplicativo	Sim	Sim	Pipeline	Sim
`dynamic-scan`	Execute a varredura dinâmica no aplicativo	Sim	Sim	Pipeline	Sim
`compliance-checks`	Execute as varreduras do Code Risk Analyzer e outras verificações de conformidade nos repositórios de aplicativos	Sim	Sim	Pipeline	Sim
`scan-artifact`	Varrer os artefatos compilados	Sim	Sim	Pipeline	Sim
`finish`	Colete, crie e faça upload dos arquivos de logs, artefatos e evidências para o armário de evidências.	Sim	Sim	Pipeline	Sim

Para obter mais informações sobre como personalizar os estágios usando o arquivo .pipeline-config.yaml, consulte Scripts personalizados e listas de parâmetros do pipeline.

Etapas e evidências

A tabela abaixo fornece um relacionamento entre vários tipos de evidência e os estágios específicos dentro do pipeline no qual sua coleta ocorre

Estágios de integração contínua e evidências associadas
Tarefa ou estágio	Tipo de evidência
`start`	N/D
`setup`	N/D
`detect-secrets`	`com.ibm.detect_secrets`
`static-scan`	`com.ibm.static_scan`
`compliance-checks`	`com.ibm.code_bom_check`, `com.ibm.code_cis_check`, `com.ibm.code_vulnerability_scan`, `com.ibm.branch_protection`
`dynamic-scan`	`com.ibm.dynamic_scan`
`scan-artifact`	`com.ibm.cloud.image_vulnerability_scan`
`finish`	`com.ibm.pipeline_logs`, `com.ibm.pipeline_run_data`

Para obter mais informações sobre como coletar evidências dentro dos estágios do usuário customizáveis usando o script collect-evidence, consulte collect-evidence script..

Inventário de processamento para artefatos e repositórios

O estágio inicial clona o inventário e processa as entradas mais recentes no ambiente de produção. Você pode especificar este ambiente, fornecendo os seguintes parâmetros de pipeline:

Artefatos e repositórios do pipeline de conformidade contínua
Nome	Tipo	Descrição	Obrigatório ou opcional
`environment-tag`	Texto	Tag que representa o ambiente de destino mais recente no inventário. Exemplo: `prod_latest` ou `us-south_prod_latest`	Obrigatório
`environment-branch`	Texto	Nome do ramo que representa o ambiente de destino no inventário. Exemplo:`prod`	Descontinuado-prefia `environment-tag` em vez
`region-prefix`	Texto	Nome da região como prefixo para a tag `latest` para o ambiente de destino. Exemplo: `us-south`	Descontinuado-prefia `environment-tag` em vez

As entradas do inventário contêm artefatos implementados e fontes de repositório. O pipeline processa e coleta as entradas do inventário e registra-as para a execução do pipeline, utilizando os seguintes comandos pipelinectl:

O estágio inicial também clona os repositórios encontrados, cada repo, e cada par de commit. Então, por exemplo, repo1 com commit sha1 são clonados em uma pasta, mas o pipeline clona o mesmo repo1 com commit sha2 em uma pasta separada.

O pipeline registra artefatos e repositórios para o pipeline executado usando um simples índice de notação e incrementador de nomenclatura, como os exemplos a seguir:

repo-1, repo-2, repo-3
artifact-1 artifact-2, artifact-3

Você pode listar essas entradas nos estágios personalizados usando os seguintes comandos pipelinectl:

Se você recuperar as informações de ramificação em seu pipeline do CC usando o pipelinectl comando load_repo "$repo" branch, ele sempre retornará master como ramificação Portanto, use commit hashes em vez de ramos.

Estágio de configuração

O estágio de setup no pipeline CC executa o script que está localizado no estágio setup que é definido por seu .pipeline-config.yaml. Você pode determinar qual pipeline que o script está rodando usando o seguinte comando:

get_env pipeline_namespace

Este comando retorna ou cc, cd, ci ou pr, dependendo de qual pipeline está em execução. Dessa forma, é possível reutilizar o script de setup entre pipelines se necessário.

Varredura de segredos do Detect

A ferramenta IBM Detect Secrets identifica quais segredos estão visíveis no código do aplicativo. Mais informações sobre a configuração de seu repositório para a varredura estão disponíveis aqui

Varredura de código estático

O estágio static code scan executa uma ferramenta de analisador de código estático nas bases de código do repositório do aplicativo especificado.

O pipeline CC fornece os repos que são encontrados no inventário para o scanner.

Qualquer um dos métodos a seguir pode ser usado para incluir um código estático em seu pipeline:

Forneça o nome, a URL e as credenciais de uma instância SonarQube já em execução, incluindo a ferramenta SonarQube na cadeia de ferramentas. A tarefa static-scan executa uma varredura nos repositórios especificados.
Adicione seu código ao estágio personalizado static-scan em seu arquivo .pipeline-config.yaml para obter uma implementação personalizada.

Varredura dinâmica

O estágio de varredura Dinâmica executa uma ferramenta de teste de segurança do aplicativo dinâmico para encontrar vulnerabilidades no aplicativo implementado.

Adicione seu próprio código de varredura dinâmica ao estágio personalizado de varredura dinâmica em seu arquivo .pipeline-config.yaml para obter uma implementação personalizada.

Para saber mais sobre configurar o scan dinâmico usando o OWASP-ZAP, veja Configurando o ZAP scan para pipeline CC.

Verificações e varreduras nas verificações de conformidade

Varreduras e verificações de conformidade
Varredura ou verificação	Descrição
Varredura de vulnerabilidade do Code Risk Analyzer	Encontra vulnerabilidades em todas as dependências de pacotes do aplicativo, todas as imagens de base do contêiner e todos os pacotes do sistema operacional. Utiliza a ferramenta Code Risk Analyzer.
Verificação do CIS do Code Risk Analyzer	Executa verificações de configuração nos manifestos de implementação do Kubernetes Utiliza a ferramenta Code Risk Analyzer.
Verificação do BOM (Bill of Material) do Code Risk Analyzer	O BOM de um repositório especificado, que captura a origem de todas as dependências. O BOM é coletado em diferentes granularidades. Por exemplo, o BOM captura a lista de imagens de base utilizadas na construção, a lista de pacotes das imagens de base e a lista de pacotes de aplicativos instalados por meio da imagem de base. O BOM representa uma verdade absoluta para os resultados analíticos e pode, potencialmente, ser usado para a aplicação de limites de políticas. Utiliza a ferramenta Code Risk Analyzer.

Esses scripts são executados em todos os repositórios de aplicativos reconhecidos pelo pipeline. O pipeline CC usa a interface pipelinectl save_repo para registrar repos encontrados nas entradas de inventário, em seguida usa os comandos list_repos e load_repo para iterar sobre recompos e enviá-los para scanners.

Para obter mais informações sobre a saída esperada dos estágios de scripts do usuário, consulte Scripts customizados.

Varredura de artefatos e assinatura

O estágio de varredura de artefato fornece um comportamento padrão para imagens do Docker, com uma etapa personalizável:

Container Registry Vulnerability Advisor escaneamento

O pipeline CC usa a interface pipelinectl save_artifact para registrar artefatos encontrados nas entradas de inventário, depois iterem sobre esses artefatos, usando os comandos list_artifacts e load_artifact.

Para ser iniciado com este estágio, forneça seus artefatos para o pipeline usando a interface pipelinectl. Não é obrigatório atualizar os scripts de construção e a configuração de .pipeline-config.yaml.

Para usar um processo de digitalização diferente ou para processar artefatos que não sejam imagens Docker em icr.io, é possível personalizar esses estágios usando a configuração .pipeline-config.yaml em seu projeto.

Coleta de dados de conformidade sobre a construção

O pipeline CC tenta processar os resultados a partir de verificações e scans, quebrando resultados para questões individuais por cada CVE, vulnerabilidade ou alerta encontrados. Os problemas que são encontrados pelo pipeline CC são marcados com uma etiqueta continuous-compliance-check que identifica questões que são descobertas no ambiente prod.

O pipeline coleta evidências em todas as verificações e scans e armazena-as no armário de provas. O coletor de evidências também salva os arquivos de log do pipeline, os dados do pipeline em si, contendo as definições de Tekton. As questões que são criadas de acordo com a varredura e verificação de que resultados também estão anexadas às provas.