AI Hacking - Como os hackers utilizam a inteligência artificial nos ciberataques

Ler agora
Utilizamos inteligência artificial para as traduções dos sítios e, embora nos esforcemos por garantir a exatidão, estas podem nem sempre ser 100% precisas. Agradecemos a sua compreensão.

Formatos SBOM: Percepções de especialistas sobre a segurançaSupply Chain Software 

por OPSWAT
Partilhar esta publicação

Um SBOM (Software Bill of Materials) serve como elemento fundamental para garantir a integridade dos componentes de software - com origens que remontam aos primeiros esforços de desenvolvimento de software para documentar dependências de código aberto na década de 1990. Os SBOMs ajudam as organizações a rastrear os componentes na sua pilha de aplicações de software e a manter a conformidade com os regulamentos da indústria. À medida que os ecossistemas de software se tornam cada vez mais complexos, a adoção de formatos SBOM padronizados torna-se essencial para melhorar a segurança e a interoperabilidade. 

Definição de SBOM 

UmaBill of Materials (SBOM) Software Bill of Materials (SBOM) é um inventário abrangente de todos os componentes de uma aplicação de software, incluindo elementos de software proprietários, de código aberto e de terceiros. Fornece metadados detalhados, como o nome do software, a versão, o fornecedor, as informações sobre a licença e os hashes criptográficos para verificação.  

Ao oferecer visibilidade total das dependências de software, os SBOMs aumentam a transparência da cadeia de fornecimento, permitem a vulnerability detection e apoiam a conformidade regulamentar. Ajudam as organizações a reduzir os riscos de segurança, a simplificar as auditorias e a melhorar a resposta a incidentes, identificando e abordando potenciais ameaças no seu ecossistema de software. 

O que é uma norma SBOM? 

As normas SBOM (lista de materiais de software) garantem a consistência e a interoperabilidade entre diferentes sectores e organizações, fornecendo uma estrutura unificada para a documentação de componentes de software. Estas normas ajudam as empresas a simplificar a gestão de vulnerabilidades, a cumprir os requisitos regulamentares em constante evolução e a facilitar a colaboração entre produtores de software, fornecedores e utilizadores finais.

Ao adotar formatos SBOM normalizados, as organizações podem melhorar a segurança da cadeia de fornecimento de software, reduzir o risco de adulteração de software e melhorar a transparência geral do software.

O que é um formato SBOM? 

Os formatos SBOM são esquemas normalizados, legíveis por máquina, utilizados para estruturar e partilhar os dados contidos num SBOM. Estes formatos definem a forma como os pormenores dos componentes de software são representados e trocados entre sistemas.

Os formatos SBOM mais utilizados incluem o SPDX e o CycloneDX, ambos compatíveis com a automatização, a interoperabilidade e a rastreabilidade ao longo do ciclo de vida do software. Estes formatos permitem uma melhor vulnerability detection, conformidade regulamentar e gestão do risco da cadeia de fornecimento, assegurando uma documentação consistente dos componentes de software.

Componentes-chave de um SBOM 

gráfico com os principais componentes de uma sbom (lista de materiais de software)

Para ser eficaz, um SBOM deve conter elementos-chave que proporcionem total transparência num pacote de software. A NTIA (Administração Nacional de Telecomunicações e Informação) dos EUA define sete componentes mínimos para uma SBOM

  • Detalhes do fornecedor: Identifica a entidade responsável pelo software. 
  • Nome doSoftware e do componente: Identifica o componente de software. 
  • Informações sobre a versão: Especifica os detalhes da versão do componente. 
  • Nome do Autor: A pessoa ou organização (mas não a ferramenta) que criou o relatório SBOM. 
  • Relações de componentes: Descreve as dependências e interações entre elementos de software. 
  • Carimbo de data/hora: Parte da meta-informação SBOM que especifica a data e a hora em que o relatório foi produzido. 
  • Outros identificadores únicos: Fornece informações adicionais para definir os componentes de software 

Outros componentes essenciais incluem: 

  • Tipo de SBOM: Fornece contexto sobre como e por que o relatório SBOM é necessário. 
  • Informações sobre a licença: Define os direitos de utilização do software.
  • Hashes criptográficos: Garante a integridade e a autenticidade dos componentes. 

Formato SPDX SBOM

O formatoSoftware Package Data Exchange (SPDX), desenvolvido pela Linux Foundation, é uma norma SBOM amplamente utilizada, concebida para facilitar a conformidade com licenças de código aberto e o controlo de componentes de software. Fornece uma forma estruturada de documentar os componentes de software e os metadados associados, tornando-o uma ferramenta essencial para a transparência e segurança do software.

Além disso, o SPDX é o formato que recebeu o estatuto de certificação ISO (International Organization for Standardization), o que faz dele o formato que cumpre os requisitos de normalização e garantia de qualidade.

Os documentos em formato SPDX contêm vários elementos-chave:

Informações sobre a embalagem

Descreve o pacote, que pode consistir em um ou mais ficheiros - incluindo código fonte, binários, documentos, etc. Outros tipos de informação incluem detalhes sobre o autor original, a fonte, o URL de descarregamento, a soma de verificação e o licenciamento geral.

Metadados ao nível do ficheiro

Detalhes sobre os ficheiros específicos, como a licença, a soma de verificação, os contribuintes dos ficheiros, etc.

Outras informações sobre o licenciamento

Assegura a gestão da propriedade intelectual, especificando as licenças de software.

Lista de dependências de Software

Documenta a hierarquia das dependências de software.

Anotações e relações

Fornece metadados adicionais e estabelece relações entre artefactos de software.

O formato SPDX suporta vários formatos, permitindo flexibilidade com base em casos de utilização e compatibilidade de ferramentas:

  • Etiqueta/Valor (.spdx): Um formato simples baseado em texto
  • JSON (.spdx.json): Um formato leve e legível por máquina
  • YAML (.spdx.yml): Um formato de serialização de dados amigável para humanos
  • RDF/XML (.spdx.rdf): Um formato estruturado para representação de dados semânticos
  • Folha de cálculo (.xls): Um formato tabular útil para análise manual

O SPDX é amplamente adotado pelas principais empresas de tecnologia, organismos reguladores e comunidades de software de código aberto. É normalmente utilizado para:

  • Gestão de licenças de software de fonte aberta: Ajuda as organizações a controlar e a cumprir os requisitos de licenciamento de software de código aberto.
  • Auditoria de segurança: Fornece informações sobre componentes de software para detetar vulnerabilidades e gerir riscos.
  • Conformidade regulamentar: Assegura o cumprimento das normas do sector e dos requisitos legais relacionados com a transparência do software.
  • Controlo da proveniênciaSoftware : Estabelece uma linhagem clara dos componentes de software para uma melhor responsabilização.

Ao tirar partido do formato SPDX, as organizações podem melhorar a segurança da cadeia de fornecimento, simplificar os esforços de conformidade e obter uma maior visibilidade dos seus ecossistemas de software.

gráfico de comparação entre o formato sbom spdx e o formato sbom cyclone dx

Formato SBOM do CycloneDX 

Desenvolvido pela OWASP Foundation, o formato CycloneDX fornece uma BOM (Bill of Materials) de pilha completa, incluindo SBOM, e foi concebido com uma forte ênfase na segurança, gestão de vulnerabilidades e transparência abrangente do software. Ele fornece um modelo de objeto prescritivo que descreve eficientemente relações complexas entre componentes de software, serviços e dependências. 

As principais caraterísticas do formato CycloneDX incluem:

Representação extensiva de metadados

Captura detalhes do fornecedor, informações sobre licenças, autores, ferramentas, processos de fabrico, etc.

Conceção centrada na segurança

Permite a identificação exacta de vulnerabilidades, a análise de explorabilidade e o apoio a casos de utilização VEX.

Mapeamento de dependência e composição

Representa as relações diretas e transitivas entre componentes e serviços de software.

Vários formatos de serialização

Suporta JSON, XML e buffers de protocolo (protobuf), garantindo uma ampla compatibilidade com ferramentas de segurança.

Conformidade e normalização

Integra-se com normas de segurança como OWASP ASVS, MASVS, SCVS e SAMM, fornecendo uma estrutura legível por máquina para controlo de conformidade.

Com a sua arquitetura robusta e abordagem orientada para a segurança, o CycloneDX é amplamente adotado em aplicações centradas na cibersegurança para gestão de vulnerabilidades e monitorização da segurança. Isso torna o formato CycloneDX uma ferramenta essencial para o gerenciamento de riscos da cadeia de suprimentos de software. 

Formatos CycloneDX vs SPDX 

Característica SPDX CicloneDX
Foco Conformidade com a licença de fonte aberta e propriedade intelectualSegurança das aplicações e análise da cadeia de abastecimento
Características Metadados abrangentes para componentes de softwareLeve, de fácil utilização, com ênfase nos dados essenciais dos componentes e na avaliação da segurança
Casos de utilização Licenciamento de fonte aberta (originalmente), auditorias de conformidade e proveniência de softwareGestão de vulnerabilidades, análise da cadeia de fornecimento de software e monitorização da segurança
Adoção Grandes empresas tecnológicas e equipas de conformidadeFornecedores de ferramentas de segurança e empresas de cibersegurança, equipas DevSecOps

Explorar as etiquetas SWID 

gráfico que mostra as aplicações das etiquetas electrónicas

Aplicações de etiquetas SWID 

Para gerir corretamente o software, as empresas têm de manter inventários de software precisos dos seus dispositivos geridos, apoiando funções empresariais, de tecnologia da informação e de cibersegurança de nível superior. Os inventários de software exactos ajudam as organizações a: 

  • Gerir a conformidade com os contratos de licença de software através do acompanhamento das instalações e da utilização, evitando custos desnecessários. 
  • Garantir a adesão às políticas organizacionais, reduzindo a pegada do software e a superfície de ataque. 
  • Verificar actualizações e correcções para mitigar vulnerabilidades conhecidas e ciberameaças. 
  • Avaliar as configurações em relação às políticas de segurança para reforçar os sistemas e reduzir os vectores de ataque. 
  • Planear investimentos para actualizações de software e substituições de sistemas antigos. 

Embora alguns fornecedores ofereçam ferramentas para a gestão de licenças, actualizações, correcções e acompanhamento da configuração, as empresas dependem frequentemente de várias ferramentas para gerir diferentes produtos de software. Esta fragmentação aumenta o risco de erro humano e as restrições de recursos, limitando a capacidade de uma organização para manter uma gestão ativa do software. É necessário um mecanismo unificado para fornecer uma visão abrangente de todo o software de uma empresa, independentemente do fornecedor. 

As etiquetas SWID (Software Identification), tal como definidas pela norma ISO/IEC 19770-2:2015, respondem a esta necessidade fornecendo uma forma transparente de rastrear o software instalado em dispositivos geridos. Os ficheiros SWID Tag contêm metadados descritivos sobre uma versão específica do software e seguem um ciclo de vida em que são adicionados durante a instalação e removidos após a desinstalação. Este ciclo de vida garante que a presença de uma etiqueta SWID corresponde diretamente à presença do produto de software que descreve. 

O NIST (National Institute of Standards and Technology) recomenda a adoção da norma SWID Tag, e vários organismos de normalização, incluindo o TGC (Trusted Computing Group) e o IETF (Internet Engineering Task Force), integraram as SWID Tags nas suas normas.  

O NIST continua a promover as etiquetas SWID para uma adoção mais ampla na comunidade de software e para integração em dados de referência de cibersegurança e conteúdos de automatização da segurança. Além disso, o NIST incorporou os dados das etiquetas SWID na versão 1.3 da NVD (Base de dados nacional de vulnerabilidades) e do SCAP (Protocolo de automatização de conteúdos de segurança), melhorando o rastreio de vulnerabilidades e a gestão da segurança. 

Ao incorporar as etiquetas SWID nas estruturas de automatização da segurança, as empresas podem melhorar o rastreio do inventário de software, a avaliação de vulnerabilidades, a monitorização da conformidade e a postura geral de cibersegurança. 

Importância das listas de materiais Software 

Os SBOMs desempenham um papel crucial na transparência e responsabilidade do software. Eles fornecem informações sobre a cadeia de fornecimento de software, permitindo que as organizações verifiquem a integridade dos componentes de software. Este nível de transparência reduz o risco de adulteração de software e de modificações não autorizadas, reforçando, em última análise, a confiança entre produtores de software, fornecedores e utilizadores finais. 

Além disso, os SBOMs suportam a resposta a incidentes e a gestão do ciclo de vida do software. Quando são descobertas vulnerabilidades, ter um SBOM detalhado permite que as equipas de segurança avaliem rapidamente o impacto e implementem correcções de forma eficaz. Esta abordagem proactiva minimiza o tempo de inatividade e garante que os sistemas críticos permanecem seguros contra ameaças emergentes. 

SBOMs em Segurança e Conformidade 

Um SBOM é uma ferramenta essencial para garantir a segurança do software e a conformidade regulamentar. Ao fornecer um inventário abrangente de todos os componentes de software, os SBOMs permitem que as organizações acompanhem e gerenciem as vulnerabilidades de forma mais eficaz. Permitem às equipas de segurança identificar e mitigar proactivamente os riscos, assegurando que todas as dependências de terceiros e de código aberto estão actualizadas e livres de explorações conhecidas. Esta visibilidade é essencial à medida que as ciberameaças se tornam mais sofisticadas e generalizadas. 

Estruturas regulamentares como NIST, ISO, Ordem Executiva 14028 e outros guias técnicos regionais exigem medidas mais rigorosas de transparência e segurança de software, tornando os SBOMs um requisito essencial para a conformidade. As organizações que utilizam SBOMs podem demonstrar mais facilmente a adesão a esses padrões, evitando possíveis repercussões legais e financeiras. Ao manter SBOMs precisos e actualizados, as empresas podem simplificar as auditorias, reduzir as despesas gerais de conformidade e garantir que o software cumpre os regulamentos da indústria. 

Comparação de formatos SBOM 

Pontos fortes e pontos fracos 

Cada formato SBOM tem finalidades diferentes, pelo que é essencial escolher o formato correto com base em necessidades específicas. 

Característica Pontos fortesPontos fracos
SPDXAbrangente e amplamente utilizado. Grande ênfase no licenciamento e na conformidade. Pode ser complexo para projectos mais pequenos
CicloneDX Optimizado para a gestão da segurança e das vulnerabilidades. Menos ênfase nos pormenores da licença
Etiquetas SWID Integrado no software Normalização limitada entre sectores

Conclusão 

Compreender e implementar SBOMs é crucial para a segurança do software moderno. Ao tirar partido de formatos como as etiquetas SPDX, CycloneDX e SWID, as organizações podem aumentar a transparência da sua cadeia de fornecimento de software e reduzir os riscos de segurança. 

Próximos passos 

Avalie as práticas actuais da cadeia de fornecimento de software da sua organização e explore os formatos SBOM que se alinham com as suas necessidades de segurança e conformidade. 

Para saber mais sobre como proteger a sua cadeia de fornecimento de software com soluções SBOM robustas, visite a solução Software Supply Chain Security daOPSWAT

Mantenha-se atualizado com OPSWAT!

Inscreva-se hoje para receber as últimas actualizações da empresa, histórias, informações sobre eventos e muito mais.