O ciclo de vida da gestão de vulnerabilidades para fornecedores de software

O que é o ciclo de vida da gestão de vulnerabilidades?

O ciclo de vida da gestão de vulnerabilidades é o processo repetível que um fornecedor de produtos segue para tratar uma vulnerabilidade no software que distribui: recebê-la ou encontrá-la, verificá-la, determinar o que é afetado, corrigi-la, lançar a correção e informar os clientes. Numa organização fornecedora, é normalmente conduzido por uma equipa de resposta a incidentes de segurança de produto (PSIRT), com as equipas de engenharia a fazer as correções.

Esta página cobre o lado do fornecedor. A gestão de vulnerabilidades de TI, que analisa e aplica patches aos servidores e portáteis que uma organização gere, partilha o vocabulário, mas não as partes difíceis. Um fornecedor tem de responder por todas as versões suportadas nas mãos dos clientes e tem de publicar o que encontrou.

As fases do ciclo de vida

1. Receber ou descobrir. As vulnerabilidades chegam de investigadores externos através do seu programa de divulgação, de clientes, de coordenadores como os CSIRT nacionais e da sua própria monitorização: uma nova CVE numa dependência open source, uma conclusão de um scanner ou um teste interno. Registe cada uma com um identificador de acompanhamento e confirme a receção aos autores externos dos relatórios.
2. Verificar e fazer a triagem. Reproduza o problema ou confirme a correspondência da dependência, decida se é uma vulnerabilidade no seu produto e avalie quão grave e quão urgente é. Feche o que não se aplica, com uma justificação que possa apresentar mais tarde. Sinais de priorização como o EPSS e o catálogo CISA KEV ajudam a ordenar o que resta.
3. Avaliar os produtos e as versões afetados. Encontre todos os produtos, versões e branches suportadas que contêm o código ou o componente vulnerável, e todas as implementações de clientes que executam um deles. Este passo decide o âmbito da correção e do aviso de segurança.
4. Remediar. A equipa responsável desenvolve e testa uma correção: uma dependência atualizada, uma alteração de código ou uma mitigação, como uma alteração de configuração, quando ainda não é possível uma correção.
5. Lançar a correção. Distribua versões atualizadas para cada branch suportada afetada, através de um canal em que os clientes possam confiar.
6. Avisar e divulgar. Publique um aviso de segurança que diga o que é afetado, qual a gravidade e o que fazer, atribua ou refira um identificador CVE e dê crédito ao autor do relatório. Formatos legíveis por máquina como CSAF e VEX permitem que os clientes processem os avisos automaticamente.
7. Monitorizar e aprender. Esteja atento à exploração e a novas informações, atualize o aviso de segurança e transmita a causa raiz ao desenvolvimento, para que a mesma classe de falha não volte a ser distribuída.

ISO/IEC 30111 e ISO/IEC 29147

Duas normas internacionais descrevem este ciclo de vida para os fornecedores. Dividem-no na fronteira da organização:

	ISO/IEC 30111:2019	ISO/IEC 29147:2018
Título	Vulnerability handling processes	Vulnerability disclosure
Abrange	O que acontece internamente: verificar, investigar, priorizar e remediar	As interfaces: receber relatórios e publicar avisos de segurança
Conteúdo principal	Política e organização, responsabilidades da PSIRT, fases de tratamento, considerações sobre a cadeia de abastecimento	Papéis das partes interessadas, tratamento de relatórios, conteúdo dos avisos, coordenação, política de divulgação
Público	Fornecedores que tratam vulnerabilidades reportadas	Fornecedores que recebem relatórios e divulgam vulnerabilidades

As normas foram concebidas para serem usadas em conjunto. A ISO/IEC 30111 indica seis fases de tratamento: preparação, receção, verificação, desenvolvimento da remediação, lançamento e pós-lançamento. Pede também a monitorização do processo, a confidencialidade da informação sobre vulnerabilidades e atenção à cadeia de abastecimento, uma vez que muitas vulnerabilidades estão em componentes que não escreveu. Ambas as normas são edições atuais, confirmadas nas suas últimas revisões da ISO, e estão assinaladas para revisão.

Outros referenciais seguem a mesma estrutura. O FIRST PSIRT Services Framework agrupa o trabalho em descoberta de vulnerabilidades, triagem e análise, remediação e divulgação, e a IEC 62443-4-1 inclui a gestão de atualizações de segurança e de defeitos no seu ciclo de vida de desenvolvimento seguro para produtos industriais.

Papéis

• PSIRT ou equipa de segurança de produto: é responsável pelo processo, recebe relatórios, faz a triagem, coordena as correções e publica avisos de segurança. Consulte CRACI para equipas PSIRT e em que uma PSIRT difere de um CSIRT.
• Equipas de produto e de engenharia: são responsáveis pelo código, desenvolvem e testam as correções e distribuem as versões.
• Gestão de lançamentos: decide que branches suportadas recebem uma correção e quando.
• Apoio ao cliente e comunicação: tratam das perguntas dos clientes e do público do aviso de segurança.
• Jurídico: aconselha sobre divulgação, contratos e notificações regulamentares.
• Partes externas: autores de relatórios, coordenadores como o CERT/CC ou um CSIRT nacional, responsáveis pela manutenção a montante dos componentes afetados e clientes que têm de implementar a correção.

Prazos e SLA

Não existe um prazo único obrigatório. A maioria dos fornecedores define metas internas por gravidade e publica as externas na sua política de divulgação. Uma estrutura típica:

• Confirmar a receção de um relatório externo em poucos dias úteis.
• Fazer a triagem em poucos dias, para que o autor do relatório e a equipa responsável saibam em que ponto está.
• Remediar num prazo definido pela gravidade e pela exploração, mais curto para as conclusões críticas e para tudo o que se saiba estar a ser explorado.
• Divulgar quando a correção estiver disponível, ou num prazo acordado se a correção se atrasar.

A pressão externa define o limite máximo. Os investigadores definem muitas vezes um prazo de divulgação (o Google Project Zero dá 90 dias aos fornecedores), e a regulamentação está a acrescentar os seus próprios: o Cyber Resilience Act da UE exige que os fabricantes corrijam vulnerabilidades sem demora e define prazos de reporte para as ativamente exploradas (consulte o que o CRA exige). Quando uma vulnerabilidade já está a ser explorada, como num zero-day, todas as fases decorrem no prazo mais curto.

Onde o ciclo de vida falha

A maioria dos atrasos não está em escrever a correção. Vem de não saber o que distribuiu.

• Não saber que versões contêm um componente. Surge uma nova CVE numa biblioteca. Quais das versões do ano passado a incluem, e que clientes as executam? Sem um registo por versão, as equipas recompilam tags antigas ou procuram manualmente nos repositórios, e a lista de versões afetadas no aviso de segurança é um palpite.
• Dependências transitivas. Muitos pacotes vulneráveis não foram escolhidos por si. Chegam como dependências transitivas vários níveis abaixo, pelo que uma pesquisa nos seus manifestos não os encontra.
• Ruído das dependências de desenvolvimento. Os scanners que leem lockfiles reportam frameworks de teste e ferramentas de build que nunca são distribuídas. Cada uma custa tempo de triagem e esconde as conclusões que importam.
• Componentes fora do gestor de pacotes. Os binários descarregados por scripts de build, as imagens base e os componentes de fornecedores não aparecem de todo num lockfile.
• Responsabilidade pouco clara. Uma conclusão sem equipa responsável fica à espera. A triagem só termina quando a correção tem um responsável.
• Correções que não perduram. Uma versão vulnerável regressa através de outra dependência ou de uma branch antiga, porque nada a impede de entrar no build seguinte.

Métricas

Métrica	O que mostra
Tempo até confirmar a receção	Se os autores de relatórios recebem resposta quando a sua política diz que recebem
Tempo até à triagem	Quanto tempo uma conclusão espera até alguém saber se importa
Tempo até à remediação, por gravidade	A rapidez com que as correções são distribuídas, medida da receção a uma versão disponível
Tempo até ao aviso de segurança	Quanto tempo os clientes esperam por informação depois da correção
Percentagem dentro da meta	Se os SLA internos são cumpridos, sobretudo para conclusões críticas e exploradas
Backlog por antiguidade	As conclusões bloqueadas, e onde
Taxa de não afetados	Quanto esforço de triagem vai para conclusões que não se aplicam

Meça cada fase separadamente. Um tempo longo até à remediação revela-se muitas vezes um tempo longo a encontrar as versões afetadas.

Conduza o ciclo de vida com base num registo do que distribuiu

Todas as fases depois da triagem dependem de saber o que está em cada versão. O CRACI executa os seus builds de GitHub Actions em runners próprios e regista os pacotes que cada job realmente obteve, incluindo dependências transitivas, pacotes restaurados de caches de CI e dependências que nenhum lockfile lista. Cada SBOM tem um estado de completude e pode ser exportada em CycloneDX ou SPDX.

O CRACI reavalia continuamente as SBOM monitorizadas e agrega-as entre builds e repositórios, e é possível acrescentar SBOM de fornecedores para que os componentes adquiridos sejam monitorizados a par dos seus. Quando surge uma nova CVE, o histórico de builds mostra que builds anteriores continham a dependência vulnerável, direta ou transitiva, para que saiba durante que período esteve afetado, e a vista de inventário mostra que versões de software estão implementadas em que produtos. As equipas de segurança fazem a triagem das conclusões no CRACI e enviam-nas para as equipas responsáveis pela correção, o CRACI suporta VEX, e os policy gates podem bloquear builds que contenham uma CVE específica, para que uma vulnerabilidade corrigida fique de fora. Consulte acompanhamento de vulnerabilidades.

Ciclo de vida da gestão de vulnerabilidades: perguntas frequentes

Quais são as fases do ciclo de vida da gestão de vulnerabilidades?

Para um fornecedor de produtos: receber ou descobrir a vulnerabilidade, verificá-la e fazer a triagem, encontrar os produtos e as versões afetados, desenvolver a remediação, lançar a correção, publicar o aviso de segurança e depois monitorizar e aprender. A ISO/IEC 30111 indica as fases de preparação, receção, verificação, desenvolvimento da remediação, lançamento e pós-lançamento.

O que é a ISO/IEC 30111?

A ISO/IEC 30111:2019 é a norma internacional para os processos de tratamento de vulnerabilidades. Dá aos fornecedores requisitos e recomendações para processar e remediar vulnerabilidades reportadas nos seus produtos e serviços, desde a política e o papel da PSIRT até às fases de tratamento e às considerações sobre a cadeia de abastecimento.

Qual é a diferença entre a ISO/IEC 30111 e a ISO/IEC 29147?

A ISO/IEC 29147 cobre a parte externa: receber relatórios e publicar avisos de segurança. A ISO/IEC 30111 cobre o tratamento interno entre ambos: verificar, investigar, priorizar e corrigir. As duas foram concebidas para serem usadas em conjunto. Consulte divulgação coordenada de vulnerabilidades para o lado da 29147.

O que é a triagem de vulnerabilidades?

A triagem é o passo em que uma equipa de segurança confirma que uma vulnerabilidade reportada ou descoberta é real, avalia quão grave e quão urgente é para o seu produto e a envia para a equipa responsável pela correção. Uma boa triagem também fecha as conclusões que não se aplicam, com uma justificação registada.

Em que difere a gestão de vulnerabilidades de produto da gestão de vulnerabilidades de TI?

A gestão de vulnerabilidades de TI aplica patches aos sistemas que uma organização gere. A gestão de vulnerabilidades de produto trata de falhas no software que a organização compila e distribui a terceiros, pelo que acrescenta passos que as equipas de TI não têm: determinar que versões lançadas são afetadas, distribuir uma correção aos clientes e informá-los através de um aviso de segurança.

Que métricas deve acompanhar um processo de tratamento de vulnerabilidades?

O tempo até confirmar a receção de um relatório, até à triagem, até à remediação e até ao aviso de segurança, cada um por gravidade, mais a percentagem de conclusões que cumprem as suas metas internas, o backlog aberto por antiguidade e quantas conclusões foram fechadas como não afetadas.