O que é necessário para o sucesso do SBOM? (Perguntas e respostas)

As empresas estão cada vez mais recorrendo às listas de materiais de software (SBOM) para entender os componentes internos dos produtos de tecnologia que usam para proteger sua cadeia de suprimentos de software.

Mas os SBOMs realmente fornecem valor? E como eles podem ser usados ​​de forma mais eficaz? Conversamos com Varun Badhwar, CEO e cofundador da Endor Labs, para descobrir as chaves para usar SBOMs com sucesso.

BN: Por que ter um SBOM se tornou tão importante?

VB: Não é sobre o SBOM em si; é mais que o desenvolvimento de software moderno já é muito complexo e não mostra sinais de se tornar mais simples de proteger. A grande maioria do código em novas soluções de software não é escrita pelos desenvolvedores; em vez disso, é puxado para cada novo projeto sem a aprovação ou mesmo conhecimento dos desenvolvedores. Eles normalmente não sabem de onde veio, como está sendo usado e quão seguro é. Essas são dependências indiretas ou transitivas, onde a menor vulnerabilidade pode ser explorada para lucro.

Enquanto isso, o ambiente externo está sem dúvida ainda mais nublado. Após várias violações e outros problemas originados com dependências transitivas, há uma infinidade de requisitos regulatórios e legislativos em vigor. De uma Ordem Executiva da Casa Branca ao National Defense Authorizations Act de 2023, o governo está colocando regras em prática que são mais específicas do que nunca.

Em muitas dessas situações, um SBOM não é a única resposta, mas geralmente é parte da resposta.

Os SBOMs ganharam importância e visibilidade porque um SBOM abrangente fornece transparência em um processo muito nebuloso. Ele apresenta uma lista de (idealmente) todos os componentes de software usados ​​para construir um aplicativo ou produto. Esse nível de visibilidade torna mais fácil responder a perguntas sobre facilidade de uso, problemas de segurança e muito mais.

BN: Quando você deve exigir um SBOM de um fornecedor?

VB: Você pode não precisar de um SBOM de cada fornecedor cujo produto você usa. Um primeiro passo melhor pode ser identificar os provedores de serviços mais críticos e soluções prontas para uso. Se as operações dependem de dados mantidos por terceiros — e isso inclui quase todo mundo — então é importante determinar o que aconteceria se esses dados sofressem uma perda de confidencialidade, integridade ou disponibilidade.

Mapeie o que aconteceria no “pior cenário”, trabalhando com seus vários departamentos de negócios para determinar quais seriam os custos financeiros de cada um.

Depois de estabelecer o impacto potencial de uma violação para cada fornecedor, você pode classificá-los em ordem decrescente. Com base em seus recursos e apetite de risco organizacional, você precisará traçar uma linha em algum lugar sobre onde focar sua análise.

Para algumas organizações com necessidades rigorosas de segurança, cada fornecedor com qualquer impacto nos dados precisará fornecer um SBOM. Para outras, pode ser obrigatório apenas para um subconjunto de provedores críticos.

Também é importante ter em mente a sofisticação dos seus próprios fornecedores. Eles são atualmente capazes de fornecer um SBOM? Uma startup altamente especializada pode explicar razoavelmente que está concentrando todos os seus esforços na resolução de um problema específico em vez de fornecer representações detalhadas da composição do seu software. Um fornecedor empresarial mais maduro, no entanto, deve ser mais capaz de fornecer o que você precisa.

BN: O que é preciso observar em um SBOM e como analisá-lo de forma eficaz?

VB: O termo SBOM tem sido amplamente usado, e ainda mais amplamente interpretado, mas é tipicamente um inventário de todos os componentes que compõem um pedaço de software. Ele inclui detalhes sobre cada componente, e pode ser usado para verificar se uma versão de um pacote de software tem alguma vulnerabilidade conhecida. Ele deve detalhar todas as dependências, diretas e indiretas, abrangendo fonte, nível de segurança, licença, expiração, atualizações e mais.

Existem ferramentas disponíveis atualmente para identificar CVEs em SBOMs, mas mais análises são necessárias. A melhor é a análise de acessibilidade, que envolve uma passagem 'para frente' no gráfico de chamadas, começando pelo cliente e verificando quais pacotes no conjunto de dependências podem ser alcançados. Existem outros métodos de análise também, mas a chave é descrever as saídas em um formato consistente e facilmente consumível.

BN: Se você identificar uma vulnerabilidade de um SBOM, qual será seu próximo passo?

VB: Simplesmente encontrar vulnerabilidades não é a resposta. Existem várias maneiras de identificar vulnerabilidades e exposições comuns (CVEs) ocultas no código — é assim que obtemos o fluxo infinito de alertas falsos que drenam a produtividade e causam fadiga. A complicação relacionada é que, enquanto os desenvolvedores rastreiam os pacotes, a reutilização real ocorre no nível do código. A estratégia aqui é de prioridade: como uma organização pode determinar quais vulnerabilidades representam o maior risco para a operação e como os riscos podem ser remediados?

Uma boa opção é a análise de acessibilidade. Essa abordagem rastreia os elementos específicos do código em uma dependência que está sendo reutilizada, o que ajuda a organização a estabelecer se um problema de segurança no código afeta o projeto, se uma atualização de dependência é segura e até mesmo se remoções de código afetarão outros usuários em potencial. Esse não é o único caminho a seguir, mas o objetivo é sempre o mesmo: as organizações precisam descrever saídas relevantes em termos consistentes e abrangentes.

Supondo que você tenha uma boa ideia do(s) risco(s) representado(s) pelas vulnerabilidades identificadas no SBOM, é melhor se aprofundar um pouco mais nas questões específicas. Por exemplo:

• Você tem uma política que especifica seu apetite e tolerância ao risco?
• Quem tem autoridade para aceitar riscos incrementais acima desse nível?
• Quem é responsável por resolver os problemas identificados?
• O que dizem os seus contratos com os clientes?
• Como você aplicará esses requisitos?

BN: O que é VEX, como ele se diferencia dos SBOMs e por que ele é útil para as organizações?

VB: VEX, ou Vulnerability Exploitability Exchange, é um sistema para produtores de software compartilharem suas avaliações das vulnerabilidades em seus componentes de software. VEX é o mecanismo pelo qual produtores de software classificam e rotulam as vulnerabilidades em seus softwares.

O material colateral VEX é usado para fornecer uma maneira consistente e padronizada de descrever vulnerabilidades. Eles incluem detalhes padrão sobre a vulnerabilidade, como sua gravidade. Eles também incluem uma análise sobre se a vulnerabilidade pode ser explorável, como ela pode ser mitigada ou corrigida e soluções alternativas conhecidas.

Enquanto os SBOMs apenas informam se as vulnerabilidades afetam componentes de software, um VEX permite que as equipes comuniquem não apenas as vulnerabilidades que afetam componentes específicos, mas também expliquem se essas vulnerabilidades afetam o aplicativo.

Crédito da imagem: Momius/depositphotos.com