Por que SBOMs compartilháveis ​​são essenciais para segurança de software

As listas de materiais de software (SBOMs) são vistas há muito tempo como a base técnica para dar visibilidade às cadeias de fornecimento de software empresarial. Até agora, o trabalho tem se concentrado na construção de mecanismos para coletar e atualizar os ingredientes de software dentro dos SBOMs e organizar tudo de forma repetível e padronizada.

É um bom começo, mas antes que as empresas e a comunidade de software possam realmente começar a operacionalizar os SBOMs, é necessário desenvolver a capacidade de compartilhamento dos componentes nos SBOMs. E muitas partes interessadas, incluindo engenheiros de software, profissionais de segurança de aplicações (AppSec) e indivíduos que trabalham no lado jurídico e de conformidade, terão que trabalhar juntos para estabelecer as estruturas técnicas e políticas para tornar os SBOMs mais facilmente compartilháveis.

John Bambenek, presidente da empresa de segurança Bambenek Consulting, disse que se os dados SBOM não forem facilmente acessíveis através das linhas organizacionais, produzir SBOMs será apenas um “trabalho sem sentido”.

” Em última análise, os SBOMs são uma forma de uma organização saber se os aplicativos que estão usando têm vulnerabilidades em um de seus componentes. Não é uma ferramenta para desenvolvedores de software; é uma ferramenta para seus clientes.”—John Bambenek

Para fazer isso direito, as equipes de desenvolvimento precisam planejar com antecedência e criar SBOMs compartilháveis ​​que sejam padronizados em um formato que seja facilmente consumível, ao mesmo tempo que estabelecem sistemas escalonáveis ​​para atestação, gerenciamento de acesso e verificação de dados, entre outros fatores. Ao longo do caminho, eles precisarão lidar com as preocupações de gerenciamento de riscos que acompanham o território do compartilhamento de dados confidenciais.

Dois eventos recentes devem facilitar o caminho para o compartilhamento do SBOM. Primeiro, a Fundação OWASP lançou o Cyclone DX 1.6, que introduziu uma abordagem legível por máquina para gerenciar SBOMs com Atestados CycloneDX (CDXAs). Em segundo lugar, um grupo de trabalho da Agência de Segurança Cibernética e de Infraestrutura dos EUA (CISA), focado no compartilhamento e intercâmbio de SBOM, produziu dois documentos, um SBOM Sharing Primer e um relatório SBOM Sharing Roles and Considerations .

Aqui estão as principais preocupações — e por que o compartilhamento de dados é essencial para tornar os SBOMs acionáveis ​​para melhorar a segurança do software da sua organização.

Os prós e contras dos SBOMs compartilháveis

Os detratores compartilháveis ​​do SBOM apontam para o risco à propriedade intelectual. Eles argumentam que, ao entregar tantas informações sobre sua base de código por meio de um SBOM, a empresa está cedendo seu IP de software.

John Gallagher, vice-presidente do Viakoo Labs, uma equipe de pesquisa e geração de conteúdo da Viakoo , reconheceu que existem alguns riscos com os SBOMs, principalmente o fato de eles fornecerem muito mais detalhes sobre o seu produto do que você tradicionalmente divulgaria – e podem até mesmo fornecer aos agentes de ameaças informações críticas sobre vulnerabilidades que podem ser exploradas apenas no contexto de outros componentes de software.

“Exemplos disso incluem fornecer aos concorrentes insights sobre compensações tecnológicas, código proprietário ou processos de desenvolvimento, ou dar vantagens aos atores de ameaças no desenvolvimento de vulnerabilidades para sistemas específicos, como infraestrutura crítica”.-John Gallagher

No entanto, estas preocupações devem ser pensadas em termos de gestão de risco, disse Gallagher. Ele e muitos outros argumentam que a capacidade dos SBOM partilhados para mitigar os riscos, na maioria dos casos, supera os riscos que podem expor. Isto é especialmente verdadeiro considerando que os SBOMs são provavelmente um caminho impraticável para um espião corporativo seguir para atingir os seus objetivos.

Chris Blask, vice-presidente de estratégia da Cybeats, disse que as empresas geralmente têm muitas maneiras de proteger a propriedade intelectual , incluindo contratos e advogados. E os parceiros representam menos riscos do que os detratores pensam, acrescentou.

“[Se] eu tivesse a propriedade intelectual ou o código de todos os meus concorrentes em um determinado momento, provavelmente nem olharia para eles. Já tenho problemas suficientes sozinho. Portanto, acho que o risco é exagerado.”- Chris Blask

Com vulnerabilidades que são notoriamente difíceis de encontrar e remediar – como as dos sistemas IoT – o uso de SBOMs pode melhorar drasticamente as defesas, disse Blask. “Essa vantagem temporal supera em muito as vantagens teóricas para os concorrentes ou para os atores da ameaça.”

Enquanto isso, a maioria dos bandidos já possui vários mecanismos testados e comprovados para produzir rapidamente explorações de dia zero ou de dia N, disse Bambenek. Sendo esse o caso, a necessidade da comunidade de desenvolvimento de software de SBOMs compartilháveis ​​supera o risco de compartilhamento.

” Os adversários estão sempre um passo à frente em saber o que é vulnerável, pois produzem explorações de dia zero o tempo todo. Os desenvolvedores de software precisam ser agressivos na verificação de vulnerabilidades em seus componentes e bibliotecas, bem como no monitoramento de repositórios externos em busca de atualizações. “—John Bambenek

Padronização SBOM e logística de acesso

À medida que a indústria de software começa a ultrapassar essas objecções comuns à partilha de SBOMs, terá de pensar de forma mais dinâmica sobre a logística em torno da partilha. Disse Blask: “A conversa tem sido tradicionalmente: ‘Eu faço software, portanto faço SBOMS. Você compra meu software, portanto posso ou não lhe dar meu SBOM.’ Estamos começando a ver que é mais complicado do que apenas aquele relacionamento de compartilhamento um a um”, disse ele.

Blask é um dos poucos especialistas que trabalharam com a CISA no compartilhamento e intercâmbio de SBOM e que ajudaram a desenvolver a cartilha e as diretrizes da agência sobre SBOMs compartilháveis. Uma conclusão importante desse trabalho para Blask é que, no ecossistema de compartilhamento SBOM, o autor do SBOM pode não ser necessariamente o produtor do software. Entretanto, o consumidor SBOM nem sempre pode ser o cliente final desse software. Esse consumidor poderia ser, por exemplo, um advogado do departamento de compras, um auditor ou um subscritor de seguros.

A CISA também definiu um terceiro participante na troca, o distribuidor SBOM – que, novamente, é uma função não necessariamente alinhada com a do distribuidor de software. Os distribuidores SBOM podem ser intermediários ou organizações que ajudam a facilitar o intercâmbio entre uma ampla gama de diferentes autores e consumidores SBOM.

À medida que as organizações compartilham informações SBOM, elas terão que descobrir não apenas as funções, mas também maneiras de gerenciar o compartilhamento de conteúdo SBOM de forma dinâmica – e de acordo com a política.

A indústria precisa ir além dos SBOMs de caixa de seleção, disse Blask. Os consumidores de software precisam conhecer o software que estava sendo executado na máquina-ferramenta usada pelo subcontratado, por exemplo, porque precisam saber se algum desse software continha um elo fraco. “É para onde estamos indo com toda essa questão de transparência na cadeia de suprimentos”, disse ele.

Diferentes regulamentações e diferentes contratos com fornecedores exigirão novos requisitos sobre a profundidade do conteúdo SBOM. Além do mais, assim como o código empresarial que está evitando um modelo monolítico, o mesmo acontecerá com o conteúdo SBOM. Raramente haverá um SBOM único compartilhado para um grande aplicativo. Em vez disso, diferentes conteúdos serão compartilhados com base em solicitações diretas ou em demandas de conformidade. Isso exigirá muita reflexão e recursos dos produtores de SBOM para serem gerenciados ao longo do tempo, e poderia ser uma área de inovação dos participantes da indústria para ajudar a formular ferramentas e estruturas para fazer isso mais facilmente, disse Gallagher da Viakoo.

“Garantir que os SBOMs compartilhados atendam a todos os padrões regulatórios pode ser complexo e consumir muitos recursos. SBOMs grandes e complexos podem ser difíceis de gerenciar, compartilhar e entender, especialmente para sistemas com inúmeras dependências e componentes transitivos.” —John Gallagher

Além de gerenciar qual conteúdo vai em qual SBOM compartilhado, há também o antigo problema de padronização na forma como os SBOMs são formatados – e na terminologia que eles usam para diferentes componentes.

Kevin Scribner, gerente de produto do Synopsys Software Integrity Group, disse que o maior desafio que ouviu falar dos clientes é a identificação de componentes.

“Não existe um método padronizado para identificar pacotes/componentes de software, portanto a indústria tem usado identificadores incompletos ou uma combinação de identificadores específicos de ferramentas, PURL e CPE. Envolver-se em grupos de trabalho para ajudar a resolver o problema, bem como ter ferramentas que usam um processo de identificação em camadas ou combinado pode ajudar.”-Kevin Scribner

O futuro do compartilhamento SBOM

Em última análise, o futuro do compartilhamento de SBOM exigirá não apenas conteúdo SBOM bem gerenciado e padronizado, mas também mais coordenação e sistemas intermediários para ajudar a descobrir os direitos de acesso e a validação de dados. “Precisamos automatizar a política”, disse Blask. “Temos de construir sistemas políticos automatizados porque o que há de mais radical na transparência radical é que nem tudo deve ser transparente.”

A política define as circunstâncias em que certas coisas são compartilhadas com determinados consumidores SBOM. Essa política pode ser definida pelos reguladores, mas na maioria das vezes será definida pelos gabinetes de compras e pelas relações contratuais – tanto aquelas entre clientes e fornecedores como as outras relações comerciais sobre as quais os ecossistemas digitais modernos são construídos. Já está começando a acontecer. É muito provável que os subscritores de seguros comecem a exigir o uso de SBOMs como condição para oferecer seguro cibernético, disse Blask.

Ele prevê vários mercados e repositórios de compartilhamento SBOM que podem coordenar o compartilhamento com um mecanismo de gerenciamento de acesso baseado em políticas integrado que torna o relacionamento de compartilhamento rastreável, verificável e protegido. “É aqui que a temida palavra B, blockchain, pode ser usada. Se isso for importante o suficiente para você, um livro-razão distribuído é um mecanismo para talvez ter realmente certeza de que não foi compartilhado com outra pessoa”, disse Blask.

Independentemente da evolução desses mecanismos de compartilhamento, esperamos que isso ajude a aliviar a apreensão sobre o compartilhamento de informações suficientes para ajudar as partes interessadas da cadeia de fornecimento de software a reduzir significativamente os riscos, disse Scribner.

“No início, as organizações estavam muito apreensivas em relação ao compartilhamento de SBOMs e incluíam apenas os requisitos mínimos. À medida que as ferramentas para ajudar a controlar o conteúdo do SBOM e dos processos relacionados amadurecem, as organizações provavelmente se sentirão mais confortáveis ​​em compartilhar esses dados com seus clientes.”—Kevin Scribner