O que são SBOMs e o que eles significam para software de código aberto?

O que há dentro do software comercial e de código aberto que você usa? Quanto foi escrito pelo fornecedor e quanto é código de terceiros? Todo esse código é confiável?

As ameaças são reais

A recente onda de ataques cibernéticos de alto perfil demonstra amplamente os efeitos indiretos dos incidentes cibernéticos agressivos. O hack da SolarWinds expôs seus clientes &’ redes à ameaça de comprometimento pelos cibercriminosos. O ataque Codecov expôs seus usuários &’ ambientes de integração / implantação contínua para os agentes de ameaça.

Hack de RELATEDSolarWinds: o que aconteceu e como se proteger

Em ambos os casos, o ataque às organizações se propagou em cascata para outros naquele ecossistema — os clientes. Os ataques que paralisam a infraestrutura crítica têm um impacto muito mais amplo. Não são apenas os clientes da organização ou serviço afetado que são afetados — as ondas se estendem para setores não relacionados e para a sociedade em geral.

O ataque de ransomware de maio de 2021 à Colonial Pipeline Company levou ao fechamento de um gasoduto de 5.500 milhas. Entre outros combustíveis refinados, o gasoduto entrega 45% do suprimento de gasolina — 2,5 milhões de barris por dia de gasolina — para a Costa Leste. A entrega de gasolina simplesmente parou. Os preços nas bombas dispararam e as compras entraram em pânico. Milhares de postos de gasolina tiveram que fechar devido à falta de abastecimento.

O ataque da Colonial Pipeline Company teve motivação financeira. Foi um ataque de ransomware, uma forma comum de extorsão digital. A Colonial Pipeline pagou aos cibercriminosos um resgate de 75 Bitcoins — cerca de US $ 4,4 milhões, dependendo das taxas de câmbio — para que seus sistemas sejam restaurados neles.

Mas se isso tivesse sido um ato de ciberterrorismo ou ciberguerra, não haveria opção de comprar o programa de descriptografia necessário para colocar os sistemas afetados novamente online. Um estado-nação com capacidades ofensivas cibernéticas pode tornar outro país incapaz de funcionar internamente por meio de uma campanha de ataques cibernéticos estratégicos.

RELACIONADO: Precisa pagar o resgate? Negocie primeiro

Respondendo às ameaças

Em 21 de março de 2021, o presidente Biden assinou uma ordem executiva para melhorar a segurança cibernética do país. Ele estabelece um conjunto de padrões e requisitos que todos os sistemas de informação federais devem atender ou exceder.

A seção 4 da ordem executiva trata das maneiras de aumentar a segurança da cadeia de suprimentos de software. Isso impõe obrigações com datas definidas aos departamentos governamentais para fornecer orientação, padrões e procedimentos para muitos aspectos do desenvolvimento e aquisição de software. Os fornecedores de software devem atender aos padrões e seguir os procedimentos para serem fornecedores de software qualificados para o governo.

A transparência é citada como um requisito. Os fornecedores de software devem revelar quaisquer componentes e bibliotecas de terceiros que foram usados ​​no desenvolvimento de seus produtos. Esse requisito se espalha pela cadeia de abastecimento, de modo que os fornecedores dessas bibliotecas e componentes devem, por sua vez, listar quaisquer componentes de software de origem externa que tenham usado em seus produtos.

O software de código aberto é mencionado especificamente. A ordem executiva fala sobre “ garantir e atestar, na medida do possível, a integridade e proveniência do software de código aberto usado em qualquer parte de um produto. ”

Isso não é surpreendente. Um relatório de 2021 sobre segurança de código aberto descobriu que o número médio de componentes de código aberto em projetos comerciais não triviais é de 528. Isso representa um aumento de 259% em relação a cinco anos atrás, quando a média era de 84 componentes de código aberto por projeto.

RELACIONADO: Como usar código-fonte aberto com segurança em seu projeto

Código aberto como consumível

Claramente, os projetos de código aberto devem atender aos padrões e procedimentos que serão promulgados como resultado da ordem executiva. À primeira vista, a parte da transparência deve ser fácil. Projetos de código aberto penduram seu código-fonte para qualquer tipo de escrutínio. Mas, é claro, os projetos de código aberto usam outros componentes de código aberto, que usam outros componentes de código aberto e assim por diante, aninhados como bonecos russos.

Além disso, os aplicativos de software têm dependências. Eles dependem de outros pacotes de software para operar. Ao optar por incluir um único componente de código aberto em seu próprio projeto de desenvolvimento, você pode, sem querer, incluir muitos outros produtos de código aberto como dependências.

Portanto, ter o seu código-fonte disponível para revisão não é suficiente. Você precisa fornecer uma lista dos ingredientes do software em seu produto, assim como a lista de alimentos e ingredientes químicos em uma embalagem de barra de chocolate. No mundo do software, isso é chamado de lista de materiais de software ou SBOM.

A lista de materiais do software

RELACIONADOComo se defender contra rootkits

A segurança começa com o conhecimento. Você precisa saber o que possui para ter certeza de que o protegeu. É por isso que os registros de ativos de TI e os registros de processamento de dados são tão importantes. Um SBOM — pronunciado ess-bomb — é um documento específico do aplicativo que lista todos os elementos de software que constituem um produto de software.

Esse é um conhecimento valioso. Tê-lo capacita os usuários desse software a tomar decisões de segurança. Se você conhece os componentes presentes no software, o risco associado a cada um deles e a gravidade de cada risco, pode fazer escolhas consideradas e informadas.

Você pode ler a lista de ingredientes em uma embalagem de barra de chocolate e descobrir que ela contém algo a que você é alérgico. Com um SBOM, você pode revisar as versões de compilação, números de lançamento dos ingredientes de software e decidir se deseja continuar ou não. Por exemplo, você pode se recusar terminantemente a usar um produto que incorpore (digamos) telnet ou um que use uma versão do SSH com uma vulnerabilidade conhecida.

Montar um SBOM detalhado não é uma tarefa de cinco minutos. Mas deve ser preciso e suficientemente detalhado, ou não servirá ao seu propósito. Como linha de base mínima, para cada componente de software em um projeto de software, um SBOM deve conter:

• Nome do fornecedor: o fornecedor ou as pessoas que escreveram o software.
• Nome do componente: o nome do componente.
• Identificador único: um identificador universalmente exclusivo (UUID ).
• String de versão: os detalhes de construção e versão do componente.
• Hash do componente: um hash criptográfico do componente. Isso permite que um destinatário verifique, se ele tem suspeitas, se um binário com o qual foi fornecido foi modificado.
• Relacionamento: o relacionamento entre os componentes de software descreve as dependências entre os componentes e quais componentes foram compilados e vinculado a outros componentes.
• Licenciamento: O tipo de licença sob a qual o componente de software é lançado.
• Nome do autor: O autor do SBOM. Este não é necessariamente o fornecedor do software.

Se houver uma ampla adoção de SBOMs, deve haver um padrão que defina os formatos de dados, conteúdo dos dados e processos e normas aceitos. É provável que isso apareça como parte da orientação que a ordem executiva solicitou ser criada.

Existem vários padrões SBOM concorrentes. Os três principais concorrentes neste espaço são Software Package Data Exchange (SPDX), o padrão ISO 19770-5: 2013 Software Identification (SWID) e CycloneDX. Será interessante ver se um deles é adotado pelo governo federal como seu padrão preferido.

A automação pode ajudar

RELACIONADOO que é Typosquatting e como os golpistas o usam?

Diversas classes de ferramentas podem ajudar na produção e uso de SBOMs. Estão disponíveis pacotes de software que podem digitalizar projetos, determinar dependências e gerar SBOMs — ou SBOMs quase completos nos quais você pode inserir alguns detalhes de acabamento.

Os SBOMs provavelmente serão disponibilizados como downloads ou como parte do pacote de software, de forma semelhante a um “ leiame ” Arquivo. Assim que estiver em posse do SBOM de outra pessoa, você precisará revisá-lo.

Isso vai levar algum tempo. Cada componente deverá ser verificado para garantir que seja permitido de acordo com os critérios que sua organização definiu e que o licenciamento de cada componente não causa conflitos para você.

Há um software disponível que pode realizar essas verificações para você. Os pacotes mais abrangentes listam as vulnerabilidades conhecidas para cada componente e a gravidade dessas vulnerabilidades.

A segurança começa com o conhecimento

A procedência dos pacotes de software e de todos os seus componentes vai se tornar uma ferramenta vital para os consumidores de software avaliarem e tomarem decisões de compra. Também será um diferencial para fornecedores e produtores de software, quer criem software para outros desenvolvedores ou para usuários finais usarem.