0 
0 “Você não pode melhorar o que você não mede” é uma sabedoria frequentemente citada e frequentemente atribuída ao famoso consultor de gestão Peter Drucker.
É difícil descartar a verdade central do ditado, mesmo que – para registro – ele não o tenha dito, de acordo com o Drucker Institute . Afinal, métricas de vendas trimestrais a KPIs individuais são a base para remuneração, promoções e muito mais nas organizações do século XXI. Há também evidências abundantes – de BF Skinner, por exemplo – de que os humanos adaptam rapidamente seus comportamentos à forma como são medidos e incentivados.
A questão que não é feita é se as coisas certas estão sendo medidas, ou se as medições em questão são completas o suficiente para não distorcer as percepções (e decisões) daqueles que estão medindo. Esses tipos de perguntas inconvenientes informaram pesquisas patrocinadas pela ReversingLabs, a empresa que cofundei, que analisou seis meses de relatórios para o National Vulnerability Database (NVD)mantido pelo National Institute of Standards and Technology (NIST).
2022: um ano marcante para CVEs
Nossa análise descobriu que os relatórios de vulnerabilidade de novas Vulnerabilidades e Exposições Comuns (CVEs) ao NVD estão acelerando, com 2022 a caminho de ser o maior ano de todos os tempos para novos relatórios de vulnerabilidade. Se a tendência atual se mantiver, haverá mais de 24.500 relatórios até o final do ano. Isso marcaria um aumento de 22% em relação a 2021, que também foi um ano recorde.
Esses números parecem sugerir que a segurança do software está se deteriorando e que são necessárias intervenções mais vigorosas do setor público e privado para reforçar a segurança do software. Mas há muita coisa que está faltando nessa tomada rápida. Em suas duas décadas de existência, o NVD teve um crescimento inconsistente no número de vulnerabilidades e exposições relatadas. Antes de 2005, o número anual de vulnerabilidades atribuídas a um identificador CVE nunca excedia 2.500. Por mais de uma década depois disso, as edições divulgadas oscilaram entre 4.000 e 8.000 relatórios por ano.
O número de novos CVEs naqueles anos refletiu a capacidade limitada da equipe CVE na corporação sem fins lucrativos MITRE, que foi encarregada de receber e documentar novos relatórios CVE. Sabemos disso, porque uma vez que o MITRE começou a convidar mais organizações para relatar vulnerabilidades como CVE Number Authorities (CNAs) em 2016, o número de vulnerabilidades aumentou. Ele dobrou em 2017 e, desde então, superou o recorde do ano anterior de CVEs relatados.
A mensagem: considerar uma métrica como o número de novos CVEs é um exercício sem sentido se você estiver tentando avaliar o estado geral da segurança do software. Mais empresas contribuintes resultarão em mais CVEs. Menos empresas contribuintes produzirão uma queda nos CVEs. A linha de tendência geral não tem sentido — pelo menos enquanto a participação no programa CVE e os envios ao NVD por fornecedores de software forem voluntários.
Segurança da Cadeia de Suprimentos de Software: Não Mensurada e Não Melhorada
Quanto à questão de saber se as coisas certas estão sendo medidas? Aqui, novamente, a configuração atual do NVD é enganosa e fortemente inclinada para os “suspeitos usuais”. As distribuições Linux Fedora e Debian representaram 1.123 e 958 vulnerabilidades, respectivamente, no primeiro semestre de 2022 e ocupam o primeiro e terceiro lugar na lista de empresas de software afetadas por problemas relatados, revelou nossa pesquisa. Google, Microsoft, Oracle e Apple responderam por mais de 500 vulnerabilidades cada.
O NVD tem muito menos a dizer sobre falhas em plataformas populares de código aberto que estão chamando a atenção de atores cibernéticos sofisticados. Por exemplo, nossa pesquisa mostra que os ataques aos repositórios de pacotes de software populares NPM e Python Package Index (PyPI) aumentaram 289% nos últimos anos, para 1.010 em 2021, de 259 em 2018. Mas apenas 56 CVEs que fazem referência ao PyPI estão no NVD . O proprietário do PyPi, a Python Software Foundation, não é um CNA. Outras plataformas populares de desenvolvimento e CI/CD como CodeCov, CircleCI e Bamboo também não são CNAs.
Pergunta desconfortável: podemos confiar no código?
O que essa desconexão significa para o futuro de recursos públicos como o NVD? Mudança, por um lado. Eventos recentes – como o sequestro do popular projeto ua-parser-js por um criptominerador – mostram que mesmo projetos aparentemente seguros podem ser comprometidos.
A lição de incidentes como esse é que as equipes de segurança de software precisam expandir seu foco além da verificação de vulnerabilidades e até mesmo da análise de código-fonte para ver o que o código está fazendo. Contanto que ignoremos essa questão central – podemos confiar no código? — não estamos abordando a segurança da cadeia de suprimentos de software.
O NIST e o governo federal também estão avançando lentamente para implementar a ordem executiva de um ano da Casa Branca para melhorar a segurança cibernética do país , que exige que todos os contratados do governo federal e fornecedores de software criem uma lista de materiais de software (SBOM) que pode ser revisada. Diretrizes práticas recentemente divulgadas pela NSA, CISA e ODNI detalham ainda mais as etapas que as organizações podem tomar para proteger as cadeias de fornecimento de software .
Para acompanhar essas mudanças maiores, no entanto, o NVD também precisa evoluir. No mínimo, seu escopo deve se expandir para incluir consistentemente exposições da cadeia de suprimentos de software. Só então o NVD se aproximará de representar toda a amplitude de ameaças enfrentadas pelas organizações modernas.
FONTE: DARK READING