Gerando listas de materiais de software (SBOMs) com SPDX na Microsoft
13 de outubro de 2021
A Ordem Executiva Presidencial dos EUA sobre Melhorar a Segurança Cibernética da Nação, divulgada em 12 de maio de 2021, veio em resposta ao ataque à cadeia de suprimentos da SolarWinds e pede melhorias abrangentes para modernizar a segurança cibernética do Governo Federal e melhorar a segurança da cadeia de suprimentos de software. Um dos itens que eles estão exigindo é uma Lista de Materiais de Software (SBOM).
Os SBOMs não são novos para a Microsoft. Na verdade, temos gerado nossos próprios manifestos de compilação proprietários há anos. Desde setembro de 2019, a Microsoft também liderou e co-presidiu o grupo de trabalho intersetorial de SBOM Tool-to-Tool (3T) do Consortium for Information & Software Quality (CISQ) para definir um novo esquema de SBOM padrão. O que é novo é que a Microsoft escolheu, juntamente com os outros em 3T, fundir o esforço 3T com o trabalho da Linux Foundation e usar o Software Package Data Exchange (SPDX) para todos os SBOMs que geramos, e embarcamos na missão de fazer isso para todos os softwares que produzimos. Isso significa que tivemos que converter nossas ferramentas de geração de manifesto existentes para arquivos JSON de saída no formato SPDX 2.2.1 padrão ISO/IEC 5962:2021, e precisamos implantar esse recurso em nossos principais sistemas de engenharia.
Por que ter um SBOM?
Um SBOM é útil para produtores e consumidores de software, pois fornece transparência de software, integridade de software e benefícios de identidade de software. Aqui está um pouco sobre cada um:
- Transparência de software: Os SBOMs fornecem uma lista de ingredientes usados na criação de um software, como software de código aberto, componentes e, potencialmente, até mesmo ferramentas de construção. Isso permite que produtores e consumidores façam um melhor inventário e avaliem o risco de licença e vulnerabilidade.
- Integridade do software: Embora a assinatura de código ainda seja o padrão do setor para confiar no software e em sua integridade, os SBOMs contêm somas de verificação de pacotes e arquivos para permitir que os consumidores validem os hashes, o que pode ser útil em cenários em que as assinaturas não estão presentes.
- Identidade do software: quando as vulnerabilidades (CVEs) são criadas, elas são atribuídas a um identificador CPE (Common Platform Enumeration), que pode ter problemas para atribuir um CPE a um software específico. Os IDs de software dentro dos SBOMs fornecem uma maneira muito mais precisa de identificar o software.
Projetando SBOMs compatíveis com a ordem executiva
O relatório delineou quais campos devem ser incluídos em nossos SBOMs, por isso mapeamos os campos mínimos NTIA para SPDX 2.2.1:
| Campo NTIA | Descrição da NTIA | Campo SPDX 2.2.1 |
| Nome do fornecedor | O nome de uma entidade que cria, define e identifica componentes | Fornecedor de Pacotes |
| Nome do componente | Designação atribuída a uma unidade de software definida pelo fornecedor original | Nome do pacote |
| Versão do componente | Identificador usado pelo fornecedor para especificar uma alteração no software a partir de uma versão previamente identificada | Versão do pacote |
| Outros identificadores exclusivos | Outros identificadores que são usados para identificar um componente ou servem como uma chave de pesquisa para bancos de dados relevantes | Identificador SPDX do pacote |
| Relação de dependência | Caracterizando a relação de que um componente upstream X está incluído no software Y | Relação |
| Autor de Dados SBOM | O nome da entidade que cria os dados da SBOM para este componente | Criador |
| Timestamp | Registro da data e hora do conjunto de dados do SBOM | Criado |
Isso ajudou a definir a primeira fase de nossa implementação da especificação SPDX. Sabíamos que tínhamos que incluir todos os campos obrigatórios da especificação SPDX 2.2, além de incluir campos opcionais específicos para estabelecer uma linha de base para nossa primeira implementação. Embora o nome do fornecedor, a versão do pacote, a soma de verificação do pacote e os campos de relacionamento sejam opcionais no SPDX, estamos tornando-os obrigatórios para os produtos Microsoft.
Gerando SBOMs em escala na Microsoft
A Microsoft se preocupa profundamente com a produtividade do desenvolvedor e quer minimizar o impacto nos tempos de compilação, especialmente considerando que temos uma média de ~ 500.000 compilações ocorrendo em um determinado dia. Levando isso em conta, veja como estamos planejando implementá-lo nos milhares de produtos da Microsoft que criamos:
- Projetar ferramentas para automatizar a geração de SBOM no momento da compilação.
- Produza SBOMs para todas as compilações oficiais.
- Pilote esse recurso com uma pequena base de clientes para incorporar feedback.
- Aproveite os recursos existentes de CI/CD para injetar de forma inteligente nossa ferramenta de geração de SBOM em pipelines de compilação, aspirando a ter a geração de SBOM “ativada por padrão”.
- Expanda esse recurso para nossos vários sistemas de engenharia em uma implantação em fases.
- Forneça um binário executável de plataforma cruzada para ambientes de compilação não padrão.
Capacidades do nosso gerador de SBOM
Nossa ferramenta geradora SPDX SBOM é multiplataforma, suportando ambientes Windows, Linux e Mac (e será de código aberto em breve). Ele também fornece detecção de software de código aberto (OSS) para inclusão no SBOM em NPM, NuGet, PyPI, CocoaPods, Maven, Golang, Rust Crates, RubyGems, contêineres (e seus pacotes Linux), repositórios públicos Gradle, Ivy, GitHub e muito mais. Ele gera duas somas de verificação para cada pacote e arquivo – SHA256 (hash forte e resistente a colisões) e SHA1 (exigido pela especificação SPDX). Nossa ferramenta também automatiza a assinatura digital de cada SBOM para proteger sua integridade e, em seguida, cria uma nova pasta na raiz da queda de compilação chamada _manifest; é aqui que o arquivo JSON SPDX é armazenado. Um exemplo é mostrado abaixo:
Adicionando informações de proveniência de compilação à SBOM
Os SBOMs fornecem principalmente transparência sobre o conteúdo da saída da compilação. Na Microsoft, queríamos dar um passo adiante e fornecer informações de proveniência sobre o sistema de compilação onde o SBOM foi gerado e tornar o próprio SBOM inviolável. Para conseguir isso, integramos um serviço de assinatura com nossa ferramenta de geração de SBOM, que executa o seguinte fluxo de trabalho:
- No início de uma compilação, o serviço de compilação cria um token de sessão que inclui declarações que descrevem a compilação (por exemplo, ID de confirmação do código-fonte, ID da compilação, URL do repositório) que identificam exclusivamente uma execução de compilação.
- O serviço de compilação envia esse token para o agente/executor de compilação para usar durante a compilação.
- A compilação é executada normalmente, criando saídas.
- É criado um SBOM que descreve as saídas.
- O agente de compilação chama o serviço de assinatura, fornecendo o token de sessão e um hash do SBOM.
- O serviço de compilação cria um arquivo de catálogo com uma assinatura que atesta que o hash da SBOM veio da compilação descrita pelas declarações no token de sessões.
Validando nossos SBOMs no lançamento
Um cenário-chave que adicionamos é a capacidade de validar os hashes de todos os arquivos listados no SBOM em relação aos hashes da própria compilação e validar que a assinatura digital no SBOM é a assinatura confiável da Microsoft. Se nossa ferramenta de validação de SBOM detectar uma incompatibilidade de hash ou assinatura incorreta, nossa ferramenta de validação de SBOM bloqueará a implantação. Isso garante que nada tenha sido adulterado entre a compilação e o lançamento. No futuro, também gostaríamos de adicionar verificações de que, por exemplo, a assinatura mostra que a compilação veio da definição de compilação esperada.
Prevemos mais anúncios emocionantes para seguir sobre este tópico no futuro, então fique atento!
