IBM Cloud Docs
Pipeline de integração contínua

Pipeline de integração contínua

O pipeline de integração contínua cria os artefatos implantáveis a partir dos repositórios dos aplicativos.

Antes de criar um artefato, o pipeline verifica se o código foi verificado e testado, da mesma forma que as solicitações pull são processadas. Os artefatos construídos também são escaneados em busca de vulnerabilidades e são inscritos no pipeline antes de serem considerados prontos para liberação e implementação no inventário. Ao contrário do pipeline de solicitações pull, o pipeline de integração contínua coleta artefatos de evidências e de resultados em cada estágio da construção, como as fases de teste, varredura e assinatura. Esses dados estão associados aos artefatos de construção e podem ser acompanhados pelo processo de implementação e gerenciamento de mudanças.

Estágios e tarefas

A tabela abaixo lista as tarefas executadas em um pipeline de IC. 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 de integração contínua
Tarefa ou estágio Descrição simples Customização permitida em .pipeline-config.yaml Implementação de Referência Padrão Coleta de evidências Ignorar permissível
start Configuração do ambiente de pipeline. Não True Pipeline Não
setup Configuração do ambiente de construção e teste. True Não N/D Não
detect-secrets Executar varredura de segredos de detecção no código do aplicativo. True True Pipeline Não
test Execução de testes de unidade e testes de aplicação no código de aplicação. True Não Usuário True
static-scan Execução do código de varredura estática no código do aplicativo. True True Pipeline True
compliance-checks Execução de varreduras do Code Risk Analyzer e outras verificações de conformidade nos repositórios do aplicativo. True True Pipeline True
containerize Construção dos artefatos. True Não N/D Não
sign-artifact Assinatura dos artefatos construídos. True True Pipeline Não
deploy Implementação dos artefatos construídos no ambiente de desenvolvimento True Não N/D Não
dynamic-scan Executar varredura dinâmica no aplicativo. True True Pipeline True
acceptance-test Execução de testes de aceitação e integração nos artefatos de construção implementados no ambiente de desenvolvimento. True Não Usuário True
scan-artifact Varredura dos artefatos construídos. True True Pipeline True
release Inclusão dos artefatos construídos no inventário. True Não N/D True
finish Coleta, criação e upload dos arquivos de log, artefatos e evidências, colocando-os no armazenamento de evidências. True True N/D True

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
test com.ibm.unit_tests
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
containerize N/D
sign-artifact com.ibm.cloud.image_signing
deploy N/D
dynamic-scan com.ibm.dynamic_scan
acceptance-test com.ibm.acceptance_tests
scan-artifact com.ibm.cloud.image_vulnerability_scan
release N/D
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..

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 como configurar seu repositório para a varredura estão disponíveis aqui

Varredura de código estático

O estágio de varredura de código estático executa diversas ferramentas de analisador de código estático nos repositórios de app especificados. É feita a varredura do repositório do aplicativo padrão e dos repositórios fornecidos pelo comando pipelinectl save_repo.

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.

  • Caso você não tenha uma instância própria do SonarQube, durante sua execução, o pipeline criará uma instância do SonarQube. É possível acessar esta instância após o estágio de varredura estática ser executado com sucesso.

  • Usando o parâmetro opt-in-gosec para executar a varredura gosec para verificações de segurança golang.

  • Inclua seu próprio código de varredura estática no estágio customizado static-scan no arquivo .pipeline-config.yaml para uma implementação customizada.

Adicionando SonarQube scan aos seus pipelines

Para obter mais informações sobre a integração do SonarQube com o pipeline de integração contínua, consulte Configurando SonarQube.

Incluindo a integração de varredura gosec em seus pipelines

Use gosec para inspecionar o código-fonte golang em repositórios varridos.

Para ativar a varredura gosec, forneça o parâmetro a seguir e configure o valor como 1.

parâmetros de varredura gosec
Nome Tipo Descrição Necessário ou opcional
opt-in-gosec text opção para ativar a varredura gosec opcional

Mais informações sobre como configurar a varredura gosec no pipeline de integração contínua, consulte Configurando GoSec

Usando outros scanners estáticos

Se, em vez disso, você quiser usar sua própria implementação de varredura estática, poderá modificar o arquivo .pipeline-config.yaml e adicionar seu próprio script personalizado ao estágio static-scan.

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.
Verificação de conformidade do repositório Verifica se as configurações de proteção da ramificação estão corretas. Por exemplo, o ramo de mestrado / principal deve sempre restringir o empurrão da força. Para mais informações, consulte Configurando o seu repositório Git Repos and Issue Tracking.

Esses scripts são executados em todos os repositórios de aplicativos reconhecidos pelo pipeline. Para incluir repositórios nessas varreduras, use a interface pipelinectl, fornecida no estágio setup.

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

Observação: os pipelines de CI não são acionados em tags porque não oferecem suporte a recursos como branch protection checks ou peer review check. Se você optar por executar um pipeline de CI em tags, certifique-se de desativar as propriedades peer-review-compliance e branch-protection-check, definindo-as como 0. No entanto, esteja ciente de que, nesse caso, a coleta de provas não ocorrerá para esses casos.

Construir

No estágio build, é possível construir seus próprios artefatos. Embora o pipeline forneça alguns recursos padrão para artefatos do tipo imagem do Docker, é possível construir qualquer tipo de artefato neste estágio.

Use as variáveis de ambiente da IU do pipeline para fornecer credenciais, segredos e parâmetros para a construção. Essas variáveis de ambiente podem ser acessadas neste estágio e em todos os estágios customizados. Para obter mais informações sobre como acessar parâmetros e segredos em estágios de scripts customizados, consulte Scripts customizados.

Varredura de artefatos e assinatura

Os estágios de varredura e assinatura de artefatos fornecem um comportamento padrão para imagens do Docker, com etapas customizáveis:

  • Assinatura de imagens utilizando GPG Key.
  • Varredura do Vulnerability Advisor no registro de contêiner

Nesses estágios, para começar, forneça seus artefatos para que o pipeline utilize 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 diferente de varredura ou de assinatura ou para processar artefatos diferentes de imagens do Docker em icr.io, é possível customizar esses estágios, usando a configuração .pipeline-config.yaml em seu projeto.

Implementação no desenvolvimento

No estágio deploy, os artefatos construídos são implementados em um ambiente de desenvolvimento.

Varredura dinâmica

O scan de código dinâmico é uma forma de varredura de vulnerabilidade de caixa preta que permite que as equipes de software digitalizem aplicativos em execução e identifique vulnerabilidades.

O estágio Dynamic Scan é executado imediatamente após o estágio Deploy to dev depois de uma implementação bem-sucedida para o ambiente dev.

Por padrão, o pipeline fornece suporte para executar o Zed Attack Proxy (ZAP) Scan, que é uma ferramenta de teste de penetração de fonte livre e aberta que é mantida sob o guarda-chuva da OWASP. Ele executa varreduras dinâmicas de API e UI, ambas as quais podem ser executadas na amostra hello-compliance-app.

Para executar a varredura dinâmica, configure o parâmetro pipeline opt-in-dynamic-scan para um valor não vazio. Para desabilitar o estágio de executar varreduras dinâmicas, configure o parâmetro pipeline opt-in-dynamic-scan para vazio. Para obter mais informações sobre a configuração de parâmetros de pipeline, consulte Parâmetros de Pipeline.

O pipeline de IC cria problemas no Repositório de Problemas com base na gravidade. A etiqueta que está anexada ao assunto indica a gravidade da vulnerabilidade.

Varredura da API ZAP

A API do ZAP varre os terminais de aplicativos para possíveis vazamentos de dados, erros de tipo de conteúdo, redirecionamentos externos, injeção de código, injeção de SQL, injeção de comandos remotos do SO e outras vulnerabilidades expostas pelo aplicativo. As varreduras da API ZAP ajudam os desenvolvedores a garantir a aplicação, detectando essas vulnerabilidades em um ambiente de estágio ou teste e fixando-as antes que o aplicativo seja implantado em um ambiente de produção.

Varreduras da API ZAP requerem as seguintes entradas para escanear sua aplicação:

  • Arquivo de definição Swagger - Descreve as APIs HTTP e seus parâmetros associados conforme expostos pelo aplicativo.
  • API Key-token de autenticação que é necessário para autenticar com os terminais da API.
  • API Endpoint-Endpoints a partir das definições de swagger que você deseja que o ZAP escanear.
  • URLs excluídas-As URLs a serem ignoradas pelo scanner ZAP.

O Scanner da API ZAP usa as entradas que são mencionadas para executar scan e produzir um relatório.

Configure opt-in-dynamic-api-scan para um valor não vazio para varreduras de API ZAP para execução. Para optar por fora, configure este parâmetro para vazio.

Varredura ZAP UI

A ZAP UI varre os terminais de aplicativos para vulnerabilidades nas próprias páginas da web, como cookies inseguros que estão sendo configurados, configurações de cabeçalho de cache impróprias, inclusões de arquivos de domínio cruzado, configurações de CORS impróprias e outras vulnerabilidades que são expostas pelo aplicativo.

As varreduras de UI funcionam de forma semelhante a varreduras de API, mas usam um script de teste de UI em vez de um arquivo Swagger. O script de teste da UI inicia um navegador sem cabeça configurado para proxy por meio do proxy do scanner ZAP e ele executa um teste de UI contra o terminal UI. O processo para executar testes da ZAP UI é o seguinte:

  • Copie os scripts de testes para os contêineres ZAP Scanner.
  • Execute o Proxy ZAP.
  • Execute os scripts de teste de zap.

O proxy ZAP registra o tráfego e descobre os endpoints para escanear. Após o acabamento das varreduras, o proxy produz um relatório e gera problemas da mesma forma que na varredura da API do ZAP.

Configure opt-in-dynamic-ui-scan para um valor não vazio para varreduras de API ZAP para execução. Para optar por fora, configure este parâmetro para vazio.

  • 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 obter mais informações sobre a varredura da API ZAP e varreduras da ZAP UI, consulte Configurando scans ZAP.

Liberação para o inventário

Use o estágio release to inventory user script para incluir artefatos no inventário, usando o comando da CLI cocoa inventory add CLI command. Para obter mais informações sobre o comando, consulte o tópico para adicionar estoque de cacau.

Se você deseja pular a atualização do inventário se houver problemas no pipeline, use as variáveis de ambiente a seguir para verificar o status do pipeline. Confira o status deles antes de atualizar o inventário:

  • skip-inventory-update-on-failure Opt-in ambiente variável a partir de pipeline para especificar se a atualização do inventário deve ser feita.
  • one-pipeline-status É configurado como 1 se houver alguma falha de estágio na execução do pipeline.

Você pode usar a interface pipelinectl para acessar seus repositórios e artefatos usando os comandos list_repos, load_repo, list_artifacts e load_artifact. Para obter mais informações sobre os comandos, consulte a documentação pipelinectl.

Coleta de dados de conformidade sobre a construção

Após a execução bem-sucedida do pipeline, é possível coletar informações sobre a construção.

As evidências de todas as verificações, varreduras, testes e assinaturas de artefatos são coletadas e enviadas para o armazenamento de evidências. Os arquivos de log do pipeline também são salvos no armazenamento, juntamente com os dados do próprio pipeline, contendo as definições Tekton. Nesta etapa, também são coletados dados de conformidade sobre as revisões de peer. O pipeline usa pipelinectl para buscar repositórios com solicitações pull que foram mesclados desde a última construção. Ele também verifica seu status de revisão, o salva como um artefato e cria evidências com base no resultado.

O script final é um avaliador, que marca o status do pipeline como verde ou vermelho, com base nos status das evidências. Caso ele contenha falhas, a execução de integração contínua é marcada em vermelho.