Conformidade de revisão de peers

As revisões de código de pares são um componente chave do fornecimento de software seguro e compatível. A implementação de referência do DevSecOps ajuda a impor a revisão das alterações de código antes de serem mescladas e promovidas para produção.

Gerenciando cadeias de ferramentas de verificação de revisão de peer em CI/CD

Esta documentação fornece instruções para ativar e desativar a verificação de revisão de peer em Integração Contínua (CI) e opcional em cadeias de ferramentas de Continuous Delivery (CD).

Cadeia de ferramentas de integração contínua (CI)

Por padrão, a verificação de revisão de peer é ativada no CI toolchain. Para modificar esta configuração:

Para ativar a verificação de revisão de peer, configure o valor da variável de ambiente peer-review-compliance para 1...
Para desativar a verificação de revisão de peer, configure o valor da variável de ambiente peer-review-compliance para 0

Continuous Delivery (CD) Toolchain

As variáveis de ambiente a seguir permitem gerenciar a verificação de Peer-review dentro da cadeia de ferramentas do CD:

Para recuperar uma lista de solicitações pull e seus títulos associados para sua implementação em andamento, configure a variável de ambiente peer-review-collection como 1. Observe que essa variável é configurada como 1 por padrão.. Para desativar essa listagem, configure peer-review-collection como 0
Para ativar a validação da revisão de peer para todas as solicitações pull associadas à sua implementação atual, configure a variável de ambiente peer-review-compliance como 1. Por padrão, essa variável é definida como 0. Para ignorar essa validação, configure peer-review-compliance como 0.

Pontos importantes

Deve-se realizar revisões de peer apenas na ramificação protegida (base), que é onde o inventário é atualizado Se você estiver executando um pipeline de IC em uma ramificação de recurso, configure a variável de ambiente peer-review-compliance como 0 para esse acionador específico para evitar a verificação de revisão de peer na ramificação de recurso..

A adesão à conformidade de revisão por pares depende da conclusão de uma execução de pipeline de Integração Contínua (CI) bem-sucedida e da entrada subsequente para o inventário Como resultado, a execução inicial do pipeline de IC ignorará a verificação de conformidade de revisão de peer (peer review)...

Para assegurar a conformidade com os padrões de revisão de peer, é assumido que as atualizações de inventário no estágio ci-finish ocorrem na ramificação master. No entanto, se as suas atualizações de inventário forem executadas em uma ramificação diferente da principal, será possível configurar a variável de ambiente inventory-repo-branch para indicar a ramificação na qual as atualizações de inventário estão ocorrendo

Espera-se que, no pipeline de implantação contínua (CD), todas as atualizações de inventário feitas no repositório de inventário sejam promovidas para a ramificação de destino que está sendo implantada, garantindo que nenhum commit seja perdido. Por padrão, durante a implantação, o repositório do inventário será verificado na ramificação de destino. No entanto, se o branch de destino da promoção de inventário perder alguns commits entre o branch de base e o branch de destino, você poderá definir a variável de ambiente inventory-repo-branch para especificar o branch de base em que todos os commits de inventário estão localizados.

Por padrão, o pipeline de Integração Contínua (CI) executará automaticamente uma confirmação no repositório de inventário na conclusão da execução, usando o nome do aplicativo como a entrada de inventário. No entanto, se você pretende modificar a entrada de inventário durante o estágio de liberação, é recomendável incorporar uma propriedade de ambiente chamada inventory-entry-name em sua cadeia de ferramentas Essa propriedade deve conter o nome do inventário modificado para trabalhar para o processo de revisão de peer

Se você tiver uma automação que envia os commits diretamente para o branch protegido e quiser evitar problemas com verificações de conformidade de revisão por pares, certifique-se de que a mensagem de commit inclua ##AUTOMATED_COMMIT##.

A implementação de referência descobre instâncias de código que não são revisadas por pares, coleta evidências e cria problemas de incidentes para rastrear esses itens.

Antes que você possa mesclar o código no ramo mestre (protegido), o código deve ser revisado por uma pessoa que não tenha feito upload do código modificado.

O repositório de código (repo) deve ter pelo menos dois membros: um membro que tenha privilégios de administrador e outro membro que tenha privilégios de gravação. Caso o código seja mesclado em um repositório sem passar por uma revisão, a ação deve ficar visível na trilha de auditoria do repositório do código. Periodicamente, faça uma varredura da trilha de auditoria para identificar e analisar essas situações excepcionais.

O pipeline coleta dados de conformidade de revisão por pares durante as compilações e implantações para criar a trilha de auditoria das fusões de solicitações de pull/merge de código para as solicitações de alteração.

Neste diagrama, PR1, PR2 são os pedidos de pull / merge que são aprovados antes de mesclar. Da mesma forma, para PR4, PR5e PR7. No entanto, PR3 e PR6, destacados em vermelho, são mesclados sem uma aprovação, o que é uma violação de conformidade de revisão por pares. Isso é capturado como evidência.

Por padrão, o aplicativo de amostra na cadeia de ferramentas de IC tenta configurar o número mínimo de revisores para 1. Se você desejar alterar o número de revisores, configure a propriedade de ambiente peer_review_approvers conforme necessário Para obter mais informações sobre como configurar o número mínimo de revisores necessários para uma solicitação de pull / mesclagem, consulte os recursos GitHub e GitLab a seguir:

Dados coletados em execuções de compilação de integração contínua

Essa coleção de dados contém uma lista de todos os commits para as solicitações pull/merge que foram mescladas nos repositórios de aplicativos desde a última compilação.

Os dados da solicitação pull são coletados diretamente a partir dos repositórios de aplicativos. São coletados os dados de cada solicitação de pull/merge relacionada aos commits entre o commit do repositório que acionou a compilação anterior e o commit disponível no momento.

Os commits que não contêm uma solicitação de pull/merge criam um problema de incidente de conformidade nas versões seguintes do pipeline. Você não pode fazer o commit diretamente no ramo mestre.

Um incidente de conformidade geralmente guarda as seguintes informações:

Lista de URLs de solicitação de pull / merge para o ID de commit associado.
Repositório de aplicativos.
ID do commit.
Número necessário de aprovações.

Os dados coletados são salvos como um artefato de evidência, que é carregado para o armário de evidências e, em seguida, referenciado na própria evidência. O resultado final da evidência é determinado pelas solicitações pull/merge aprovadas. Solicitações pull/merge não aprovadas, mas mescladas, falham nesse tipo de evidência.

Dados coletados em execuções de implantação contínua

Essa coleção de dados contém uma lista de todas as solicitações pull/merge que foram mescladas nos repositórios de aplicativos desde a última implantação.

Os dados da solicitação pull são coletados do armário de evidências e do repositório de problemas do incidente.

O inventário reúne dados de todas as construções em artefatos relacionados desde a última implementação.
O armazenamento de evidências coleta os dados de revisão de peers armazenados a partir das construções.
O repositório de problemas de incidentes coleta informações sobre incidentes abertos de pull/merge request.

Os repositórios de aplicativos não são acessados durante esta coleta de dados. Como se supõe que os pipelines de implantação contínua estejam localizados em ambientes isolados, você não pode cruzar esses limites.

Conteúdo da solicitação de mudança

Os dados a seguir são incluídos na solicitação de mudança gerada automaticamente:

Lista de incidentes de solicitação de pull/merge que não foram corrigidos. Esses dados incluem os detalhes do ativo e o incidente URL.

Os incidentes de solicitação de pull/merge não corrigidos afetam a prontidão de implementação da solicitação de mudança. Se quaisquer incidentes de solicitação de pull / merge forem encontrados, eles são considerados vulnerabilidades e a solicitação de mudança deve ser revisada e aprovada manualmente.

Correção de incidentes de solicitações pull

Os incidentes de solicitações pull são considerados vulnerabilidades pois indicam que um código não verificado está contido nos artefatos liberados. Para corrigir esses incidentes, conclua as seguintes etapas:

Faça a revisão retroativa da mudança mesclada.
Crie uma emissão sobre como corrigir os problemas existentes no código.
Inclua a etiqueta exempt ou feche a emissão de incidente de pedido de pull / merge.

O autor da solicitação pull/merge e a pessoa que fecha o problema do incidente da solicitação pull/merge não podem ser a mesma pessoa.

Resolução de problemas

Caso 1:

Problema

Falha no estágio collect_peer_review_commits no prod-start do pipeline do CD resulta em outros estágios com falha com erros. Quando o seguinte erro ocorre no estágio prod_start

| ERROR | 2023-12-20T07:00:48.978Z | index.ts:25:14 | The inventory entry has no such property ('pipeline_run_id').

Solução

Os usuários que possuem entradas de inventário que não são suportadas pelo pipeline único devem incluir um ignorar arquivo no inventário. Essa ação assegura que esses arquivos não sejam considerados para nenhum cálculo..

Problemas conhecidos

A conformidade de revisão de peer é dependente da inclusão de entrada de inventário na etapa de liberação após cada iteração do pipeline de Integração Contínua (CI). Ignorar para incluir a entrada de inventário para qualquer execução de pipeline de IC com falha pode resultar na evidência de revisão de peer para essa execução de pipeline de IC específico sendo desconsiderado em seu pipeline de Continuous Delivery (CD).