Selecionando a lista de materiais de software certa para sua empresa

Se você está perguntando: “O que é um SBOM?” você precisará alcançá-lo rapidamente. Uma lista de materiais de software é a primeira linha de defesa contra vulnerabilidades de software que podem estar à espreita, como portas traseiras desbloqueadas em sua rede, prontas para permitir a entrada de hackers.

Um SBOM, como qualquer lista de materiais, lista os componentes do produto acabado, portanto, em caso de problemas, os desenvolvedores podem se concentrar na causa e resolvê-la com o mínimo de interrupção possível. Os SBOMs são a pedra angular da segurança da cadeia de suprimentos, permitindo DevOps mais seguro e melhor inteligência de ameaças para manter redes mais resilientes.

Dois anos depois que uma gangue de ransomware prejudicou as entregas de combustível dos EUA ao atacar um operador de oleoduto, os ataques à cadeia de suprimentos continuam sendo a principal irritação dos profissionais de segurança. Após o ataque e a descoberta da vulnerabilidade do Log4J, os SBOMs se tornaram populares enquanto os profissionais de segurança lutam para evitar ataques futuros.

Ascendência de SBOMs e orientação federal

SBOMs estão tendo um momento. Durante a recente conferência RSA, a Agência de Segurança Cibernética e Infraestrutura (CISA) do governo federal divulgou orientações sobre os diferentes tipos de SBOMs disponíveis e seu uso.

A CISA tem sido uma promotora do uso de SBOMs, principalmente desde Ordem Executiva 14028 e o Gabinete de Gestão e Orçamento memorando M-22-18 que exigia o desenvolvimento de um formulário de relatório para desenvolvedores de software que atendem ao governo federal. CISA detém SBOM-a-Rama reuniões que reúnem tipos da indústria para apoiar o desenvolvimento do CBOM.

O documento CISA resultou de um esforço de grupo iniciado em 2018 e, como muitos esforços de grupo, pode se tornar pesado. A introdução do documento reconhece isso, afirmando: “Dadas as formas diferentes de coleta de dados do SBOM, os resultados das ferramentas podem variar e fornecer valor em diferentes casos de uso”. Com isso em mente, vale a pena detalhar os tipos de SBOMs disponíveis e alguns possíveis casos de uso para ajudar a esclarecer quais podem ser mais úteis para uma organização.

Decodificando os 6 tipos principais de SBOMs

Existem seis tipos principais de SBOMs em uso hoje, à medida que avançam nos estágios do ciclo de vida do desenvolvimento de software:

• • Projeto: Um SBOM desse tipo é criado para software prospectivo ou planejado e inclui componentes que podem ou não existir. Geralmente é desenvolvido com base em uma RFP, conceito ou especificações. Embora teoricamente possível, é difícil imaginar como isso poderia ajudar e como poderia gerar um documento legível por máquina que atendesse aos requisitos padrões o governo federal está apoiando.

  Um caso de uso possível para esse tipo de SBOM é alertar os desenvolvedores sobre problemas de licenciamento que possam surgir ao considerar o uso de determinados componentes que afetariam a propriedade intelectual ou a distribuição do produto acabado. Este SBOM pode ajudar a equipe de desenvolvimento a identificar elementos incompatíveis antes de serem adquiridos e definir uma lista de componentes aprovados e recomendados. Esse tipo de SBOM também pode permitir que a equipe obtenha os melhores componentes de código aberto de uma perspectiva de negócios.

• • Fonte: Muito semelhante ao SBOM do tipo build, este é gerado no ambiente de desenvolvimento e inclui todos os arquivos de origem e dependências necessários para construir um artefato, mas exclui a ferramenta de build do processo. Geralmente é produzido pela ferramenta de análise de composição de software (SCA), com alguns esclarecimentos adicionados manualmente.

  É difícil ver o caso de uso para esse tipo em vez do SBOM de tipo de compilação mais comum. Ainda assim, esse SBOM pode identificar componentes vulneráveis ​​que nunca são executados após a implantação, dando à equipe uma visão da árvore de dependências dos componentes incluídos. Portanto, permite a correção de vulnerabilidades conhecidas na fonte no início do processo de desenvolvimento.

  Por outro lado, pode faltar alguns detalhes de outros tipos de SBOMs, incluindo tempo de execução, plug-in ou componentes dinâmicos, como bibliotecas de servidor de aplicativos.

• • Construir: O tipo de SBOM mais utilizado, trata-se de um inventário mais completo gerado como parte do processo de construção do software que executará o artefato final. Essa abordagem usa dados como arquivos de origem, dependências, componentes construídos, dados efêmeros do processo de construção e design anterior e SBOMs de origem. Ele se baseia na resolução de todas as dependências no sistema de compilação e na verificação delas na máquina de compilação.

  Como os arquivos reais são verificados, esse tipo de SBOM cria um registro mais completo com dados avançados sobre cada arquivo, como hash e origem. Fornecer mais visibilidade além do que está disponível no código-fonte cria confiança de que o SBOM representa com precisão o processo de desenvolvimento. Essa confiança decorre da integração do SBOM e do produto acabado no mesmo fluxo de trabalho.

  Por outro lado, esse SBOM é muito dependente do ambiente de construção, que às vezes pode precisar ser alterado para produzir o SBOM.

• • Analisado: Às vezes, isso é chamado de “SBOM de terceiros” ou SCA binário. Ele se baseia na varredura do artefato conforme entregue para descobrir seus componentes; e usa ferramentas de terceiros para analisar artefatos como pacotes, contêineres e imagens de máquinas virtuais. Ele não precisa de acesso ao ambiente de construção e pode verificar novamente os dados do SBOM de outras fontes para encontrar dependências ocultas que as ferramentas de criação do SBOM perderam.

  Como basicamente faz engenharia reversa dos componentes do artefato, pode ser uma ferramenta útil para consumidores de software que não têm um SBOM disponível ou podem corroborar um SBOM existente.

  No lado negativo, esse tipo de SBOM geralmente depende de heurísticas ou fatores de risco mais flexíveis com base no contexto para testar os componentes. Portanto, o teste pode produzir alguns resultados falso-positivos. Mas também é mais provável encontrar bibliotecas vinculadas a partir do ambiente sem que a equipe de desenvolvimento perceba, como OpenSSL libc ou outras que criam SBOMs que geralmente não são encontradas.

• • Implantado: Como o próprio nome sugere, trata-se de um inventário do software implantado no sistema, geralmente gerado pela compilação dos SBOMs e informações de configuração dos artefatos instalados. Ele pode combinar a análise das opções de configuração e o exame do comportamento de execução em um ambiente implantado. É útil examinar os componentes de software, incluindo as outras configurações e componentes do sistema que executam um aplicativo.

  A geração desse tipo de SBOM pode exigir a alteração dos processos de instalação e implantação e nem sempre reflete o ambiente de tempo de execução do artefato, pois alguns componentes podem não estar acessíveis. Mas o amplo escopo desse tipo de SBOM o torna uma opção atraente.

• • Tempo de execução: Às vezes chamado de SBOM “Instrumentado” ou “Dinâmico”, esse tipo resolve o ponto cego em SBOMs implantados. Nesse caso, as ferramentas interagem com o sistema e registram os artefatos utilizados em um ambiente em execução e aqueles carregados na memória durante a execução. Esse processo ajuda a evitar falsos positivos de componentes não utilizados.

  Esse tipo de SBOM oferece aos desenvolvedores visibilidade de componentes carregados dinamicamente e conexões externas e pode fornecer detalhes sobre quais componentes estão ativos e quais partes estão em uso. Isso aumenta a sobrecarga da rede porque o sistema precisa ser analisado durante a execução. Como ele precisa estar em execução por algum tempo para usar sua funcionalidade completa, pode levar algum tempo para coletar informações detalhadas.

Considerações finais sobre a seleção de SBOMs

Considerando esses detalhes, selecionar o tipo certo ou combinação de SBOMs para atender às necessidades de sua organização envolve mais consideração do que simplesmente optar pela primeira ferramenta de geração de SBOM disponível para fins de conformidade.

Com o apoio do governo federal, a SBOM sem dúvida veio para ficar e pode estabelecer uma base sólida, introduzindo ordem no processo ocasionalmente caótico de proteger produtos de software.