Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Nos últimos anos, a adoção de software de código aberto no desenvolvimento cresceu significativamente, representando atualmente até 90% do que é desenvolvido. Sua popularidade entre empresas em todo o mundo decorre da redução de custos e da aceleração do tempo de lançamento dos produtos no mercado. No entanto, há um aspecto crucial a ser considerado ao integrar componentes de software de código aberto. A Synopsys relata que 84% das bases de código comerciais e proprietárias incluem pelo menos uma vulnerabilidade conhecida de código aberto. Isso destaca a importância crescente de garantir a segurança dos componentes de código aberto que você utiliza. E é aí que uma Lista de Materiais de Software (SBOM) se torna útil.
O que é uma SBOM?
Componentes de código aberto e códigos de terceiros podem ser complexos, com várias camadas. Assim como as bonecas russas, essas partes se encaixam umas nas outras, e cada camada pode ter suas próprias regras. Para garantir que seu software seja seguro, as empresas precisam saber exatamente o que ele contém.
Uma SBOM fornece informações detalhadas sobre cada componente. É como um rótulo para software, que lista todas as partes e suas relações — como uma combinação de componentes de código aberto, peças de terceiros e o próprio código da empresa. Ela fornece detalhes técnicos sobre cada componente, incluindo seu nome, versão e licença. As SBOMs também podem incluir informações sobre questões de segurança, dependências transitivas, origens dos componentes e outras informações.
Por exemplo, na indústria automotiva, os fabricantes elaboram especificações detalhadas para cada veículo, incluindo peças fabricadas por eles mesmos e aquelas fornecidas por terceiros. Se for constatado que uma peça está com defeito, o fabricante sabe rapidamente quais veículos foram afetados. Isso permite que eles informem os proprietários sobre os reparos ou substituições necessárias. Esse tipo de registro claro é importante para identificar a origem dos defeitos e como corrigi-los de forma eficaz.
Requisitos mínimos de dados
Nos EUA, os desenvolvedores de software estão adotando cada vez mais a Lista de Componentes de Software (SBOM), influenciados pelas novas políticas governamentais de segurança da informação, que exigem medidas de segurança de software mais rigorosas.
O Executivo Presidencial n.º 14028, emitida em 12 de maio de 2021, com o objetivo de “Melhorar a Segurança Cibernética do País”, estabelece normas específicas para os sistemas de informação federais. Um aspecto fundamental dessa ordem, detalhado na Seção 4, envolve a formulação de diretrizes para práticas seguras de desenvolvimento e aquisição de software. O documento reconhece a SBOM como um elemento crucial para garantir a integridade do software e gerenciar os riscos associados à cadeia de suprimentos de software.
Em conformidade com a Ordem Executiva nº 14028, o Departamento de Comércio dos EUA e a Administração Nacional de Telecomunicações e Informação (NTIA) definiram requisitos mínimos de dados para componentes de software, categorizados em três grupos principais:
- Campos de dados incluem informações essenciais sobre cada componente de software, tais como:
-
- Nome do fornecedor: O nome de uma entidade que cria, define e identifica componentes.
- Nome do componente: Designação atribuída a uma unidade de software definida pelo fornecedor original.
- Versão do componente: Identificador utilizado pelo fornecedor para especificar uma alteração no software em relação a uma versão identificada anteriormente.
- Outros identificadores exclusivos: Outros identificadores utilizados para identificar um componente ou que servem como chave de consulta em bancos de dados relevantes.
- Relação de dependência: Caracteriza a relação em que um componente X, situado a montante, está incluído no software Y.
- Autor dos dados da SBOM: O nome da entidade que cria os dados do SBOM para este componente.
- Carimbo de data/hora: Registro da data e hora da compilação dos dados da SBOM.
- Suporte à automação facilita a geração automática de SBOMs e a legibilidade por máquina, permitindo a escalabilidade em todo o ecossistema de software. Além disso, as SBOMs devem ser geradas em um dos três formatos a seguir:
- Software Package Data eXchange (SPDX)
- CycloneDX
- Etiquetas de identificação de software (SWID)
Software Package Data eXchange (SPDX)
Esse formato é amplamente utilizado para documentar informações sobre licenças e componentes de software. Desenvolvido pela Linux Foundation, o SPDX padroniza a forma como as organizações comunicam os componentes de software e as licenças utilizadas em seus produtos, simplificando assim a conformidade.
CycloneDX
Com foco principal na segurança, o CycloneDX é um formato leve de SBOM projetado para uso em contextos de segurança de aplicativos e análise de componentes da cadeia de suprimentos. Ele oferece uma maneira padronizada de representar os componentes, bibliotecas e módulos de um aplicativo, juntamente com os riscos de segurança e as licenças associados a eles.
Etiquetas de identificação de software (SWID)
Desenvolvidas pela Organização Internacional de Normalização (ISO), as tags SWID são estruturas XML que fornecem identificação exclusiva para produtos de software. Elas auxiliam no gerenciamento do inventário de software e garantem a conformidade com as licenças. As tags SWID são particularmente úteis para fins de gerenciamento de ativos de software e segurança cibernética.
- Práticas e processos que devem ser seguidos para integrar a SBOM ao ciclo de vida de desenvolvimento seguro. Isso inclui estabelecer uma frequência para as atualizações da SBOM, definir a profundidade das árvores de dependências, lidar com elementos da SBOM com informações de dependência incertas ou incompletas e definir políticas para distribuição, entrega e controle de acesso.
Casos de uso do SBOM
Os casos de uso do SBOM podem ser divididos, de maneira geral, em três categorias principais:
- Detecção e gerenciamento de vulnerabilidades: O SBOM ajuda a acompanhar todos os componentes do código. Quando uma vulnerabilidade crítica é encontrada, as equipes de segurança podem usar rapidamente o SBOM para localizar o problema no código, compreender seu impacto e priorizar sua correção. Por exemplo, o SecureChain para Java da TuxCare fornece um SBOM detalhado para cada pacote Java verificado e corrigido pelo serviço, garantindo total transparência para a tomada de decisões bem fundamentadas.
- Gerenciamento de licenças de software: Com uma SBOM, as empresas podem acompanhar facilmente as licenças de softwares de terceiros e de código aberto. As licenças costumam mudar, por isso são necessárias verificações regulares. Isso ajuda a garantir que a empresa não viole nenhum contrato de licença ou direito de propriedade intelectual, evitando problemas legais e riscos financeiros.
- Melhoria do ciclo de vida do desenvolvimento de software (SDLC): A SBOM torna todo o processo de criação, implantação e manutenção de software mais eficiente. Por exemplo, os desenvolvedores listam todas as dependências de software em uma SBOM inicial à medida que escrevem o código. Essa SBOM é atualizada durante as fases de teste e implantação, à medida que novas vulnerabilidades e dependências são identificadas. Ela também alerta os desenvolvedores sobre quaisquer problemas que surjam após o software estar em uso, garantindo atualizações e melhorias contínuas.
O Futuro da SBOM
A SBOM é particularmente crucial para empresas que fornecem software a órgãos governamentais, sobretudo em setores como o de defesa e o aeroespacial. No entanto, sua relevância se estende também a outras empresas.
O recente aumento nos ataques à cadeia de suprimentos, que muitas vezes exploram vulnerabilidades de código aberto, ressalta a importância de examinar rigorosamente componentes, bibliotecas e frameworks de código aberto de terceiros. Esses ataques podem permitir que agentes mal-intencionados assumam o controle total dos sistemas de uma empresa, prejudiquem a funcionalidade dos produtos, introduzam malware e até mesmo disseminem vírus para clientes e outras organizações com as quais a empresa interage. O impacto imprevisível e potencialmente abrangente desses ataques os torna uma ameaça significativa.
Gartner prevê que, até 2025, 60% das organizações incorporarão a SBOM em seus sistemas de segurança. No entanto, embora seja útil, a SBOM não é uma panaceia para os desafios da cadeia de suprimentos e da garantia de software, conforme reconhecido pela NTIA. É uma das muitas ferramentas disponíveis, não uma solução abrangente. A eficácia das SBOMs depende de sua ampla adoção, que ainda está em andamento, com padrões e requisitos em constante evolução. Alcançar o uso universal levará tempo, dada a variedade emergente de ferramentas e padrões atualmente em desenvolvimento.
