Neste artigo, vamos abordar um exemplo que pode explicar o que vem a ser o Software Bill of Materials (SBOM) e como ele é consultado por diversas ferramentas de SCA.
Você também pode ouvir a versão em áudio desse blogpost:
A pressão é grande, e cada vez mais o time de desenvolvedores das empresas precisa entregar aplicações e soluções de forma mais rápida. Para o mercado isso é um ponto positivo, sempre coisas novas, novidades da semana e ou mesmo ajustes em processos e ou features desejadas pelos clientes. Mas e a segurança, como fica?
Não é fácil para os times manter um processo seguro dentro da agilidade que os dias de hoje pedem, e cada vez mais vamos precisar ter mais controles sobre todas as etapas e tudo que usamos nas soluções desenvolvidas.
O fato de tentarmos usar ferramentas para isso, não exclui da equação o fator humano, o desenvolvedor, muito pelo contrário o uso destas ferramentas pode deixar ao desenvolvedor mais tempo para que assim possa focar mais nas melhores práticas de segurança de código.
Um destes caminhos é a existência dentro do seu processo de desenvolvimento de ferramentas como SCA – Software Composition Analysis – que podem de forma geral, e por meio de um processo automatizado buscar componentes de software de código aberto, identificando conformidade com licenças, qualidade de software e ainda auxiliando na identificação de possíveis componentes que precisam ser atualizados.
Mas, por baixo dessas ferramentas há um padrão que não é muito comentado mas, que quando utilizado e entendido auxilia no processo de segurança de uma aplicação.
Antes de abordarmos diretamente o padrão Software Bill Of Materials (SBOM), vamos entender um pouco do conceito. O objetivo é manter um registro de todos os componentes de um software, e olha que não é nada fácil. Afinal, segundo o relatório Open Source Edition, 71% dos softwares analisados possuem vulnerabilidade em algum componente, e destes, 47% possuem vulnerabilidades transitivas, ou seja, vulnerabilidade de um componente do componente.
Imagina a seguinte situação
Estamos produzindo bolachas, e nossos concorrentes lançaram um novo sabor que vem fazendo bastante sucesso. Desta forma, nossa margem está caindo, e precisamos de um produto novo, então começamos a trabalhar nisso.
Bem, nosso produto precisa de partes, partes individuais e partes compostas. Neste caso, digamos que o nosso novo produto vá se assemelhar a uma barra de cereais – e que o nosso foco são pessoas que desejam uma alimentação mais saudável. Então temos alguns ingredientes como caramelo, mel, castanha do Pará, sal e um conjunto de outras castanhas que compramos de um fornecedor.
Desta forma, neste cenário temos como componentes únicos sal, castanha do Pará e mel. Logo os demais ingredientes são compostos.
Imagine, então, que o ingrediente que compramos de nosso fornecedor tem em sua composição o amendoim. E nós precisamos saber disso, pois temos que colocar em nossa embalagem essa informação, para que nossos clientes possam saber disso caso sejam alérgicos.
Isso só é possível se também mapearmos os componentes de toda a nossa cadeia, inclusive as dos produtos que são fornecidos por outras empresas. E a isso se chama dependência transitiva.
Desta forma, podemos agora identificar que um de nossos componentes pode ser perigoso para algumas pessoas e podemos colocar isso em nossa embalagem.
Muito bem, tendo entendido esse conceito, substitua a bolacha pelo seu software, e os ingredientes por bibliotecas e assim teremos uma visão do que é um SBOM e qual a importância que ele tem dentro de um processo de software.
Com este mapeamento é possível identificar quais componentes precisam de atenção e onde estes componentes estão sendo usados.
Basicamente essa visão vai nos responder a duas perguntas básicas : Estou sob alguma ameaça? E onde está essa ameaça?
Entenderam agora onde isso vai nos levar? A visão trazida pelo SBOM é uma visão de ameaças, de possíveis problemas que estão dobrando a esquina e se sabemos que está vindo, podemos evitar.
A utilização e o olhar sobre o Software Bill Of Materials (SBOM) ficou ainda mais evidente quando a administração do Presidente americano Biden publicou uma Ordem Executiva para melhoria do processo de cibersegurança. Nesta ordem está clara a necessidade de adotar em todas as soluções vendidas ao Governo Americano o padrão SBOM.
Mas o que é este padrão Software Bill Of Materials (SBOM)?
De uma forma bem macro, e acredito que nosso exemplo já ajudou nesse entendimento, SBOM é um inventário encadeado que lista e registra componentes de um software, mostrando de forma efetiva toda uma cadeia de suprimentos.
Como qualquer lista, esta precisa definir alguns dados que são importantes para o seu entendimento e melhor uso. Existem alguns modelos de Software Bill Of Materials (SBOM), a própria Ordem Executiva do Governo Americano trouxe uma lista mínima de dados que devem compor o SBOM mas, isso pode ser identificado para ou por cada uma das ferramentas que usam esse padrão como base.
Mas, basicamente temos alguns pontos que podem ser entendidos como comuns. Abaixo vou colocar alguns deles, e entendo que a descrição de cada um é bem clara.
- Nome do autor;
- Nome do Fornecedor;
- Hash criptográfico do componente;
- Identificador Único e;
- Relacionamentos deste componente.
Há outros ? Sim, há outros dados que fazem parte de um SBOM mas, como falei, aqui temos que ter algum ponto de início. Mas há outros, por exemplos padrões como o SPDX e o SWID ambos com suas estruturas de notações e informações necessárias para seu uso, mas como a própria documentação destes modelos nos coloca, não há uma necessidade de se usar todos os campos identificados pelo modelo, o ponto é entregar informações suficientes para que o objetivo seja alcançado.
O padrão SPDX, por exemplo, em suas especificações nos entrega um padrão de estrutura que foca em como melhor comunicar componentes, licenças, copyrights e informações de segurança.
Já o padrão SWID, é focado em entregar transparências de forma às organizações conseguirem rastrear componentes de software e onde eles estão sendo usados. É um padrão que se baseia na ISO/IEC 19770-2/2015 e basicamente entrega para o gerenciador um ciclo de vida do componentes, por adicionar uma tag ao componente no momento da instalação e retira essa tag quando acontece o processo de desinstalar esse componente.
Bom, mas isso sozinho já daria alguns artigos.
Acredito que consegui explicar o que é um Software Bill Of Materials (SBOM) e qual a importância dele, certo?
Bom, mas como isso influencia no processo de desenvolvimento de vocês? Que tal comentar?
