Como escalar uma PSIRT: responder a «estou afetado?» quando as perguntas se multiplicam

Não é possível contratar pessoas ao ritmo de um volume crescente de pedidos, nem acelerar a triagem indefinidamente. Uma PSIRT escala quando responde à maioria das perguntas «estou afetado?» com dados que registou no momento em que cada versão foi compilada, e quando publica a resposta antes de os clientes perguntarem. Hoje, o passo caro é perguntar à engenharia o que contém um produto. Passe esse passo para o momento do build, e a maioria dos pedidos torna-se uma consulta que o suporte consegue fechar.

Este artigo parte do princípio de que já tem uma PSIRT em funcionamento; se está a criar uma, comece por o que é uma PSIRT e como criar uma. A seguir: porque mudou o volume, onde se perde o tempo no processo habitual e o que mudar, por ordem.

Porque mudou o volume

O aumento é estrutural, não um mau trimestre. Há quatro fatores a pressionar a mesma fila ao mesmo tempo.

Mais CVE. O CVE Program publicou 39 718 registos CVE em 2024 e 47 801 em 2025. Em 2026, a contagem ultrapassou o total de todo o ano de 2025 muito antes do fim do ano; as nossas tendências de publicação de CVE em direto acompanham-na dia a dia. A atualização de 2026 da previsão de vulnerabilidades da FIRST (15 de junho de 2026) elevou a estimativa para o ano para cerca de 66 000 CVE e apontou a causa sem rodeios: a IA consegue encontrar significativamente mais falhas do que os analistas humanos, e «a limitação já não é a descoberta; é a capacidade humana de verificar, coordenar e corrigir». Uma PSIRT é essa capacidade humana.

Os clientes analisam o seu produto. Os clientes correm scanners sobre as suas imagens, firmware e appliances e reencaminham cada resultado como um ticket. A maioria desses resultados é ruído de scanner sobre componentes que não distribui ou versões que não estão afetadas, e esse ruído passa a ser a sua entrada de pedidos. Reduzir o ruído das vulnerabilidades aborda o lado do scanner.

A regulamentação acrescenta prazos. Desde 11 de setembro de 2026 aplicam-se as obrigações de notificação do Cyber Resilience Act da UE. Uma vulnerabilidade ativamente explorada num produto vendido na UE exige um alerta precoce no prazo de 24 horas após o fabricante tomar conhecimento dela.

Menos ajuda da NVD. Em 15 de abril de 2026, o NIST passou a National Vulnerability Database para um enriquecimento baseado no risco: os CVE do catálogo KEV da CISA, o software usado pelo governo federal e o software crítico segundo a EO 14028 têm prioridade, e os restantes são marcados como «Lowest Priority - not scheduled for immediate enrichment». Chegam menos CVE com dados CPE, pelo que a correspondência pelo nome do produto piora precisamente quando o volume aumenta.

Fator	O que faz à fila da PSIRT
Volume de CVE, descoberta assistida por IA	Mais CVE de terceiros para avaliar por produto, todos os meses
Análise pelos clientes	Mais pedidos por CVE, muitos sobre componentes que não distribui
Notificação ao abrigo do CRA	Um prazo de 24 horas para vulnerabilidades ativamente exploradas
Menos enriquecimento da NVD	Mais trabalho manual para associar um CVE aos produtos que afeta

Onde se perde o tempo: o processo de pedidos tal como costuma funcionar

Ouvimos o mesmo processo de equipas de segurança de produto vezes sem conta. Uma PSIRT de duas pessoas num fabricante de hardware descreveu-no-lo assim: um cliente pergunta ao serviço de suporte, o suporte encaminha a pergunta para a PSIRT através do CRM, o caso chega ao sistema de tickets da PSIRT, a PSIRT investiga os produtos sobre os quais os clientes mais perguntam, depois passa a pergunta à engenharia e espera.

Tome-se um pedido ilustrativo. Um cliente reencaminha um relatório de scanner que lista 40 CVE para a versão X do firmware. O suporte abre um caso e anexa o relatório, mas não o build exato que o cliente executa. A PSIRT verifica quais dos 40 já avaliou, encontra uma dúzia que ainda não avaliou e pergunta à equipa de engenharia responsável se os componentes estão na versão X. A engenharia tem de encontrar o código-fonte da versão X, apurar que versões de dependências entraram nela e responder. Os números são inventados; o padrão não.

A análise em si raramente é o que demora. Há dois custos ocultos:

1. O mesmo CVE é investigado de novo para cada cliente que pergunta. Quando a resposta fica numa troca de e-mails, o cliente seguinte recomeça a investigação.
2. «Primeiro os produtos mais perguntados» deixa a cauda longa sem resposta. Os produtos mais antigos ainda em uso nunca são verificados, e é muitas vezes aí que está o risco: componentes mais antigos, menos atualizações, menos pessoas que se lembram de como foram compilados.

Entrada de pedidos: separar perguntas de relatórios

O relatório de vulnerabilidade de um investigador e o «estou afetado?» de um cliente são trabalhos diferentes e precisam de caminhos diferentes. O PSIRT Services Framework da FIRST já conta com entradas desorganizadas: uma PSIRT deve «contar receber vulnerabilidades através de vários canais e com qualidade variável» (subfunção 2.1.1.1). A sua área de serviço de triagem vai mais longe: «Quando as organizações recebem um grande volume de relatórios de vulnerabilidades, podem considerar fazer uma triagem inicial para validar os relatórios antes de os casos serem criados.» Encare isso como autorização para não abrir um caso de PSIRT por cada pedido.

Divida os pedidos no serviço de suporte em três caminhos:

O cliente pergunta sobre	Caminho	Quem responde
Um CVE publicado num componente de terceiros que já avaliou	Responder com a declaração VEX ou o aviso de segurança publicado; sem caso de PSIRT	Suporte
Um CVE publicado que ainda não avaliou	Um caso de PSIRT por CVE, não por cliente; associe-lhe todos os pedidos	PSIRT, depois o suporte responde a todos os associados
Uma nova vulnerabilidade no seu próprio código	Um relatório de vulnerabilidade: o processo completo de divulgação coordenada de vulnerabilidades	PSIRT

O suporte precisa de duas coisas para seguir o primeiro caminho: uma lista pesquisável de CVE avaliados por produto e versão, e modelos de resposta. Como responder aos clientes após um ataque à cadeia de abastecimento tem modelos que pode adaptar.

Registe logo na entrada o produto e a versão exata que o cliente executa. Sem a versão, todas as respostas são «depende», e o caso volta.

Priorizar pela exposição, não só pela popularidade

«Primeiro os produtos mais perguntados» é uma heurística razoável. Precisa de um segundo eixo. Mantenha a popularidade (base instalada, receita, frequência com que o suporte pergunta) e acrescente a exposição: o produto ainda é suportado, está exposto à internet nas implementações típicas, e o CVE está no catálogo KEV da CISA ou tem uma pontuação elevada no EPSS? O guia de priorização de vulnerabilidades aborda os sinais em profundidade.

	Exposição baixa	Exposição alta
Base instalada grande	Responder a partir do inventário; publicar VEX para as versões não afetadas	Investigar primeiro; aviso de segurança e correção no prazo mais curto
Base instalada pequena	Responder a partir do inventário a pedido; sem trabalho proativo	Não o ignore: responder a partir do inventário e depois decidir entre uma correção ou um aviso de mitigação

O objetivo da matriz está na coluna da esquerda e na linha de baixo. A cauda longa recebe uma resposta a partir de dados, não de uma investigação para a qual ninguém tem tempo.

Ao abrigo do CRA, o período de suporte que declarou para cada produto determina a que produtos mais antigos ainda deve respostas e atualizações de segurança (o que o CRA exige).

A passagem para a engenharia é o estrangulamento

Esta secção destina-se ao responsável de engenharia que recebe os escalamentos da PSIRT.

Os prazos da PSIRT são públicos: um cliente, um regulador ou uma data de divulgação está à espera. Os da engenharia normalmente não são, e a PSIRT absorve a diferença. Um problema crítico passado à engenharia numa segunda-feira sem resposta até terça-feira deixa dois dias até à data em que a resposta pública tem de sair.

A PSIRT faz à engenharia duas perguntas diferentes, e só uma delas deveria precisar da engenharia:

• «O componente está no produto?» é uma pergunta de dados. Deve ser respondida a partir de um registo, não por alguém a ler ficheiros de build.
• «Consegue corrigi-lo até à data X?» é uma pergunta de trabalho. Essa cabe à engenharia.

O referencial da FIRST diz como tirar a primeira pergunta da secretária da engenharia. A função 2.3.5 pede às PSIRT que «estabeleçam canais automatizados para distribuir as notificações de vulnerabilidades de terceiros identificadas diretamente às equipas de desenvolvimento dos produtos afetados», para que os avisos de terceiros sejam tratados no processo de desenvolvimento e a PSIRT trate menos deles manualmente.

Acorde três coisas com a engenharia:

1. Um responsável por produto. Nos grandes fabricantes, a remediação está distribuída pelas equipas de produto; o modelo distribuído do referencial existe porque permite que a missão da PSIRT escale através dos engenheiros responsáveis pelos produtos.
2. Objetivos de resposta por gravidade, por escrito, para a correção e não para a investigação.
3. O que acontece quando um objetivo não é cumprido. A função 4.2.4 pede «um processo de aceitação formal do risco para quaisquer vulnerabilidades não remediadas dentro dos prazos dos SLA internos». Alguém com autoridade assina o risco; ele não fica simplesmente em aberto.

O ritmo das correções varia. Uma equipa disponibiliza um patch de um dia para o outro, outra precisa de uma atualização de plataforma de seis meses. O aviso de segurança tem de dizer qual, para que os clientes possam planear.

Transformar «estamos afetados?» numa consulta: uma SBOM para cada versão distribuída

Esta é a mudança que elimina mais trabalho. A função 2.3.1 da FIRST, o inventário de componentes do produto, considera-o «essencial para identificar rapidamente os produtos afetados por vulnerabilidades herdadas». Os níveis de maturidade de uma PSIRT colocam um registo de produtos com mapeamento de dependências no nível intermédio e a monitorização das vulnerabilidades dos componentes dos produtos no nível avançado.

Um inventário só elimina trabalho se aguentar o volume. Cada requisito abaixo tem uma razão de ser:

• Uma SBOM por versão distribuída, não por repositório nem do branch predefinido. Os clientes executam versões, não branches.
• Obtida a partir do build que produziu a versão. Um novo build mais tarde, ou uma análise do repositório de hoje, descreve outro software (SBOM no momento do build).
• Com as dependências transitivas e ocultas incluídas. O pacote vulnerável raramente é um que tenha adicionado (dependências transitivas), e scripts de instalação, imagens base e caches restauradas trazem componentes que nenhum lockfile lista.
• Um sinal de completude. Um registo parcial tratado como completo produz respostas «não afetado» confiantes e erradas.
• Conservada enquanto a versão for suportada. O registo de uma versão de há três anos é aquele de que vai precisar quando já ninguém se lembrar de como foi compilada.
• SBOM de fornecedores para componentes adquiridos, para que o software de terceiros fique no mesmo inventário que o seu.
• Cruzada continuamente com os novos CVE à medida que são publicados, em vez de voltar a ser analisada quando alguém pergunta.

Um exemplo prático. É publicado um novo CVE numa biblioteca de compressão amplamente usada. Sem o inventário, a PSIRT pergunta a todas as equipas de produto, as respostas chegam a conta-gotas ao longo de dias e os produtos mais antigos nunca são verificados. Com ele, uma consulta devolve os produtos e versões afetados, além do primeiro e do último build que continham a versão vulnerável. É essa a janela de exposição sobre a qual os clientes perguntam a seguir; estamos afetados por um CVE? mostra como apurá-la num caso concreto.

As carteiras embedded e Yocto são as que têm mais dificuldades. Os scanners que leem uma imagem de firmware acabada têm de adivinhar o que foi compilado nela, e equipas com quem falamos viram provas de conceito de scanners falhar em produtos baseados em Yocto. Registar o build enquanto decorre evita as suposições (builds Yocto no CRACI).

Quando um cliente pede depois a própria SBOM, num formato específico, consulte responder a pedidos de SBOM de clientes.

O lado da saída: avisos de segurança e VEX que respondem antes de alguém perguntar

O pedido mais barato é o que nunca chega.

• Publique «não afetado» como VEX, para que os scanners dos clientes deixem de assinalar o CVE, e publique «afetado» e «corrigido» como avisos de segurança com as versões exatas.
• Torne-o legível por máquina. A subfunção 5.3.2.3 da FIRST sugere que as PSIRT «ponderem publicar avisos num formato legível por máquina, como o Common Security Advisory Framework (CSAF)», para que os clientes os possam consumir com as suas próprias ferramentas. O guia de CSAF explica como passar de páginas web e feeds RSS para CSAF.
• Informe o suporte antes de publicar. Função 5.3.4: «Disponibilizar notificação antecipada e confidencial e FAQ sobre os avisos que vão ser publicados prepara quem possa ser questionado sobre eles no momento da publicação.» Assim, o suporte pode responder no próprio dia.
• Envie, não se limite a publicar. A subfunção 5.4.1.3 observa que um baixo número de visualizações das páginas de avisos «pode orientar a sua estratégia para a notificação proativa». Feeds e notificações chegam a clientes que nunca visitam uma página de avisos.

O CRA torna parte disto um dever. O artigo 14(8) exige que o fabricante, depois de tomar conhecimento de uma vulnerabilidade ativamente explorada ou de um incidente grave, informe os utilizadores afetados «e, se for caso disso, todos os utilizadores», e que o faça «se for caso disso, num formato estruturado, legível por máquina e facilmente processável de forma automática». O regulamento não especifica um formato.

O que automatizar, por ordem

Cada passo elimina um tipo de trabalho; a métrica mostra se o eliminou.

Passo	Trabalho que elimina	Métrica que mostra que funcionou
1. Um inventário por versão a partir do build	A pergunta «o que contém?» à engenharia	Os pedidos de investigação à engenharia por mês diminuem
2. Cruzamento contínuo dos novos CVE com todas as versões suportadas	Novas análises a pedido	Tempo desde a publicação do CVE até à decisão afetado ou não afetado
3. Um caso por CVE, com os pedidos associados	Investigações duplicadas	Os pedidos por caso aumentam, os casos por CVE ficam em um
4. Encaminhamento automático dos resultados afetados para a equipa responsável (FIRST 2.3.5)	Passagens manuais	Tempo desde a decisão até um responsável a confirmar
5. Uma biblioteca pesquisável de declarações VEX e avisos de segurança publicados	Envolvimento da PSIRT em perguntas repetidas	Percentagem de pedidos fechados pelo suporte
6. Publicação legível por máquina (CSAF)	Clientes a pedir o que as suas ferramentas poderiam ter obtido	Os pedidos por aviso publicado diminuem
7. Assistência de IA na redação de avisos e respostas	Tempo de redação	Tempo desde a decisão até ao aviso publicado

A IA fica em último lugar por uma razão. Redige bem com base em dados registados, e nunca deve ser a origem da decisão «afetado».

Há coisas que não devem ser automatizadas: o juízo «não afetado» e a avaliação da gravidade ficam com uma pessoa, com as evidências anexadas. A automação decide a rapidez com que essa pessoa recebe as evidências.

Métricas que mostram que a PSIRT está a escalar

• A percentagem de pedidos respondidos sem caso de PSIRT.
• Tempo desde a publicação do CVE até à decisão afetado ou não afetado, por produto.
• Pedidos de investigação à engenharia por mês. Devem diminuir.
• Taxa de remediação dentro do prazo por gravidade; a subfunção 4.4.2.4 do referencial define-a como a medida em que as equipas de produto cumprem o prazo acordado entre o relatório e a correção.
• Cobertura por VEX e avisos de segurança das versões que ainda suporta.

Não citamos valores de referência do setor para estas métricas. Nenhuma fonte primária em que confiemos os publica.

Onde entra o CRACI

O CRACI cobre os passos 1 e 2, e parte dos passos 4 e 5, para software compilado em GitHub Actions. Os seus builds correm nos runners do CRACI, e o CRACI regista o que cada job efetivamente obteve durante a execução: dependências diretas e transitivas, pacotes instalados por scripts e pacotes restaurados de caches de CI. A SBOM de cada job tem um estado de completude, para que um registo parcial nunca seja confundido com um completo.

O CRACI guarda o histórico de builds, pelo que, quando é publicado um novo CVE, vê que builds continham a dependência vulnerável, e desde quando, até onde chegar o seu período de retenção. As SBOM monitorizadas são reavaliadas continuamente, os resultados são agregados entre builds e repositórios, e é possível adicionar SBOM de fornecedores para que os componentes adquiridos sejam monitorizados a par dos seus próprios builds. O CRACI notifica as pessoas relevantes de uma nova vulnerabilidade e da sua gravidade. A vista de inventário mostra que versões de software estão implementadas em que produtos, e as equipas de segurança fazem a triagem de cada resultado no CRACI e encaminham-no para a equipa responsável pela correção. O CRACI suporta VEX. Consulte o CRACI para equipas PSIRT e acompanhamento de vulnerabilidades.

Veja que versões distribuídas contêm um CVE.

Quando o CRACI não é a resposta

• O seu estrangulamento é a entrada de pedidos e a gestão de casos, a parte entre o CRM e o sistema de tickets. O CRACI não é uma ferramenta de gestão de casos nem de publicação de avisos de segurança; para essa metade, precisa de uma ferramenta de casos (ferramentas de PSIRT comparadas).
• Os seus produtos não são compilados em GitHub Actions com runners Linux. O GitHub Actions é o CI suportado hoje; o GitLab CI e o Jenkins estão no roadmap, sem data.
• Precisa de análise binária ou de firmware de produtos que não compilou. É isso que fazem as ferramentas de análise do resultado final (ferramentas de segurança embedded comparadas).
• Precisa de análise de alcançabilidade para fundamentar «não afetado». O CRACI não a oferece.

Perguntas frequentes

Como escalar uma PSIRT sem contratar?

Deixe de investigar a mesma pergunta repetidamente. Registe o que cada versão distribuída contém no momento do build, cruze continuamente os novos CVE com esse registo, decida uma vez por CVE e publique a decisão como VEX ou como um aviso de segurança para o qual o suporte possa remeter. A PSIRT trata então os casos realmente em aberto, e à engenharia pede-se que corrija, não que investigue.

Como deve uma PSIRT tratar os pedidos «estamos afetados?» dos clientes?

Trate-os como um fluxo de entrada separado dos relatórios de vulnerabilidades. O suporte responde às perguntas sobre CVE que já avaliou com o material publicado. Um CVE que ainda não avaliou dá origem a um caso de PSIRT, ao qual se associam todos os pedidos de clientes. Só uma nova vulnerabilidade no seu próprio código passa pelo processo completo de divulgação.

O que diz o PSIRT Services Framework da FIRST sobre volume e automação?

Conta com relatórios «através de vários canais e com qualidade variável», permite a triagem antes da criação de casos quando o volume é elevado, considera um inventário de componentes do produto «essencial para identificar rapidamente os produtos afetados» e pede canais automatizados que enviem as notificações de vulnerabilidades de terceiros diretamente às equipas de desenvolvimento dos produtos afetados (função 2.3.5).

O que deve uma PSIRT automatizar primeiro?

O inventário por versão obtido a partir do build e, depois, o cruzamento contínuo dos novos CVE com todas as versões suportadas. Estes dois eliminam o trabalho mais repetido: a pergunta «o que contém?» à engenharia e a nova análise a pedido. A deduplicação de casos, o encaminhamento, uma biblioteca pesquisável de VEX e avisos de segurança e a publicação em CSAF vêm depois.

Como conseguir que a engenharia responda a tempo às perguntas da PSIRT?

Faça menos perguntas à engenharia. Responda a «o componente está no produto?» a partir do registo do build e envie à engenharia apenas «consegue corrigir até esta data?». Acorde um responsável por produto, objetivos de resposta por gravidade para a correção e uma aceitação formal do risco quando um objetivo não for cumprido.

Porque é que uma SBOM por versão é importante para uma PSIRT?

Os clientes executam versões específicas, muitas vezes antigas. Uma SBOM do branch predefinido nada diz sobre a versão X de há dois anos. Uma SBOM por versão distribuída, registada a partir do build que a produziu e conservada durante o período de suporte, é o que permite a uma PSIRT responder por todas as versões ainda em uso, incluindo a janela de exposição.

Os clientes querem VEX ou avisos de segurança?

Ambos, para estados diferentes. O VEX indica aos scanners dos clientes que CVE não afetam um produto, para que os resultados deixem de aparecer. Os avisos de segurança dizem às pessoas o que está afetado, o que está corrigido e o que fazer. Publicar ambos, em formato legível por máquina sempre que possível, responde à maioria das perguntas antes de serem feitas.