Nos últimos anos, a lista de materiais de software (SBOM) tornou-se um elemento-chave da segurança de software e do gerenciamento de riscos da cadeia de suprimentos de software.
Conversamos com Tim Mackey, chefe de estratégia de riscos da cadeia de suprimentos de software em Synopsys para saber mais sobre os benefícios e desafios dos SBOMs.
BN: Qual foi a principal percepção que surgiu como resultado da vulnerabilidade do Log4shell?
TM: A experiência Log4Shell destacou que o uso de código aberto era generalizado nas organizações. Mesmo software comercial foi encontrado para ter componentes de código aberto como dependências. Isso trouxe um foco mais nítido de que os projetos de código aberto são criados e mantidos por voluntários externos, e não por seus próprios funcionários ou fornecedores comerciais terceirizados. Isso significava que a TI não tinha nenhum controle sobre o uso de software de código aberto dentro do software comercial–mesmo que tivessem processos maduros de governança de código aberto para software de código aberto baixado e usado diretamente ou usado em seus esforços de desenvolvimento de software personalizado.
BN: O que as organizações precisam entender sobre o código aberto para estarem melhor preparadas para enfrentar os desafios únicos que ele traz?
TM: O primeiro passo é muitas vezes, apenas reconhecendo que você está usando código aberto e, a partir daí, pode definir um fluxo de trabalho de governança viável. Como as equipes de código aberto não sabem quem baixou seu código, você não tem um mecanismo push para atualizações; você tem um mecanismo de puxar. Portanto, quando um projeto é efetivamente abandonado ou no final de sua vida útil, adoraríamos que os mantenedores dissessem:”Ei, terminei este projeto”e colocassem um pequeno aviso nele dizendo não haverá novas atualizações, mas isso normalmente não acontece.
Agora, ser capaz de identificar projetos’abandonados’versus’concluídos’é um problema à parte. Você não pode fazer essa determinação se não estiver envolvido com o projeto; portanto, se não sabia que está usando um projeto, comece a fazer essas perguntas. E essa é realmente a primeira grande peça do quebra-cabeça–aceite que você tem código aberto, aceite que ele é gerenciado de forma diferente e coloque em prática um processo que inclua estar envolvido com esses projetos.
Onde as coisas se tornam particularmente desafiadoras é quando você diz, três ou quatro níveis de profundidade na dependência ou na cadeia de fornecedores que você pode não necessariamente saber que tem código-fonte aberto em execução. Essa é uma das lições de toda a experiência do Log4j, as pessoas não sabiam que existia essa coisa chamada Log4j antes do problema acontecer.
BN: O que exatamente é um SBOM?
TM: Um SBOM é fundamentalmente um arquivo que lista as bibliotecas usadas por um aplicativo. É um componente-chave de um plano de governança que abrange não apenas o uso de código aberto em uma cadeia de suprimentos de software, mas também se torna um ponto de ancoragem para outros elementos operacionais. O elemento operacional mais comum discutido hoje é o uso de SBOM para comunicar a exposição de vulnerabilidade dentro de componentes na cadeia de suprimentos de software para determinado aplicativo.
BN: Um SBOM é suficiente para mitigar riscos de segurança e licenciamento de código aberto?
TM: Não. Como um SBOM foi apresentado em uma ordem executiva, muita atenção foi dada a:’Preciso ir e ter um SBOM.’Para fins práticos, muitas organizações hoje estão criando SBOMs e é simplesmente uma lista de materiais dizendo:”Eu tenho esses componentes que vêm deste local e esta é a versão deles.”
É realmente uma coisa estática. Ele representa a aparência daquele software quando foi enviado. É fantástico a esse respeito, mas não vai dizer se é mais seguro ou menos seguro do que qualquer outra coisa. Está estritamente dizendo a você como é a lista de ingredientes para aquele software específico, e é aí que as pessoas ficam um pouco enganadas. O SBOM de que todos falam não é esse unicórnio mágico–é parte de um fluxo de trabalho que precisa ser implementado dentro das empresas.
O’SB’em SBOM não significa Bala de Prata.
O’SB’em SBOM não significa Bala de Prata.
p>
O problema é que os dados SBOM precisam entrar em um fluxo de trabalho. As pessoas que recebem o SBOM podem estar dizendo:”Aqui, recebi este arquivo com o qual não sei o que fazer”, e isso está falando de um fluxo de trabalho-um conjunto de processos que as organizações precisam descobrir.
Em outras palavras, o conhecimento fornecido pelos SBOMs é obviamente valioso, mas se sua organização não tiver um processo para consumi-lo, então há um benefício mínimo em ter um SBOM e as informações de vulnerabilidade associadas. É essa falta de processo que é o maior desafio, pois enquanto as equipes de compras podem solicitar SBOMs de todos os seus fornecedores, se não houver um processo bem definido para agir sobre as informações do SBOM, tudo o que acontece é que você agora tem mais um arquivo em um diretório.
BN: Como deve ser um processo bem definido e bem-sucedido para obter valor de SBOMs?
TM: Todas as organizações têm um departamento de TI responsável por manter os patches no software que está dentro dessa organização. Todo software é construído a partir de componentes. Sabemos pelo relatório Synopsys OSSRA que o uso de código aberto em software comercial é em média de 78 por cento. Portanto, você sabe que haverá componentes de código aberto e que precisarão ser atualizados. O SBOM comunica essa informação se estiver anexado ao ativo que a TI está gerenciando.
Agora, quando chega a hora de uma nova divulgação de vulnerabilidade, a TI está em posição de consultar o sistema de gerenciamento da SBOM e diga:”A-ha-eu tenho isso, mas de onde vem meu patch?”O patch vem das informações de proveniência do SBOM-esse é o papel de um SBOM. Não é para dizer que você tem uma nova vulnerabilidade–é um documento que descreve exatamente o que há naquele artefato que você está tentando executar, e agora você pode fazer as coisas certas se tiver esse fluxo de trabalho.
BN: Quais requisitos um SBOM deve atender?
TM: Para ser útil, um SBOM deve ser preciso e completo, e esses são dois problemas diferentes, mas resolvendo um, depende da resolução do outro.
Para começar, todas as bibliotecas externas empacotadas em um aplicativo devem ser registradas para que um SBOM seja concluído, incluindo software de código aberto, bibliotecas comerciais de terceiros e qualquer software introduzido por meio um contrato de terceiros. Idealmente, o SBOM seria extraído do código-fonte de um aplicativo, embora isso possa ser um processo difícil, dependendo de como o processo de construção do aplicativo é definido. Por exemplo, você pode precisar de dois SBOMs diferentes ao compilar um aplicativo para duas plataformas diferentes; um para Windows e outro para Linux.
Igualmente, é importante que os componentes sejam identificados com precisão, reconhecendo desde seu ponto de origem até a versão dele. Um SBOM primário, que extrai do código-fonte do aplicativo, é mais preciso, mas também existem SBOMs de terceiros. Nesse caso, o aplicativo e não o código-fonte é verificado. Isso pode resultar em algumas informações ausentes, pois você não tem a capacidade de determinar a versão precisa da biblioteca; portanto, tornando este método adequado apenas se os SBOMs primários não estiverem disponíveis ou como um meio de verificar novamente o SBOM primário.
BN: O que você vê para o futuro dos SBOMs em abordando vulnerabilidades de código aberto e riscos gerais da cadeia de suprimentos de software?
TM: Estamos muito no início da era SBOM. A maioria dos fornecedores ainda está trabalhando para criar SBOMs e isso continuará no futuro previsível. No entanto, embora um fornecedor capaz de fornecer um SBOM seja um indicador de perspicácia de segurança de código aberto, não é o único indicador. É importante ressaltar que, se uma organização solicita um SBOM de um fornecedor, mas não possui um fluxo de trabalho para processar esse SBOM e extrair valor dele, ter um fornecedor fornecendo SBOMs adiciona custo sem benefício.
Curiosamente, muitos falharam observar que os casos de uso de segurança para SBOMs geralmente se alinham com o que as soluções de Software Composition Analysis (SCA) já fornecem. Os SBOMs são mais úteis como parte de uma estratégia geral de mitigação de riscos. Isso implica que existem processos para medir o risco transmitido por meio de um SBOM e, em seguida, algum processo para mitigar esse risco.
Crédito da imagem: Momius/depositphotos.com