A construção de produtos ou aplicativos de software seguros nesta era requer um conhecimento completo dos componentes exatos do aplicativo que você está construindo. As dependências, licenças, arquivos e outros ativos que compõem seu pacote de software são pontos potenciais de vulnerabilidade por meio dos quais atores mal-intencionados podem lançar um ataque ao seu software e outros aplicativos na cadeia de suprimentos.
Como parte dos esforços para combater o recente aumento na frequência e no impacto das ataques às cadeias de fornecimento de software, o Governo Federal, em coordenação com a NTIA, emitiu uma ordem executiva que detalhou diversas medidas para melhorar a segurança cibernética e garantir a integridade de componentes de terceiros usados em pacotes de software. Uma dessas medidas é a Lista de materiais de software.
Este é um documento formal que contém todos os componentes de um pacote de software e as relações da cadeia de suprimentos entre esses componentes. Preparar uma lista de materiais de software abrangente não é apenas uma prática padrão, mas também exigida por lei. Esta postagem define o escopo da Lista de Materiais de Software e o elementos mínimos que deve ser incluído em uma lista abrangente de materiais.
O que os componentes mínimos de um SBOM da NTIA fornecem?
O SBOM serve como um guia formal para empresas que constroem, compram ou operam software, fornecendo todas as informações necessárias para melhorar a sua compreensão da cadeia de fornecimento de software. Também ajuda a rastrear facilmente vulnerabilidades emergentes, caso elas ocorram, e reduzir os riscos da cadeia de fornecimento de software. Porém, para que o SBOM atenda às exigências estipuladas pelo Governo Federal, existem alguns elementos básicos que ele deve conter. Esses elementos são frequentemente classificados em três categorias:
- Campos de dados: Espera-se que um SBOM forneça dados importantes sobre componentes de software, como o nome do componente, o nome do fornecedor, a versão do software e outros identificadores exclusivos. Deve também detalhar as relações entre dependências. Esses dados possibilitam identificar com precisão todos os componentes de software e rastreá-los em toda a cadeia de fornecimento de software.
- Suporte de automação: A Lista de Materiais do Software deve ser legível por máquina e também capaz de geração automática. Isso permite o rastreamento contínuo dos dados incluídos no SBOM. Normalmente, esses documentos estão em formatos padrão, como tags SPDX, CycloneDX e SWID, o que também os torna legíveis por humanos.
- Práticas e processos: Espera-se também que a documentação do SBOM detalhe as práticas e processos padrão para preparar e atualizar o SBOM. Deve também incluir práticas para distribuição e acesso ao SBOM, bem como medidas para lidar com erros incidentais.
Os elementos mínimos exigidos da documentação SBOM da NTIA fornecem um critério claro do que é esperado em uma diretriz SBOM para os casos de uso básicos de sua lista de materiais de software, como gerenciamento de vulnerabilidades, inventário de componentes de software e gerenciamento de licenças de software. A estrutura está sendo atualizada e pode incluir elementos adicionais que ampliem sua usabilidade no futuro próximo. Nas seções subsequentes desta página, explicaremos esses componentes principais da sua lista de materiais de software com mais detalhes. Os elementos mínimos exigidos de uma lista de materiais de software incluem sete campos de dados conforme especificado abaixo.
Campos de dados: requisitos mínimos
O objetivo da Lista de Materiais de Software é fornecer informações que ajudem os usuários e outras partes interessadas a identificar facilmente os componentes de software. Como esperado, um dos primeiros e mais importantes elementos do SBOM são os dados que devem ser incluídos para cada componente detalhado no documento. Além de ajudar na identificação de componentes individuais, os dados também facilitam o rastreamento dos componentes nos vários locais em que são usados na cadeia de fornecimento de software.
- Nome do Fornecedor: O fornecedor é o originador ou fabricante do componente de software em questão. Este é o nome do indivíduo ou organização que cria, define e identifica os componentes de software.
- Nome do Componente: Refere-se ao nome designado atribuído ao software conforme definido pelo fornecedor ou fabricante original. Nos casos em que existam vários nomes e apelidos para o software, eles também poderão ser anotados.
- Versão do componente: O SBOM deve incluir o número de lançamento ou número de categoria conforme especificado pelo fornecedor ou fabricante. Os dados da versão servem como um identificador que especifica qualquer alteração no software a partir de uma versão previamente identificada da versão subsequente do software.
- Outros identificadores exclusivos: Refere-se a identificadores adicionais além do nome e da versão do componente. Esses identificadores adicionais fornecem uma camada adicional de identificação para o componente e também podem ser usados como uma chave de pesquisa para localizar o componente em bancos de dados relevantes.
- Relação de Dependência: Este é um dos componentes de dados mais importantes de uma Lista de Materiais de Software, uma vez que o SBOM se destina a detalhar como os componentes de software se encaixam. O relacionamento de dependência especifica o relacionamento entre o software X usado em seu aplicativo e seus componentes upstream.
- Autor dos dados SBOM: Refere-se ao indivíduo que criou os dados SBOM. Às vezes, o fornecedor do software também pode atuar como autor. Porém, em muitos casos, o autor é outro indivíduo ou grupo.
Suporte de Automação: Requisitos Mínimos
O uso da Lista de Materiais de Software geralmente ultrapassa as fronteiras organizacionais. Isso significa que os dados contidos no SBOM são frequentemente usados por vários departamentos de uma organização e também por várias organizações. Para garantir a facilidade de uso desta documentação, a NTIA recomenda que o SBOM esteja em um formato que seja legível por máquina e por humanos. Preparar e transmitir o SBOM em formatos automatizados padrão como este melhora a interoperabilidade deste documento para os diversos fins pretendidos.
A NTIA reconhece três formatos de entrega para geração e transmissão de SBOMs. Sua lista de materiais de software deve corresponder a qualquer um desses formatos para estar em conformidade com os padrões estabelecidos pelo ordem executiva de segurança cibernética do governo. Esses formatos padrão incluem:
- Troca de dados do pacote de software (SPDX)
- Etiquetas de identificação de software (SWID)
- CicloneDX
Troca de dados do pacote de software (SPDX)
O SPDX é um padrão aberto para entrega de dados SBOM. Ele captura informações importantes sobre o software, incluindo seus componentes, procedência, licenças e direitos autorais. Ele também fornece referências de segurança. O SPDX a versão 2.2 é a versão mais recente e suporta o tipo de arquivo YAML 1.2, JavaScript Object Notation e Resource Description Framework (RDF/XML). tag: arquivo de texto simples de valor e planilhas .xls
Etiquetas de identificação de software (SWID)
As tags SWID são projetadas para ajudar a identificar e contextualizar os componentes de qualquer produto de software. O projeto Etiquetas de identificação de software (Tags SWID) é um conjunto de ferramentas para geração e validação de etiquetas de identificação de um software. Essas ferramentas baseadas em Java suportam tags XML SWID baseadas no formato padronizado conforme definido pela ISO/IEC 19770-2:2015 e Concise Binary Object Representation (CBOR). O O NIST tem um site com uma lista de recursos úteis para:
- Construindo tags SWID e CoSWID
- Validação de tags SWID e CoSWID com base em requisitos de esquema específicos e diretrizes de práticas recomendadas
- Um aplicativo da web que fornece serviço de validação de tag SWID que pode ser implantado em um servidor de aplicativos Java
- Cliente de repositório SWID para postar tags no banco de dados nacional de vulnerabilidades
CicloneDX
CicloneDX afirma ser um “padrão leve de lista de materiais de software (SBOM). É útil para análise de componentes da cadeia de suprimentos e segurança de aplicações. As organizações que adotam o CycloneDX podem atender perfeitamente aos requisitos mínimos do SBOM e amadurecer em casos de uso mais sofisticados da documentação do SBOM ao longo do tempo.
SBOMs CycloneDX são normalmente apresentados nos formatos XML, JSON ou Protocol Buffers. A especificação geralmente inclui estes cinco campos:
- Os metadados da lista de materiais: incluem informações gerais sobre o aplicativo ou produto de software em si.
- Componentes: Este é um inventário abrangente que cobre todos os componentes proprietários e de código aberto do software.
- Informações de serviços: detalha todas as APIs externas que o aplicativo provavelmente chamará durante sua operação. Inclui todos os URLs de endpoint, requisitos de autenticação e travessias de limites de confiança.
- Dependências: A documentação também detalha todos os componentes e serviços do pacote de software. Isso inclui relacionamentos diretos e transitivos.
- Composições: Refere-se à integridade de todas as partes constituintes, incluindo os componentes individuais, serviços e relacionamentos de dependência. Cada composição é normalmente descrita em termos de serem completas, incompletas, incompletas apenas de terceiros, incompletas apenas de terceiros ou completamente desconhecidas.
Práticas e Processos: Requisitos Mínimos
O elemento final de sua lista de materiais de software concentra-se na mecânica de uso do SBOM em si. As práticas e processos abrangem os detalhes operacionais de geração e utilização do SBOM e devem ser incluídos em qualquer política ou contrato que o solicite. A seguir estão os principais requisitos que devem ser detalhados na seção Práticas e Processos da sua Lista de Materiais de Software:
- Frequência: Esta seção detalha com que frequência uma organização precisa gerar uma nova lista de materiais de software. Geralmente, a NTIA recomenda que você gere um novo SBOM sempre que seu componente de software for atualizado ou uma nova versão for lançada. Espera-se também que os fornecedores gerem novos SBOMs sempre que encontrarem um erro na versão original ou aprenderem novos detalhes sobre os componentes de seu software que não foram incluídos na documentação inicial.
- Profundidade: A profundidade do seu SBOM depende do que está incluído no documento. Para estar em conformidade, espera-se que seu SBOM inclua todos os componentes de nível superior e todas as dependências transitivas. Nas situações em que o autor não consiga incluir todas as dependências transitivas, o documento deverá orientar o consumidor sobre onde encontrá-las.
- Há casos em que o autor do SBOM não pode fornecer um gráfico de dependência completo por um motivo ou outro. Isso pode ocorrer porque o componente não possui mais dependências ou eles não sabem se essas dependências existem ou não. O autor do SBOM é obrigado a especificar esse motivo.
- Distribuição e Entrega: O objetivo deste requisito é garantir que os SBOMs sejam entregues rapidamente e em um formato de fácil digestão. Embora este requisito não especifique o número de dias ou semanas em que os SBOMs devem ser entregues, eles devem ser entregues o mais rápido possível. Além disso, o SBOM deve ter funções apropriadas e permissões de acesso definidas quando for entregue. Finalmente, o requisito estipula que o SBOM pode ser distribuído com cada instância do produto ou disponibilizado de qualquer outra forma facilmente acessível, como através de um site público.
- Controle de acesso: Nos casos em que o fornecedor decida limitar o acesso aos dados do SBOM a usuários ou clientes específicos, o autor é obrigado a especificar os termos do controle de acesso. Há também a necessidade de oferecer subsídios específicos para os consumidores que gostariam de integrar os dados do SBOM nas suas próprias ferramentas de segurança.
- Acomodação de erros: O SBOM pode ajudar a melhorar a garantia de software e gerenciamento de risco da cadeia de suprimentos de software. No entanto, ainda está longe de ser perfeito. Assim, os consumidores precisam ser tolerantes com os erros ou omissões não intencionais ocasionais que podem ocorrer na preparação dos SBOMs.
Pensando além dos requisitos mínimos da NTIA
Até agora, discutimos os elementos mínimos exigidos em sua lista de materiais de software. Estes elementos mínimos representam os requisitos recomendados, especialmente para os casos de uso mais básicos desta documentação. Embora estabeleçam uma boa base para a origem e segurança do software, é preciso olhar além desses requisitos. A seguir estão algumas recomendações a serem consideradas para casos de uso de SBOM mais avançados.
Campos de dados adicionais
Além dos campos de dados abordados no documento de requisitos mínimos, existem campos de dados adicionais que são recomendados para casos em que é necessário um nível mais elevado de segurança. Alguns desses campos de dados adicionais incluem:
- Um hash criptográfico dos componentes de software
- Dados da fase do ciclo de vida do software
- Relações entre outros componentes
- Informações da licença
Software baseado em nuvem e software como serviço
Outra área potencial onde os requisitos do SBOM podem ir além do básico é no gerenciamento de produtos de software como serviço (SaaS). Esses tipos de produtos de software apresentam desafios únicos no que diz respeito aos dados SBOM. Para começar, os riscos de segurança no contexto da nuvem são únicos. Além disso, a responsabilidade pelo tratamento desses riscos cabe ao prestador de serviços. A preparação da documentação SBOM para software baseado em nuvem também é mais complexa, pois eles tendem a ter um ciclo de lançamento mais curto.
Integridade e Autenticidade SBOM
Outro problema provável que vale a pena observar é o processo de autenticação da própria fonte dos dados SBOM. Atualmente, as assinaturas e a infraestrutura de chave pública são as soluções essenciais para verificar a integridade do software no mundo digital atual. Autores e fornecedores de SBOMs podem precisar aproveitar essas assinaturas de software existentes para melhorar a confiabilidade dos dados SBOM.
Vulnerabilidade e exploração em dependências
Embora o objetivo dos SBOMs seja facilitar a detecção de vulnerabilidades, é importante observar que nem todas as vulnerabilidades nas dependências constituem grandes riscos para o software que depende delas. Para evitar desperdício de tempo e recursos, os fornecedores de software precisarão implementar medidas para determinar os impactos potenciais de uma vulnerabilidade de dependência no software que utiliza downstream e comunicar o nível de risco (ou a falta dele, neste caso) aos usuários do SBOM. dados a jusante.
Flexibilidade vs. Uniformidade na Implementação
Sempre que se discute segurança de software, a questão da flexibilidade e da uniformidade sempre vem à tona. Isso também se aplica a casos de uso avançados de SBOMs. Para implementar com êxito os SBOM, serão necessárias políticas amplas que se apliquem a todas as áreas, bem como casos específicos onde será necessária flexibilidade.