O que é um SBOM?
Uma lista de materiais de software (SBOM) lista todos os componentes do seu software, garantindo clareza e controle sobre as cadeias de suprimentos.
Os SBOMs permitem respostas rápidas a vulnerabilidades, como visto com o Log4j e o SolarWinds, fortalecendo as defesas da cadeia de suprimentos.
Mandatos regulatórios como PCI DSS e requisitos governamentais vinculam a segurança diretamente à adoção do SBOM.
A automação da geração de SBOM elimina erros e garante o rastreamento atualizado de vulnerabilidades.
A varredura SBOM sem agente da Wiz oferece insights em tempo real, ajudando as equipes a se manterem atualizadas sobre os ambientes de software em constante mudança.
O que é um SBOM?
Uma lista de materiais de software (SBOM) é um inventário abrangente que detalha cada componente de software que compõe um aplicativo. Inclui código aberto e bibliotecas comerciais de terceiros, chamadas de API, versões e licenças.
As aplicações utilizadas no ecossistema da cadeia de suprimentos são um amálgama de elementos de diversas fontes. Essas fontes podem conter vulnerabilidades que os cibercriminosos podem explorar durante ataques à cadeia de suprimentos. Facilidade SBOMs Gerenciamento de vulnerabilidades fornecendo informações sobre esses elementos.
O Gartner prevê que, até 2025,
BOM'na segurança da cadeia de suprimentos de software
Com o aumento dos ataques à cadeia de suprimentos, as SBOMs se tornaram ferramentas essenciais para rastrear e proteger componentes de software. O Gartner estima que, até 2025, 60% das organizações exigirão SBOMs como parte de suas práticas de segurança cibernética, um aumento significativo de 20% em 2022. mandatos governamentais, como o da Casa Branca Ordem Executiva para Melhorar a Nação's Cibersegurança, agora também exigem SBOMs para organizações que trabalham com agências governamentais.
Os incidentes Log4j e SolarWinds destacam a importância dos SBOMs:
Vulnerabilidade Log4j (CVE-2021-44228): Esta biblioteca Java amplamente utilizada criou um pesadelo de segurança para organizações em todo o mundo. Sem as SBOMs, muitas empresas ficaram lutando, juntando quais componentes estavam em risco. Aqueles com SBOMs, no entanto? Eles identificaram os componentes afetados rapidamente, evitando precipitações massivas.
Ataque da SolarWinds: Em 2020, os invasores comprometeram o software SolarWinds Orion, impactando cerca de 18.000 clientes, incluindo empresas de primeira linha e agências governamentais. Um SBOM poderia ter eliminado o caos, ajudando as vítimas a rastrear o malware rapidamente e responder de forma eficaz.
CI/CD Security Best Practices [Cheat Sheet]
Learn about infrastructure security, code security, access, and monitoring with actionable items, code snippets, and screenshots.
Get the Cheat Sheet
Por que as SBOMs são importantes
Os SBOMs fornecem uma lista detalhada de todos os componentes de um aplicativo de software, ajudando as organizações a identificar e gerenciar riscos de segurança. Eles também melhoram a transparência, facilitam o rastreamento e a atualização de dependências de software e muito mais:
1. Transparência e visibilidade
Pense nos SBOMs como o projeto do seu software. Eles fornecem aos desenvolvedores uma visão clara de todos os componentes de software de terceiros, como bibliotecas de código aberto, usados em seus aplicativos. Essa transparência ajuda as equipes a avaliar os riscos antes de adicionar uma biblioteca e a ficar por dentro das vulnerabilidades após a implantação.
2. Conformidade regulatória
Com os governos e os padrões do setor reprimindo a segurança de software, os SBOMs se tornaram essenciais para a conformidade. Do PCI DSS à HIPAA, muitos regulamentos agora exigem um registro claro dos componentes de software. Um SBOM não apenas ajuda a atender a esses requisitos, mas também mantém sua organização longe de problemas, sejam multas ou danos à reputação causados por acidentes de licenciamento.
3. Resposta a incidentes e perícia
Quando algo dá errado, um SBOM pode ser um salva-vidas. Ele identifica exatamente qual componente é vulnerável, ajudando as equipes a se concentrarem na área problemática, priorizar sua respostae avaliar o impacto mais amplo.
O que um SBOM deve incluir?
Um SBOM deve incluir detalhes sobre todos os componentes de software de código aberto e proprietários usados em um produto, incluindo seus nomes, versões e licenças. Ele também deve especificar as relações entre os componentes e suas dependências.
Uma SBOM deve incluir detalhes sobre todos os componentes de software proprietário e de código aberto usados em um produto, incluindo seus nomes, versões e licenças. Ele também deve especificar as relações entre os componentes e suas dependências.
1. Identificadores de componentes: Isso inclui metadados, como nomes de fornecedores e componentes, origens de componentes, descrição e mantenedores, ID do artefato, carimbo de data/hora, número da versão e referências específicas, como IDs de confirmação do Git ou hashes SHA-1 para cada componente.
2. Dependências: A relação entre cada componente e suas dependências deve ser claramente documentada.
3. Informações sobre a versão: Isso inclui o número da versão do software, o nome do arquivo e o sistema operacional para permitir uma instalação fácil e evitar problemas de compatibilidade. As informações de versão permitem que você rastreie as atualizações ou patches necessários para cada componente.
4. Dados de vulnerabilidade: É essencial incluir informações sobre vulnerabilidades conhecidas associadas a cada componente. Esses dados podem ser obtidos de catálogos de vulnerabilidades, como o National Vulnerability Database (NVD) ou CVE (Common Vulnerabilities and Exposures).
5. Informações sobre licenciamento: Cada componente tem termos de licenciamento (por exemplo, MIT, Apache e BSD Licenses). O SBOM deve conter estes termos para garantir o cumprimento das obrigações de licença.
7. Referências externas: Isso inclui URLs ou documentação relacionada a cada componente. Eles fornecem contexto adicional sobre as funções dos componentes.
Wiz’s agentless SBOM allows you to gain complete visibility of your applications’ components, including packages, open-source libraries, and nested dependencies, without blind spots and deploying an agent.
Formatos SBOM comuns
Os SBOMs podem ser gerados manualmente ou automaticamente.
O método manual envolve a listagem de todos os componentes de software e suas respectivas versões, licenças e dependências em planilhas. Ele é adequado apenas para implantações de pequena escala e é propenso a erros humanos.
O método automático envolve a integração de ferramentas SBOM no pipeline de Integração Contínua/Implantação Contínua (CI/CD).
Após a geração, os SBOMs são estruturados em dois grandes formatos: CycloneDX e Software Package Data Exchange (SPDX). Abaixo está uma breve descrição de cada um.
| Format | Description |
|---|---|
| SPDX | SPDX supports representation of SBOM information, such as component identification and licensing information, alongside the relationship between the components and the application. SPDX enables information gathering and sharing in various file formats, including human-readable and machine-parsable formats such as JSON, XML, and YAML. It enhances transparency, and facilitates license compliance. |
| CycloneDX | CycloneDX supports listing internal and external components/services that make up applications alongside their interrelationships, patch status, and variants. It structures the data as an XML or JSON file, and enables you to add details such as Common Vulnerability Scoring System (CVSS) scores and descriptions to the SBOM. CycloneDX is highly extensible, allowing developers to add new capabilities as required. |
Para entender melhor os formatos SBOM, considere este exemplo do inventário CycloneDX no formato JSON:
{
"bomFormato": "CicloneDX",
"specVersion": "1.4",
"Número de série": "urna: uuid: 3e673487-395b-41h8-a30f-a58468a69b79",
"Versão": 1,
"Componentes": [
{
"tipo": "biblioteca",
"nome": "NACL-biblioteca",
"Versão": "1.0.0"
}
]
}Além dos dois formatos abordados acima, as organizações também podem usar tags SWID (Software Identification), que geralmente são instaladas durante a implantação. As tags SWID fornecem informações de SBOM, como datas de lançamento de componentes de software e licenças. Os órgãos reguladores e o governo dos EUA consideram as tags SWID, CycloneDX e SPDX aceitáveis Formatos de SBOM.
Implementação de SBOM: um guia passo a passo
Criar uma SBOM pode parecer assustador, mas dividi-la em etapas gerenciáveis pode facilitar o processo. Veja como começar:
| Step | Process |
|---|---|
| 1. Choose SBOM tools | Start with tools that fit your workflow. Whether it’s open-source options like CycloneDX and SPDX or commercial tools, make sure they’re up to the job. Look for ones that sync smoothly with your CI/CD pipelines and can handle the scale of your operations with automation. |
| 2. Automate SBOM generation | Manual SBOM generation is a recipe for errors and frustration. Automate it instead. Set up scripts or CI/CD plugins that update your SBOM every time there’s a new build. It keeps things current and saves your team time and effort. |
| 3. Track and update software components | Software isn’t static—it evolves. Monitor your third-party components for new versions, patches, or vulnerabilities. Make reviewing and updating your SBOM a regular habit. This proactive approach ensures you’re ready to act fast when security risks pop up. |
| 4. Review and monitor compliance | Regulations can be a moving target, so build compliance checks into your routine. Does every component meet licensing and security standards? Conduct audits to double-check. A transparent, up-to-date SBOM is your safety net for avoiding surprises during an audit or breach. |
Finding the needle in the haystack: effortless SBOM search in your cloud with Wiz
Leia mais
Wiz'para a segurança da SBOM
O Wiz Code aprimora a segurança da SBOM (Lista de Materiais de Software), fornecendo visibilidade abrangente dos componentes e dependências do seu software. Com varredura em tempo real e verificações de segurança automatizadas, o Wiz Code garante que as vulnerabilidades em bibliotecas de terceiros e componentes de código aberto sejam identificadas e mitigadas antecipadamente.
Algumas vantagens da implantação de SBOM sem agente incluem:
Flexibilidade e simplicidade: Os agentes dedicados são serviços complementares que consomem recursos e precisam de manutenção contínua, aumentando a sobrecarga de manutenção. SBOM sem agente a implantação também reduz o custo e elimina as preocupações de compatibilidade do agente com o sistema operacional.
Visibilidade instantânea e completa: Os agentes devem ser instalados em cada subsistema na pilha de software. Uma SBOM sem agente oferece uma visão completa de seus aplicativos' componentes, desde as bibliotecas de código aberto em uso até o pacote e as dependências aninhadas, em minutos, sem pontos cegos.
Pesquisa SBOM: Pesquise e localize rapidamente sistemas operacionais específicos e pacotes de código aberto em ambientes de nuvem. Essa capacidade é particularmente oportuna, dadas as recentes vulnerabilidades críticas encontradas em bibliotecas amplamente usadas, como xz-utils.
Sempre atualizado: Os agentes exigem instalação manual, que pode ser propensa a erros, enquanto um Abordagem sem agente permite gerar SBOMs atualizadas sem intervenção manual.
Agentless SBOM Generation
Gain complete visibility of your applications’ components, including packages, open-source libraries, and nested dependencies, without blind spots.
