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 do pipeline de compilação, no caso de uma vulnerabilidade encontrada, e as ações correspondentes do usuário são explicados no diagrama a seguir.
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 é descrito no diagrama a seguir.
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 e isenções
Se a equipe classificar uma incidência como falso positivo ou receber uma exceção de segurança relacionada a uma vulnerabilidade, a incidência poderá ser marcada como “Isenção ”. 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.
Gerenciamento de prazos para problemas relacionados a incidentes
Quando são detectados problemas relacionados a incidentes no ambiente de produção, a propriedade Due Date é adicionada automaticamente para especificar o prazo de tolerância dentro do qual o problema deve ser corrigido.
A duração do período de carência é determinada pela gravidade da vulnerabilidade encontrada.
Cenários comuns de data de vencimento
Os cenários a seguir descrevem como as datas de vencimento são gerenciadas:
- Atribuição inicial da data de vencimento: Quando o pipeline do CC identifica um problema em produção, ele calcula e define automaticamente uma data de vencimento com base na gravidade do problema.
- Prorrogação do prazo: Se você precisar de mais tempo para corrigir um problema, poderá prorrogar o prazo após obter a aprovação de um ponto de contato de segurança. Consulte “Adiamento da data de vencimento ” para obter mais detalhes.
- Problemas em atraso: Mesmo quando os problemas ficam em atraso, os pipelines de CI ainda podem prosseguir com as implantações, desde que a nova compilação não prejudique o ambiente de produção (abordagem puramente voltada para a gestão de riscos). Isso permite que as equipes continuem lançando funcionalidades enquanto trabalham para resolver problemas de segurança.
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 | 180 dias |
| Baixo | 180 dias |
| Médio | 90 dias |
| Alta | 30 dias |
| Crítico | 30 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
O processamento de incidentes suporta resultados de diversas ferramentas de varredura integradas aos pipelines do DevSecOps. Para consultar a lista atualizada das ferramentas de digitalização compatíveis e seus recursos, consulte “Ferramentas de digitalização compatíveis ”.
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 em Git Repos and Issue Tracking, a data de vencimento é definida no campo GitLab native due date 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.
Prorrogação do prazo de um problema relacionado a um incidente
É possível prorrogar o prazo de um incidente quando for necessário mais tempo para implementar uma correção. Isso requer a aprovação de um responsável pela segurança para garantir a supervisão adequada das vulnerabilidades de segurança.
Processo para prorrogar prazos de vencimento
- Solicite uma análise ao seu ponto de contato de segurança, explicando por que a prorrogação é necessária.
- Após receber a aprovação, atualize a data de vencimento:
- Para o Git Repos and Issue Tracking: altere o campo “
Due date” nos campos de metadados do incidente. - Para o GitHub Enterprise: edite o campo “
Due date” na descrição da solicitação.
- Para o Git Repos and Issue Tracking: altere o campo “
- Faça referência à aprovação do responsável pela segurança na solicitação, adicionando um comentário com um link para a documentação de revisão ou aprovação.
Certifique-se de referencia a revisão focal de segurança na questão, como fornecer um link para ele em um comentário.
Exceções de segurança
Caso haja algum problema relacionado a uma exceção de segurança, você pode prorrogar o prazo para que ele coincida com a data de validade da exceção. Isso garante que a coleta de evidências e o acompanhamento da conformidade continuem de forma adequada até que a exceção expire.
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.