Acompanhamento de vulnerabilidades
Acompanhe todas as vulnerabilidades conhecidas no software que distribui, desde o build que as trouxe até à versão que as corrigiu. O CRACI regista a SBOM de cada build, continua a verificá-la face a novos dados de vulnerabilidades e encaminha cada vulnerabilidade detetada para a equipa responsável pela correção.
O que é o acompanhamento de vulnerabilidades?
O acompanhamento de vulnerabilidades é o registo contínuo de todas as vulnerabilidades conhecidas que afetam o seu software, desde a descoberta até serem corrigidas ou descartadas. Para cada uma responde a quatro perguntas: onde está, que produtos e versões a incluem, quem é responsável pela correção e qual é o seu estado.
Muitas ferramentas respondem à primeira pergunta analisando manifestos e lock files a posteriori, e deixam o resto para folhas de cálculo e tickets. O CRACI começa mais cedo. Os seus jobs de GitHub Actions são executados em runners do CRACI e, enquanto decorrem, o CRACI regista todos os pacotes que o build efetivamente obteve, incluindo pacotes restaurados de caches de CI. É essa SBOM gerada durante o build que o CRACI monitoriza, pelo que as vulnerabilidades que acompanha são as do artefacto que distribuiu, e não as de uma análise feita algures ali perto.
Acompanhar o software que distribui, não apenas os seus ativos de TI
A maioria das ferramentas de acompanhamento de vulnerabilidades foi concebida para as TI: analisa servidores, portáteis e contas na nuvem, e a correção é um patch que alguém instala. O software que desenvolve e vende precisa de outro tipo de registo. O código vulnerável está dentro da sua versão, a correção é um novo build, e os clientes e as autoridades perguntam que versões foram afetadas e durante quanto tempo.
É esse o registo que o CRACI mantém: a SBOM de cada build, os produtos e versões em que foi implementado, os componentes de fornecedores que adquiriu e o estado de cada vulnerabilidade em todos eles.
Reavaliação contínua do que distribuiu
O CRACI regista a SBOM enquanto cada build decorre e depois continua a reavaliar as SBOM monitorizadas face aos dados de vulnerabilidades. Uma vulnerabilidade publicada muito depois de uma versão continua a aparecer associada à versão que afeta, sem que ninguém tenha de repetir uma análise.
Uma única vista de todos os builds e repositórios
As conclusões são agregadas entre builds e repositórios, com vistas da organização sobre o branch predefinido. A vista de inventário mostra exatamente que versões de software estão implementadas em que produtos, e o histórico de builds mostra que builds anteriores continham uma dependência vulnerável, para que saiba que produtos foram afetados e durante quanto tempo.
Triagem e encaminhamento para a equipa responsável
As equipas de segurança fazem a triagem das vulnerabilidades descobertas e enviam-nas às equipas responsáveis pela correção, para que cada vulnerabilidade detetada chegue a quem pode agir. O CRACI suporta também VEX para registar a forma como uma vulnerabilidade afeta o seu produto, e as policy gates podem bloquear qualquer build que contenha uma CVE específica.
SBOM de fornecedores acompanhadas junto das suas
Adicione as SBOM dos seus fornecedores e os componentes adquiridos passam a ser monitorizados a par do software que desenvolve. O código de terceiros no seu produto é acompanhado no mesmo local que as suas próprias dependências.
Da deteção à notificação do CRA
No âmbito do Cyber Resilience Act, o CRACI submete em seu nome as notificações de vulnerabilidades: o alerta precoce, a notificação e o relatório final. As SBOM são exportadas em CycloneDX ou SPDX com as vulnerabilidades encontradas nos respetivos componentes, para auditorias, clientes e os seus próprios registos.
Cada pacote vulnerável e o que o traz
Cada build lista os seus pacotes com a versão, o package URL, a licença e o estado de vulnerabilidade, e mostra se a sua SBOM está completa. Abra um pacote para ver os respetivos avisos de segurança com a gravidade, e os pacotes que o exigem.
O ciclo de acompanhamento de vulnerabilidades no CRACI
- Descobrir. Cada build produz uma SBOM com um estado de completude, exportada em CycloneDX ou SPDX com as dependências transitivas. As SBOM monitorizadas, as suas e as dos seus fornecedores, são reavaliadas continuamente face aos dados de vulnerabilidades.
- Localizar. As vistas da organização sobre builds e repositórios, a vista de inventário e o histórico de builds mostram que produtos e versões são afetados, e desde quando.
- Priorizar e fazer a triagem. Cada aviso de segurança mostra a sua gravidade. As equipas de segurança fazem a triagem de cada vulnerabilidade detetada, com suporte de VEX para registar a forma como uma vulnerabilidade afeta o seu produto.
- Corrigir. Cada vulnerabilidade detetada vai para a equipa responsável pela correção, e "Required by" mostra que pacote traz uma vulnerabilidade transitiva. As policy gates podem manter uma CVE específica fora dos builds posteriores.
- Verificar. A SBOM do build seguinte mostra se a versão vulnerável desapareceu, pelo que o registo se estende até à versão corrigida.
- Reportar. O CRACI submete em seu nome as notificações de vulnerabilidades do CRA, e as SBOM são exportadas com as vulnerabilidades encontradas nos respetivos componentes.
O que acompanhar em cada vulnerabilidade
- Vulnerabilidade
- O aviso de segurança e os respetivos IDs (CVE, GHSA e outros), com a gravidade.
- Componente
- O pacote e a versão exata, e se é uma dependência direta ou transitiva.
- Caminho
- Os pacotes que trazem o pacote vulnerável, o que indica o que deve atualizar.
- Exposição
- Que produtos, versões e builds o incluem, e desde quando.
- Responsável
- A equipa responsável pela correção.
- Estado
- Em aberto, em investigação, não afetado ou corrigido, de preferência registado como VEX.
- Evidência
- O build ou a versão que já não contém a versão vulnerável.
Métricas que mostram se o acompanhamento funciona
As equipas de segurança costumam reportar quatro números:
- Tempo médio de correção (MTTR): quanto tempo passa desde que uma vulnerabilidade é encontrada até haver uma versão sem ela.
- Cumprimento dos prazos de correção: a percentagem de vulnerabilidades corrigidas dentro do prazo que a sua política define para a respetiva gravidade.
- Tendência do backlog: se o número de vulnerabilidades em aberto está a subir ou a descer.
- Janela de exposição: durante quanto tempo cada produto foi distribuído com uma versão vulnerável. O histórico de builds do CRACI mostra que builds continham uma dependência vulnerável, para que saiba durante que período esteve afetado.
O que o CRACI não faz atualmente
O CRACI não oferece análise de alcançabilidade, pelo que não ordena as conclusões consoante o seu código chame ou não a função vulnerável. Não mostra métricas de correção como o MTTR, o cumprimento de prazos ou a tendência do backlog. Atualmente não emite alertas com base num limiar de gravidade, e os seus alertas abrangem as violações da política de saída de rede. Os comentários nas conclusões, a comparação entre versões, os alertas por limiar e os webhooks de vulnerabilidades estão no roadmap.
VEX: que vulnerabilidades afetam realmente o seu produto
Um componente vulnerável na sua SBOM nem sempre significa um produto vulnerável. O código afetado pode não estar incluído naquilo que distribui, ou pode não ser alcançável da forma que um ataque exige. O VEX (Vulnerability Exploitability eXchange) é uma forma legível por máquina de o declarar: cada declaração VEX liga um produto, uma vulnerabilidade e um estado. Os estados padrão são not affected, affected, fixed e under investigation.
Isto torna-se importante quando os clientes e as autoridades verificam as suas SBOM face a bases de dados de vulnerabilidades. Sem uma declaração VEX, cada correspondência parece um problema em aberto, e a sua equipa acaba por explicar os mesmos falsos positivos uma e outra vez. O CRACI suporta VEX para registar a forma como uma vulnerabilidade afeta o seu produto, a par da triagem que envia cada vulnerabilidade detetada para a equipa responsável pela correção.
Quer saber quanto há para acompanhar? Veja quantas CVE são publicadas por dia e como cresceu o volume de vulnerabilidades High e Critical.
Acompanhamento de vulnerabilidades, explicado
Perguntas frequentes sobre o acompanhamento de vulnerabilidades no software que desenvolve e adquire
O que é o acompanhamento de vulnerabilidades?
O acompanhamento de vulnerabilidades é o registo contínuo de todas as vulnerabilidades conhecidas que afetam o seu software, desde o momento em que são encontradas até serem corrigidas ou descartadas: em que componente e versão estão, que produtos e versões as incluem, quem é responsável pela correção e qual é o seu estado. Para o software que distribui, parte de uma lista exata de componentes, que é precisamente o que uma SBOM fornece.
Quais são as etapas da gestão de vulnerabilidades?
O ciclo habitual tem cinco etapas: descobrir as vulnerabilidades naquilo que executa ou distribui, priorizá-las, corrigi-las, verificar que a correção as eliminou e reportar. O acompanhamento é o que liga as etapas, para que nenhuma vulnerabilidade detetada se perca entre a descoberta e uma versão corrigida. No CRACI, as etapas são registar a SBOM durante o build, fazer a triagem de cada vulnerabilidade detetada, encaminhá-la para a equipa responsável, confirmar que um build posterior já não contém a versão vulnerável e reportar através das exportações de SBOM e das notificações do CRA.
Como se acompanha a correção de vulnerabilidades?
Atribua a cada vulnerabilidade um responsável e um estado, e feche-a apenas quando um build ou uma versão já não contiver a versão vulnerável. Meça quanto tempo demoram as correções, se cumprem os seus prazos e se o volume de vulnerabilidades em aberto está a diminuir. No CRACI, a SBOM de cada build mostra se a versão vulnerável ainda lá está, e uma policy gate pode manter uma CVE específica fora dos builds posteriores.
O que é a gestão de vulnerabilidades com base em SBOM?
A gestão de vulnerabilidades com base em SBOM consiste em cruzar os componentes listados nas suas listas de materiais de software com os dados de vulnerabilidades, e voltar a fazê-lo à medida que são publicadas novas vulnerabilidades. O resultado só é tão bom quanto a SBOM. O CRACI regista a SBOM enquanto o build decorre, pelo que a lista reflete o que o build efetivamente obteve, incluindo pacotes restaurados de caches de CI.
Em que difere o acompanhamento de vulnerabilidades da análise de vulnerabilidades?
Uma análise é um momento no tempo: lê ficheiros, reporta conclusões e termina. O acompanhamento mantém as conclusões, os respetivos responsáveis e o seu estado ao longo do tempo, e continua a verificar o software distribuído à medida que surgem novas vulnerabilidades. O CRACI regista, não analisa: regista cada build e depois reavalia continuamente as SBOM monitorizadas.
O CRACI acompanha vulnerabilidades em software de terceiros?
Sim. Pode adicionar SBOM de fornecedores, e esses componentes adquiridos são monitorizados a par do software que desenvolve no CRACI.
O CRACI pode bloquear um build que contenha uma vulnerabilidade conhecida?
Sim. As policy gates podem bloquear um build com base nas conclusões, incluindo qualquer build que contenha uma CVE específica, para que uma vulnerabilidade que já corrigiu não volte num build posterior.
Como é que o CRACI me notifica sobre vulnerabilidades?
As conclusões aparecem nas vistas da organização do CRACI, onde as equipas de segurança fazem a sua triagem e as enviam às equipas responsáveis. Atualmente, os alertas abrangem as violações da política de saída de rede. Os alertas por limiar e os webhooks de vulnerabilidades estão no roadmap, tal como os alertas no Slack e no Teams.
O CRACI ajuda a reportar vulnerabilidades ao abrigo do CRA?
Sim. O CRACI submete em seu nome as notificações de vulnerabilidades exigidas pelo CRA: o alerta precoce, a notificação e o relatório final. O cumprimento do Cyber Resilience Act continua a ser um processo do fabricante; o CRACI automatiza uma parte significativa da visibilidade e das evidências da cadeia de abastecimento de que esse processo precisa.
O CRACI suporta VEX?
Sim. O CRACI suporta VEX (Vulnerability Exploitability eXchange) para registar a forma como uma vulnerabilidade conhecida afeta o seu produto, a par da triagem e do encaminhamento para a equipa responsável pela correção. Uma declaração VEX indica aos clientes e às autoridades se uma vulnerabilidade identificada na sua SBOM afeta realmente o produto, para que não andem atrás de falsos positivos. Marque uma demo para ver como se enquadra no seu processo de triagem.
O CRACI faz análise de alcançabilidade?
Não. O CRACI não oferece análise de alcançabilidade (reachability). Mostra que builds, repositórios e produtos seus contêm um componente vulnerável, e suporta VEX para registar a forma como uma vulnerabilidade afeta o seu produto.
Veja o acompanhamento de vulnerabilidades nos seus próprios builds
Marque uma demo e mostraremos que vulnerabilidades chegam ao software que distribui, e quem é responsável por cada correção
Marcar uma demo