A cadência de correções de um fornecedor, isto é, a velocidade com que um fornecedor de software identifica, desenvolve e lança correções para vulnerabilidades conhecidas em seu software, é uma das dimensões mais importantes, porém menos rigorosamente avaliadas, da segurança da cadeia de suprimentos de software. Os questionários de TPRM rotineiramente pedem que os fornecedores informem seus SLAs de correção: com que rapidez se comprometem a corrigir vulnerabilidades de gravidade crítica, alta, média e baixa. Os fornecedores rotineiramente dão respostas no nível da política que descrevem seu compromisso declarado ou desejado. O que raramente se avalia é se esse compromisso declarado é de fato cumprido: se o tempo médio entre a publicação da vulnerabilidade e o lançamento da correção está alinhado à política e se todas as vulnerabilidades críticas acabam sendo corrigidas.
A lacuna entre política e cumprimento é o problema central. Um fornecedor que declara um SLA de correção de vulnerabilidades críticas de 30 dias e alcança uma média de 73 dias não está cumprindo a política declarada, mas isso não ficará visível em um questionário que pergunta sobre a política em vez de medir o cumprimento. A medição exige examinar o histórico real de lançamentos do fornecedor e correlacioná-lo com os prazos de CVE publicados: quando a vulnerabilidade foi publicada, quando a correção ficou disponível e se isso é consistente em todo o conjunto de vulnerabilidades publicadas. Essa análise é possível com dados públicos (datas de publicação no NVD, notas de versão do fornecedor e acompanhamento de CVE), mas exige um esforço que um questionário padrão não exige.
O problema das vulnerabilidades não corrigidas é a exposição específica de TPRM. Vulnerabilidades críticas que nunca são corrigidas representam um risco permanente para toda empresa que executa a versão afetada do software. A política de correção em 30 dias do fornecedor não trata das vulnerabilidades que simplesmente não são corrigidas: descreve apenas o prazo pretendido para as correções que são produzidas. Quatro das catorze vulnerabilidades críticas do fornecedor no último ano continuam sem correção após a janela declarada de 30 dias. Para as empresas que executam essas versões do software, a vulnerabilidade não é um risco de 30 ou de 73 dias: é um risco persistente, sem correção programada.
Por que isso importa
A realidade da cadência de correções é relevante porque o software que a sua empresa implanta continua acumulando risco de vulnerabilidades entre a avaliação inicial e a próxima revisão planejada do fornecedor. Um fornecedor que corrige devagar ou de forma incompleta é um fornecedor cujo software se torna progressivamente mais vulnerável com o tempo. A empresa que confirmou a política de correção em 30 dias do fornecedor sem medir seu cumprimento executa um software significativamente mais vulnerável do que a confirmação da política sugere.
- Política de correções confirmada sem medição do cumprimento
- Tempo médio de correção não calculado a partir de dados históricos de lançamentos e de CVE
- Vulnerabilidades não corrigidas não identificadas: a política pergunta sobre o SLA, não sobre a cobertura
- Ausência de monitoramento contínuo de correções: apenas confirmação pontual da política
- Atualização da versão de software implantada não acompanhada em relação à versão corrigida mais recente
Como é uma boa prática
Programas maduros de cadência de correções de fornecedores medem o cumprimento real das correções a partir de dados históricos: calculam o tempo médio entre a publicação do CVE e o lançamento da correção para o software do fornecedor, identificam vulnerabilidades não corrigidas e acompanham a atualização da versão implantada pela empresa em relação à versão corrigida mais recente.
- Análise histórica do cumprimento das correções: publicação do CVE em comparação com o prazo de lançamento da correção
- Identificação de vulnerabilidades não corrigidas: CVEs de software sem correção
- Acompanhamento da atualização da versão implantada: versão atual em comparação com a versão corrigida mais recente
- Monitoramento contínuo de correções: monitoramento de CVE para o software implantado
- Métrica de cumprimento do SLA de correções: política em comparação com a prática nas avaliações de fornecedores
Ferramentas
Monitoramento de Correções: Vulncheck e Recorded Future para análise da publicação de CVE e dos prazos de correção; Snyk para monitoramento contínuo do software implantado
Plataformas de inteligência de vulnerabilidades fornecem prazos de publicação de CVE e acompanhamento dos lançamentos de correções dos fornecedores, o que permite calcular o cumprimento da cadência de correções a partir de dados públicos. Para profissionais de TPRM, calcular o tempo médio entre a publicação do CVE e o lançamento da correção pelo fornecedor para um produto de software nos últimos doze meses é uma medição específica e objetiva da cadência de correções que declarações de política não podem substituir.
Desafios de governança
O desafio de governança da avaliação da cadência de correções é o esforço de coleta de dados. Calcular o cumprimento real das correções a partir de dados de CVE e de lançamentos exige levantar as datas históricas de publicação de cada CVE, encontrar as notas de versão do fornecedor que tratam de cada CVE e calcular a diferença. Isso é viável para CVEs críticos, mas trabalhoso para uma análise abrangente. A solução de governança é priorizar a análise do cumprimento real das correções para fornecedores de software críticos e usar o monitoramento automatizado de vulnerabilidades para a cobertura contínua do software implantado.
- Calcule o cumprimento real das correções pelos fornecedores de software críticos, não apenas a política
- Identifique CVEs críticos não corrigidos no software implantado
- Acompanhe a atualização da versão implantada: implantação atual em comparação com a versão corrigida mais recente
- Implemente o monitoramento contínuo de CVE para o software implantado
- Inclua os dados de cumprimento das correções na reavaliação de fornecedores, junto com a política
Se você faz parte de uma equipe pequena
Para os seus três fornecedores de software mais críticos, levante os CVEs publicados para o software deles nos últimos doze meses e as datas de lançamento das correções que os trataram. Calcule o tempo médio entre a publicação do CVE e a disponibilidade da correção. Em seguida, verifique se algum CVE crítico não foi corrigido em uma versão lançada. Essa análise, feita com o NVD, o MITRE CVE e as notas de versão do fornecedor, dirá se o SLA de correção em 30 dias é a descrição de uma prática ou uma declaração de intenção.
- Levante os CVEs dos três principais fornecedores de software nos últimos 12 meses
- Calcule o tempo médio entre a publicação do CVE e o lançamento da correção
- Identifique CVEs críticos não corrigidos
- Acompanhe a atualização da versão implantada em relação à versão corrigida mais recente
O que exigir
Pergunte diretamente:
“Qual foi o seu tempo médio entre a publicação de um CVE crítico e o lançamento da correção nos últimos doze meses, e há algum CVE crítico publicado nos últimos doze meses para o seu software que ainda não tenha sido tratado em uma correção lançada?”
O que esperar como evidência
- Dados históricos de prazos das correções: publicação do CVE em comparação com o lançamento da correção
- Lista de CVEs críticos não corrigidos com prazo de remediação
- Cadência média de correções por gravidade
- Confirmação da atualização das correções na versão implantada
A um fornecedor que confirma um SLA de correção em 30 dias, devem-se pedir seus dados reais de cumprimento das correções. A política descreve o compromisso. Os dados históricos descrevem o desempenho. Ambos são necessários para avaliar o risco real de executar o software desse fornecedor.
Como comprovar
- Registros da análise histórica do cumprimento das correções
- Acompanhamento de CVE não corrigidos
- Monitoramento da atualização da versão implantada
- Cumprimento do SLA de correções na avaliação de fornecedores
Principal conclusão
SLA de correção em 30 dias: confirmado. Tempo médio real de correção: 73 dias. CVEs críticos não corrigidos: 4 de 14. A política era real. O cumprimento, não. O questionário perguntou sobre a política. Os dados de prazos das correções revelaram a lacuna de cumprimento. A confirmação da política descreve o que o fornecedor pretende. Os dados históricos de cumprimento descrevem o que ele entrega. Para o risco da cadeia de suprimentos de software, é o que ele entrega, e não o que pretende entregar, que determina a exposição real a vulnerabilidades da empresa que executa seu software.