Pipelines de solicitações pull

O pipeline de pull request executa um conjunto de verificações de status de conformidade em um pull request para o repositório de aplicativos especificado.

As tentativas de mesclagem de uma solicitação pull na ramificação principal podem ser bloqueadas caso haja verificações de status de conformidade com falha. A abertura ou atualização de uma solicitação pull em relação à ramificação principal aciona a execução do pipeline de solicitação pull. Você pode executar sua própria configuração para os pipelines e testes em scripts personalizados.

Estágios e tarefas

A tabela abaixo lista as tarefas executadas em um pipeline de RC. 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.
Default Reference Implementation: indica se os pipelines DevSecOps vêm com uma implementação predefinida ou padrão para o estágio. Notavelmente, para determinados estágios, como unit-tests ou setup, o pipeline DevSecOps 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. Quando o DevSecOps Pipeline fornece 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 nos estágios em que o pipeline DevSecOps 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.

Ordem do oleoduto
Tarefa ou estágio	Descrição curta	Customização permitida em `.pipeline-config.yaml`	Implementação de referência padrão	Requisito de coleção de evidência	Ignorar permitido
`start`	Configure o ambiente de pipeline	Não	Sim	NA	Não
`setup`	Configure seu ambiente de construção e de teste	Sim	Não	NA	Não
`detect-secrets`	Executar varredura de segredos de detecção no código do aplicativo.	Sim	Sim	NA	Não
`unit-tests`	Execute testes de unidade e testes de aplicativo no código do aplicativo	Sim	Não	NA	Sim
`compliance-checks`	Execute as varreduras do Code Risk Analyzer e outras verificações de conformidade nos repositórios de aplicativos	Sim	Sim	NA	Sim
`finish`	Consolidar o status do pipeline..	Sim	Sim	NA	Sim

Para obter mais informações sobre como customizar os estágios usando o arquivo .pipeline-config.yaml, consulte Scripts customizados e Parâmetros de pipeline.

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

Verificações e varreduras nas 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 de ramificação estão corretas. |

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.

Tarefas

Varreduras e verificações de conformidade
Tarefa	Descrição
`code-pr-start`	Clona os repositórios do aplicativo e do DevSecOps e configura o estado pendente inicial para verificações de status em repositórios do Git Repos and Issue Tracking.
`code-setup`	O marcador de um script customizado de configuração definido pelo usuário, que pode ser utilizado para a conclusão de uma configuração de pipeline própria.
`code-detect-secrets`	Executa a varredura de segredos de detecção para identificar onde os segredos são visíveis no código do app
`code-unit-tests`	O marcador de um script customizado de teste definido pelo usuário, que pode ser usado para a execução de testes próprios.
`code-pr-finish`	Executa todas as verificações de conformidade necessárias, comenta os resultados na solicitação pull e configura o resultado nos repositórios do Git Repos and Issue Tracking.

Uso de alterações PR/MR para o repositório de configuração do pipeline

Se a linha do PR deve considerar as alterações dos arquivos/scripts de configuração provenientes do PR/MR, o repositório e a ramificação de configuração devem estar vazios, o que pode ser definido como abaixo:

As variáveis env one-pipeline-repo, one-pipeline-config-repo e pipeline-config-repo estão vazias ou não foram especificadas nas variáveis env
As variáveis env one-pipeline-config-branch e pipeline-config-branch estão vazias ou não foram especificadas nas variáveis env.

Mesclagem de solicitações pull e problemas

É possível usar os direitos de administrador para mesclar as solicitações pull que têm verificações de status com falha no repositório. No entanto, um resultado failure é registrado nas evidências dessas solicitações pull para a tarefa com falha. Esse resultado é incluído no resumo de evidências e na descrição da solicitação de mudança e afeta o escore final de conformidade no Security and Compliance Center.

Permitir a coleta de evidências no pipeline de RP

O pipeline de RP oferece suporte à coleta de evidências e ao gerenciamento de problemas. Por padrão, o pipeline de RP não coleta evidências nem abre nenhum problema, mas os usuários podem optar por esse recurso. Para habilitar a coleta de evidências e o gerenciamento de problemas, defina a variável de ambiente collect-evidence-in-pr como uma das seguintes opções:

none: (padrão) Defina collect-evidence-in-pr para none, para impedir a coleta de evidências no pipeline de PR.
all: Defina collect-evidence-in-pr como all para coletar todas as evidências, independentemente do status do pipeline de PR. Os problemas serão abertos, atualizados ou fechados de acordo com o script collect-evidence.
success: Defina collect-evidence-in-pr como success para coletar evidências somente se todo o pipeline de PR for executado com êxito. Se o pipeline de RP falhar, as evidências não serão coletadas ou publicadas no armário de evidências e o gerenciamento de problemas não será realizado.

Observação: Como os pipelines de PR geralmente são executados com bastante frequência, a escolha do modo correto de collect-evidence-in-pr evitará a coleta desnecessária de evidências. Sugere-se selecionar o modo success durante a fase de desenvolvimento ou nos casos em que as falhas são previstas, a fim de evitar a coleta de evidências se o pipeline falhar.

Se o pipeline PR acionar um pipeline Assíncrono, o modo collect-evidence-in-pr definido como success não será suportado. Caso o pipeline PR acione um pipeline assíncrono, defina collect-evidence-in-pr como all para coletar evidências.

Observação: se o repositório do aplicativo for um repositório GitLab e a contribuição do MR (solicitação de mesclagem) for de um repositório bifurcado, o usuário precisará fornecer um valor para a variável de ambiente git-token que tenha acesso aos repositórios de origem e de destino para definir os status adequados na solicitação de mesclagem. Isso significa que o token git precisaria pertencer a um usuário que é um colaborador no repositório base e no repositório bifurcado, e o token tem permissões para definir o status em um commit.

Superando o CVE em RP

Quando um PR é criado e as vulnerabilidades são encontradas pelo pipeline de PR, o pipeline adiciona as informações sobre a vulnerabilidade, como a gravidade, o identificador da cve, o pacote junto com sua descrição e a correção, se disponível, como um comentário. Isso permite que os usuários verifiquem rapidamente as vulnerabilidades a serem corrigidas no PR, em vez de ter que examinar os registros do pipeline.

Um sinalizador opcional opt-in-pr-updates está disponível para ativar/desativar esse recurso no pipeline de PR. Isso é ativado por padrão.

Configuração de um pipeline de PR para lidar com PRs da fila de mesclagem do Github

Uma fila de mesclagem é um recurso do Github que ajuda a aumentar a velocidade automatizando as mesclagens de pull request em um branch ocupado e garantindo que o branch nunca seja quebrado por alterações incompatíveis. Mais informações sobre como configurar e usar o Github Merge Queue aqui.

Criar um novo Git Trigger

Crie um novo Git Trigger ou duplique um já existente. Mantenha todas as configurações padrão, apenas substitua as seguintes propriedades:

Name: preferem ter um nome de acionador que reflita o contexto da fila de mesclagem - por exemplo: PR - Merge Queue
EventListener: selecione pr-listener-merge-queue
Trigger on: selecione CEL filter
- CEL filter: entrar body.action == 'checks_requested'

Os PRs da Fila de mesclagem usam ramificações efêmeras - criadas "on the fly" quando o PR original é adicionado à Fila de mesclagem - a partir das quais o PR da Fila de mesclagem é criado. Como consequência, a carga útil do evento Git correspondente (que aciona o pipeline de Pull Request) não contém nenhuma informação sobre PR URL ou HTML URL.

Irrelevantes no contexto da Merge Queue, os seguintes recursos do DevSecOps devem ser desativados com a adição das propriedades de texto correspondentes:

skip-merge-pr-to-base: deve ser definido como true (padrão: false)
opt-in-pr-updates: deve ser definido como 0 (padrão 1)

Salve o gatilho.

Teste do acionador da fila de mesclagem

Crie um novo Pull Request no branch principal do repositório de código-fonte do aplicativo.
Observe: o pipeline "padrão" do DevSecOps PR é acionado
Ainda na página do PR, clique em Merge when ready e, em seguida, clique em Attempt merge when ready- isso fará com que enqueue o PR entre na fila de mesclagem assim que o PR "padrão" for concluído.
Aguarde até que o DevSecOps PR "padrão" seja concluído com êxito
Observe: após a conclusão do pipeline de PR, o PR é adicionado à fila de mesclagem e o PR da fila de mesclagem é acionado:
- Aguarde a conclusão do Merge Queue PR
- Se for bem-sucedido, o PR será mesclado com um comentário como Merged via the queue into main with commit abcdefg
- Se não for bem-sucedido (por exemplo: falha na verificação de conformidade), o PR não será mesclado automaticamente e será removido da Merge Queue (Fila de mesclagem).

Visão geral da carga útil do PR

Carga Útil

Uma carga útil é um termo genérico usado para descrever um bloco estruturado de dados, geralmente no formato JSON, que é transmitido como parte de um evento ou solicitação. As cargas úteis são comumente usadas em webhooks, APIs e sistemas de automação para transmitir informações relevantes em um formato legível por máquina.

As cargas úteis podem representar uma ampla variedade de conteúdo, dependendo do contexto - por exemplo, metadados de compilação, atividade do usuário, atualizações de problemas ou, neste caso, detalhes de pull request.

Carga útil do PR

cd-devsecops-pr-payload

A carga útil de PR é uma instância específica de uma carga útil que encapsula metadados e informações contextuais sobre uma solicitação pull (PR). Ele é gerado quando ocorre um evento de pull request e fornece acesso estruturado aos principais atributos relacionados a esse PR.

Essa carga útil inclui uma ampla variedade de dados, como:

Título e descrição do PR
Autor e revisores
Ramos de origem (cabeça) e destino (base)
Histórico de compromissos e referências SHA
Detalhes do repositório
Carimbos de data e hora, rótulos, status e muito mais

Embora a carga útil completa contenha muitas informações, apenas um subconjunto específico de campos está sendo extraído e exposto como variáveis de ambiente para uso em pipelines, scripts e arquivos de configuração.

Propriedades do ambiente extraídas da carga útil do PR

As seguintes variáveis de ambiente são atualmente derivadas da carga útil do PR e usadas ativamente:

Nome da Variável	Descrição
`head-branch`	O ramo de origem do PR (ramo do qual está sendo mesclado)
`head-sha`	O SHA do commit mais recente no ramo principal
`head-repo`	O repositório do qual o PR se origina
`base-branch`	O ramo de destino do PR (ramo no qual está sendo mesclado)
`base-repo`	A referência completa ao repositório de base
`base-repo-name`	O nome do repositório base
`base-repo-owner`	O proprietário (usuário ou organização) do repositório de base
`commit-timestamp`	O registro de data e hora do commit mais recente no PR
`pr-url`	A API URL do pull request
`pr-html-url`	O site (HTML) URL do pull request
`pr-title`	O título da pull request
`action`	status do PR
`base_ref`	ramo de destino do PR

Esses valores são injetados como variáveis de ambiente para simplificar o acesso durante a execução em fluxos de trabalho automatizados.

A carga útil do PR inclui muitos campos adicionais além do que está listado acima. No entanto, apenas o subconjunto extraído é atualmente aproveitado para fins operacionais. Se necessário, o acesso à carga útil completa pode ser fornecido para casos de uso avançado ou expansão futura.