Gerenciando problemas de incidentes
A partir de uma perspectiva de conformidade, criação, armazenamento e atualização de problemas de incidentes (vulnerabilidade, CVE) como parte dos pipelines Integração Continuada e Compliance Continuous Compliance são essenciais para a coleta de evidências.
Durante a execução do pipeline PR com a coleta de evidências ativada, os pipelines CI e CC, o collect-evidence script cria problemas de incidentes, anexa-os
às evidências coletadas e os armazena no repositório de problemas de incidentes.
O script collect-evidence usa as funções do comando cocoa incident process, que processa os resultados de varredura fornecida e cria novos problemas de
incidentes no repositório fornecido por vulnerabilidade ou atualiza as questões de incidentes existentes com base nos pares de incidentes de assunto. Por isso, as questões de incidentes são ligadas a ativos e criadas de acordo com os resultados
de ferramentas específicas. Para obter mais informações, consulte Diferença entre o processamento de emissão em pipelines de IC e CC.
Processamento de problemas de incidentes no pipeline de RP
O pipeline de PR com a coleta de evidências ativada pode criar problemas de incidentes quando qualquer vulnerabilidade ou CVE for encontrado. Para ativar a coleta de evidências no pipeline de relações públicas, consulte:coleta de evidências do pipeline de relações públicas
O gerenciamento de problemas no pipeline de PR para problemas de incidentes é semelhante ao do pipeline de CI. A única diferença está na lógica da autoclavagem.
Um problema de incidente criado pelo pipeline de PR pode ser encerrado automaticamente apenas por um pipeline de PR em execução no mesmo PR. O problema não pode ser autoclavado por um canal de RP quando:
- O problema é encontrado por um pipeline de PR em execução em qualquer outro PR.
- O problema é encontrado por qualquer pipeline de CI ou CC.
Processamento de emissão de incidentes
Embora os pipelines CI e CC tenham etapas comuns, o processamento de problemas desses pipelines tem algumas diferenças:
- Questões de incidentes que são criadas durante o pipeline de IC não carregam uma data de vencimento, enquanto questões de incidentes que são criadas durante o pipeline CC do.
- Questões de incidentes que são criadas durante o pipeline de IC são encontradas durante a construção, enquanto questões de incidentes que são criadas durante o pipeline CC são encontradas no ambiente de produção.
As Figuras 1 a 6 mostram os possíveis casos de uso que são baseados nessas diferenças.
Ciclo de vida do problema:
O ciclo de vida do problema estende-se de PRs de código para varreduras de produção
Caso de uso 1: vulnerabilidade localizada na construção
A nova construção introduz uma vulnerabilidade, que não é aceita A implementação é bloqueada, a menos que a solicitação de mudança seja um CR emergencial aprovado manualmente.
Esse fluxo de pipeline de construção no caso de uma vulnerabilidades localizada e as ações do usuário correspondentes foram explicadas abaixo:
Caso de uso 2: vulnerabilidade localizada na construção que também está em produção
A nova construção contém uma vulnerabilidades que também está na produção atualmente implementada As equipes têm um cronograma para corrigir o problema, mas novos recursos ou correções ainda podem ser implementados.
O pipeline do CC configura a linha de tempo para corrigir tais vulnerabilidades encontradas na produção Ele só falhará quando a linha de tempo para corrigir a vulnerabilidade tiver expirado O fluxo foi esboçado abaixo
Caso de uso 2A: a vulnerabilidade que está localizada na produção permite PRs
A vulnerabilidade na produção não impede que as RCs se mesclem.
Caso de uso 3: falsos positivos
Se a equipe categorizar um problema como falso positivo, o problema poderá ser rotulado como Isento O problema pode, então, ser tratado como um problema sem bloqueio. Para manter uma trilha de auditoria, as solicitações de mudança mantêm os problemas visíveis
Caso de uso 4: fechando automaticamente problemas corrigidos
Executar periodicamente o pipeline CC pode fechar problemas que estão abertos e ter uma data de vencimento configurada. Além disso, a vulnerabilidade relevante não pode ser localizada em varreduras
O diagrama a seguir explica o fluxograma do pipeline CC detectando quais problemas devem ser encerrados e quais problemas devem ser criados.
Como definir a data de vencimento para questões de incidentes
Se as questões de incidentes forem encontradas na produção, a propriedade Due Date poderá ser adicionada à questão para especificar o período de carência em que deve ser corrigida. A duração do período de carência é determinada
pela gravidade da vulnerabilidade encontrada.
Para obter mais informações sobre como personalizar os períodos de carência, consulte Configurando os períodos de graça personalizados no pipeline CC.
Problemas de incidentes de etiquetagem
Problemas de incidentes que são criados pelos pipelines de integração contínua (IC) ou de conformidade contínua (CC) podem ter etiquetas padrão.
Etiquetas para problemas de incidentes descobertos pelo Code Risk Analyzer
O Code Risk Analyzer (CRA) detecta vários tipos de vulnerabilidades, como dependência de app e vulnerabilidade de imagem.
O tipo de vulnerabilidade pode ser do seguinte: name os, python, js, golang ou java.
Se o tipo de vulnerabilidade for do tipo os, um rótulo os-vulnerability é anexado ao assunto. Para qualquer outro tipo de vulnerabilidade, um rótulo app-vulnerability é anexado ao assunto.
Etiquetas para problemas de incidentes com correções disponíveis
Para questões de incidentes que são criados pelo pipeline de integração contínua (CI) ou pipeline de conformidade contínua (CC), o scanner pode ter informações de correção como uma parte do resultado da varredura. Se informações de correção
estiverem disponíveis, uma etiqueta fix-available é adicionada ao problema de incidente com um link para a descrição da correção dentro da descrição do problema.
A ausência da etiqueta fix-available não significa que a questão não seja acionável porque nem todo scanner inclui as informações de correção no resultado da varredura. O scanner sugere as informações de correção, e essa informação
vem de onde quer que o scanner fontes este dado de "correção". Alguns scanners podem não ter dicionários de "fix" atualizados ou não conter informações para uma correção.
Problemas de incidentes com a data de vencimento
Quando você usa o script colete-evidências, questões de incidentes são criadas e anexadas às provas coletadas. Se forem encontradas questões na produção, elas podem ter um período de tempo especificado no qual devem ser corrigidas para que as implementações não sejam bloqueadas. O prazo fornecido para corrigir o problema na produção é chamado de período de carência. No entanto, para melhor legibilidade, o Due Date agora está disponível em questões de incidentes para que os usuários conheçam a data em que a correção é devida sem calculá-la a partir do período de carência.
Se uma questão como vulnerabilidade ou CVE é encontrada na produção, e o mesmo problema também é encontrado em uma construção, a construção não torna a situação pior. O recurso pode ser implantado, e a equipe pode se concentrar na fixação da questão na produção.
Configurando períodos de carência personalizados no pipeline CC
O Pipeline de Conformidade Contínua (CC) calcula as datas de vencimento de questões de incidentes com base na gravidade de uma emissão. Você pode alterar os valores de período de carência padrão e substituí-los por valores personalizados.
O pipeline calcula o período de carência de acordo com a tabela a seguir:
| Gravidade | Período de carência |
|---|---|
| Informativo | 90 dias |
| Baixo | 45 dias |
| Médio | 45 dias |
| Alta | 15 dias |
| Crítico | 15 dias |
Para alterar a configuração padrão, crie uma nova propriedade nas propriedades de ambiente do pipeline CC denominadas grace-period-configuration. Esta propriedade de ambiente deve ser uma string JSON e combinar o seguinte formato:
{
"informational": 50,
"low": 40,
"medium": 30,
"high": 20,
"critical": 10
}
Se a propriedade do ambiente não corresponder ao formato esperado ou não for uma string JSON válida, o pipeline utiliza os valores padrão.
A propriedade de ambiente grace-period-configuration estabelece datas de vencimento para questões que não possuem data de vencimento já definida. Para questões que possuem um conjunto de datas de vencimento, a reconfiguração do
grace-period-configuration não atualiza essas datas de vencimento.
Cálculo de data de vencimento
A data de constatação é quando o pipeline de conformidade contínua (CC) é executado e encontra a questão no ambiente de produção. Se a questão existir, CC atualiza-o com o Due Date que é calculado a partir daquele momento.
<due date> = <date of finding the issue in prod> + <grace period in days (determined by severity)>
Formato de data de vencimento
A data de vencimento está no formato ISO 8601 e mostra como YYYYY-MM-DD.
Exemplo:Due Date: 2022-04-01
Casos de uso
-
Uma vulnerabilidade é encontrada em uma das imagens de base em produção pelo pipeline CC. A equipe é notificada de uma emissão de incidente com um período de carência configurado de acordo com a gravidade da vulnerabilidade. O período de carência é o número de dias que a equipe tem para implantar uma correção.
-
A equipe constrói um novo release com um novo recurso. A construção encontra um CVE associado à imagem base que é utilizada para a aplicação. A equipe executa o pipeline CC manualmente, que varre artefatos já em produção. A execução manual CC detecta o mesmo CVE no mesmo aplicativo em produção e acrescenta o Período de Graça à Incidente de Incidente. A equipe agora pode construir e implementar sem ser bloqueada.
Diferenças entre o processamento de emissão em pipelines de IC e CC
Problemas de incidentes são criados em dutos de IC e CC:
- Uma questão que é criada em IC significa que foi encontrada durante a construção.
- Uma questão que é criada em CC significa que ela foi encontrada no ambiente de produção.
Um Due Date pode ser incluído automaticamente em questões apenas se estiverem relacionadas a problemas encontrados no ambiente de produção. Isso significa que apenas o pipeline CC tem permissão para adicionar o Due Date a um problema. Se o CI encontrar a questão e o Due Data não estiver disponível, o valor do Due Date será n / a.
Processamento de resultados em questões
Problemas para problemas que são encontrados são criados de acordo com os resultados de ferramentas específicas. O script collect-evidence tenta processar os arquivos de resultado nos anexos e criar uma lista de questões.
As questões são ligadas a ativos, que podem ser comuns em um repositório ou uma imagem de docker com um digest.
Uma questão é criada para cada ID de emissão-um ID de emissão é composto pelos seguintes componentes:
- Ativo ligado
- A ferramenta que encontrou a vulnerabilidade
- O identificador de vulnerabilidades (o ID CVE, por exemplo)
Por exemplo, se CVE-2022-001 for encontrado por duas ferramentas separadas, o processo cria duas questões hoje.
Ferramentas suportadas
Atualmente, as ferramentas a seguir são suportadas para processamento de emissão:
- CRA
- VA
- Gosec
- Detecção de segredos
- Scanner de API OWASP-ZAP
- Scanner OWASP-ZAP UI
- SonarQube
Ferramentas não suportadas ou formatos de resultados
Se o script collect-evidence receber um anexo a partir de uma ferramenta não suportada, ou o formato de arquivo de resultado não for reconhecido durante o processamento, o script pula questões e usa o arquivo de resultado como
um simples anexo às provas.
Conteúdo da emissão
- Problema é o nome do problema ou vulnerabilidade.
- Due Date mostra a data em que a correção é devida ou n / a se nenhum prazo final estiver disponível.
- Assunto é o ativo que a questão está vinculada.
- URL é o link para a versão exata do ativo.
- Tipo de Ferramenta é a ferramenta que produziu o conteúdo para a emissão
Para problemas criados no Git Repos and Issue Tracking, a data de vencimento é configurada no campo de data de vencimento nativo do GitLab em vez da descrição do problema.
A descrição do problema contém o timestamp quando a questão foi descoberta pela primeira vez. Por exemplo, First found on 2022-04-07. A data está no formato YYYY-MM-DD. Os locais onde o problema ocorre estão listados
nos comentários do assunto.
Adiando a data de vencimento de uma questão incidente
Se você quiser adiar a data de vencimento de um problema de incidente, você pode pedir uma revisão a partir de um focal de segurança. Dependendo da revisão, você pode adiar a data de vencimento modificando o campo Due date no incidente
Git Repos and Issue Tracking problemas de metas.
Certifique-se de referencia a revisão focal de segurança na questão, como fornecer um link para ele em um comentário.
Slack alertas para problemas pendentes e vencidos para pipeline CC
O Pipeline de Conformidade Contínua (CC) pode configurar datas de vencimento para as questões de incidentes. O pipeline também pode notificar os usuários sobre questões que se aproximado de datas de vencimento e vencidas as datas de vencimento usando o Slack, se a integração do Slack estiver ativada.
Para obter mais informações, consulte Configurar uma cadeia de ferramentas de Integração Continuada(CI). Para mais informações sobre datas de vencimento, veja [Problemas de Incidentes com a data de vencimento](/docs/devsecops?topic = devsecops-incident-emite#devsecops-devsecops-questões-due-date.
As questões que são notificadas são classificadas da seguinte forma:
- Questões tendo datas de vencimento pendentes dentro de um cronograma específico: questões que estão abertas, têm datas de vencimento, e estão vencidas dentro de um cronograma.
- Questões tendo as datas de vencimento anteriores: questões que estão abertas, têm datas de vencimento e a data é passada.
As durações do cronograma são overdue, due in 1 day, due in 2 days, due in 5 days e due in 10 days.
Um exemplo dessa capacidade é o seguinte:
Overdue issues:
- <issue url#1>
- <issue url#2>
- <issue url#3>
Issues due in 1 day:
- <issue url#4>
Issues due in 2 days:
- <issue url#5>
Issues due in 5 days:
- <issue url#6>
- <issue url#7>
Issues due in 10 days
- <issue url#8>
- <issue url#9>
- <issue url#10>
- <issue url#11>
- <issue url#12>
A lista agregada é ordenada com os problemas que são vencidos em primeiro lugar, e os problemas com datas de vencimento mais próximos são listados antes daqueles com data de vencimento posterior.
O estágio cc-finish nas consultas de pipeline CC para as questões com base nos critérios e aciona um alerta Slack.