Encontrar uma vulnerabilidade é a parte fácil. O trabalho de Segurança é garantir que a correção seja mesclada e implantada; para dependências vulneráveis, o Coroid abre a própria atualização pull request, e sua equipe a revisa e mescla.
Quando o Coroid abre uma...
Com Corrigir dependências vulneráveis ativado, uma ocorrência de dependência com gravidade de correção igual ou superior (alta por padrão) gera uma tarefa de correção no projeto:
- Uma tarefa e um pull request por pacote, abrangendo todas as recomendações que o afetam.
- Primeiro, as ocorrências críticas, depois as de alta gravidade.
- No máximo 5 pull requests de correção abertos por projeto por padrão (até 50). A próxima correção aguarda por uma vaga.
Proprietários e administradores também podem escolher Corrigir em qualquer ocorrência de dependência aberta cuja recomendação seja pública. Quando nenhuma versão corrigida foi lançada, a opção Corrigir oferece uma tarefa de mitigação: remover ou substituir o pacote, fixar um fork com correção ou proteger a chamada vulnerável.
As atualizações automáticas funcionam hoje para projetos npm. Para outros ecossistemas, a ocorrência indica "Ainda não há correção automática para este ecossistema", e a opção Corrigir oferece a tarefa de mitigação.
Quais são os custos?
As tarefas de Corrigir usam um modelo do AI, portanto consomem horas de agente como outras tarefas. Elas são executadas sob o mandato interno de Correções de segurança , que toda organização possui:
- Escopo: atualizações de dependências e mitigações de segurança, nada mais.
- Orçamento: apenas horas de agente, por padrão um quarto das horas de agente do seu plano por mês. Proprietários alteram as horas e se elas são contabilizadas por semana ou mês em Segurança → Configurações → Corrigir dependências vulneráveis.
- Sem prazo de expiração para revisão. É um padrão permanente, não algo que precise ser renovado.
- Prioridade: as correções de segurança têm prioridade sobre outros trabalhos iniciados autonomamente.
Desativar a opção Corrigir dependências vulneráveis no padrão da organização pausa o mandato. O mandato está listado com os demais em Controle de Qualidade → Mandatos.
Quando uma organização que já tinha repositórios conectados adquire o Security, seus proprietários recebem uma notificação no sininho: "As correções de segurança começam em sete dias". O trabalho de Corrigir inicia sete dias após o envio dessa notificação, permitindo que um proprietário o desative antes do primeiro pull request. Novas organizações começam imediatamente.
Por que uma correção pode aguardar?
A seção de correção de uma ocorrência indica o motivo da espera. Os motivos comuns são:
- o limite de pull request aberto para o projeto foi atingido;
- o orçamento do mandato ou as horas de agente do plano foram esgotadas (a detecção continua);
- o trabalho de agente está pausado no Mission Control, ou não há vaga disponível para agente;
- o período de aviso de sete dias ainda não terminou;
- não foi lançada nenhuma correção compatível, ou o ecossistema não tem correção automática;
- a opção Corrigir dependências vulneráveis está desativada.
Como a atualização é escolhida?
Para cada local onde um pacote vulnerável está instalado, o Coroid seleciona a menor versão acima da instalada que corrija todas as recomendações que o afetam, respeitando o intervalo declarado e a versão principal permitida. Ele nunca faz downgrade. Um espaço de trabalho que precisa de uma versão principal e outro que precisa de outra recebem suas próprias versões corrigidas no mesmo pull request. Um pacote transitivo é atualizado pela atualização do pai ou pela sobrescrita do gerenciador de pacotes. Qualquer mudança de versão principal ou consolidação em uma única versão vem acompanhada de seu motivo no pull request. Quando nenhuma atualização única corrige tudo, o pull request corrige o que for possível e lista o restante como não corrigido.
O que o pull request inclui?
- As recomendações que corrige, com sua gravidade.
- O inventário de pacotes antes e depois da alteração, mostrando que a versão vulnerável foi removida.
- As verificações do seu projeto: quando o gráfico de Entrega do projeto tem verificações que podem ser executadas, elas devem obter aprovação na alteração enviada antes que o Coroid abra o pull request; caso contrário, a tarefa termina com seu motivo. Quando o projeto não tem verificações configuradas, o pull request ainda é aberto e indica que o Coroid não executou verificações do projeto, que a CI própria do seu repositório roda no pull request, e onde configurar verificações em Controle de Qualidade.
- Os motivos de qualquer mudança de versão principal ou intervalo.
- Qualquer recomendação que não pôde ser corrigida, listada como não corrigida.
O texto termina com: "As pessoas revisam e fazem o merge. O status de implantação é definido apenas por uma verificação da revisão implantada." O achado é incorporado ao código a partir do próximo inventário completo e corrigido por ambiente a partir da verificação da revisão executada nesse ambiente. Veja Achados e seu ciclo de vida.
Achados de código
Em um achado de código, Corrigir arquiva uma tarefa para corrigi-lo no respectivo projeto. Proprietários e administradores podem usá-la em qualquer achado de código aberto. A tarefa solicita ao desenvolvedor que descreva a correção, não o ataque, nas mensagens de commit e no pull request, além de incluir um teste de regressão. Ela segue as mesmas regras das demais tarefas e consome horas de agente.
Em um repositório público, ou naquele cuja visibilidade o Coroid não consegue confirmar, uma correção para um achado que ainda não é público não é commitada lá. O Coroid mantém a alteração preparada de forma privada para que um proprietário ou administrador a publique. Veja Divulgação.
Segredos vazados
Uma credencial vazada é corrigida por meio da rotação dela, algo que o Coroid não pode fazer por você. A correção em um achado de segredo gera uma tarefa de lista de verificação. Veja Segredos vazados.