Os programadores utilizam habitualmente código de terceiros para criar as suas aplicações, em nome da eficiência e da poupança de tempo. No entanto, esta dependência de componentes externos, particularmente de software de código aberto (OSS), introduz riscos significativos, incluindo vulnerabilidades e problemas de licenciamento. De acordo com um inquérito do GitHub de 2023, 31% dos programadores consideram que encontrar e corrigir vulnerabilidades de segurança é a segunda tarefa mais importante, logo a seguir a escrever código (32%).
Consequentemente, muitas organizações estão preocupadas com a sua dependência do OSS, uma vez que este é frequentemente alvo de hackers. As organizações enfrentam desafios com o aumento da vulnerabilidade em toda a cadeia de fornecimento de software e com a compreensão de como mitigar eficazmente o risco na sequência de recentes ataques de alto perfil.
Um relatório de investigação do ESG revela que 91% das organizações sofreram um incidente na cadeia de fornecimento de software nos últimos 12 meses. Os incidentes mais comuns incluem:
Vulnerabilidades proeminentes como Log4J, Curl, Apache Struts e OpenSSL conduziram a numerosos casos de danos operacionais. Estas vulnerabilidades realçam o grave impacto que as organizações sofrem quando é explorada uma única fraqueza na cadeia de fornecimento de software. Em resposta a estes riscos crescentes, as entidades reguladoras de todo o mundo estão a dar ênfase à transparência e segurança do software. A adoção de um Software Bill of Materials (SBOM) está a tornar-se uma estratégia fundamental para gerir os riscos da cadeia de fornecimento de software.
Regulamentos SBOM ganham impulso
Os regulamentos SBOM estão cada vez mais difundidos. Muitos governos publicaram recomendações relativas à implementação do SBOM. Nos EUA, as recomendações do SBOM estão incluídas em várias diretrizes governamentais, incluindo:
Em 2023, a CISA publicou três documentos-chave para promover a adoção do SBOM. Estes centraram-se na escalada da utilização do SBOM, na exploração de novas tecnologias e aplicações e na promoção da colaboração da comunidade.
Na Europa, a Agência Europeia para a Cibersegurança (ENISA) publicou "Guidelines for Securing the Supply Chain for the Internet of Things", que oferece às organizações informações valiosas para melhorar a cibersegurança e gerir os riscos da cadeia de abastecimento relacionados com o software.
Outros países emitiram orientações semelhantes, nomeadamente:
Aconselha as organizações a utilizarem os SBOM para avaliar os riscos associados aos componentes de software que utilizam e para identificar e resolver as vulnerabilidades desses componentes.
No "Manual de Segurança da Informação: Guidelines for Software Development", a ACSC recomenda a utilização de SBOMs para aumentar a transparência da cadeia de fornecimento cibernético, facilitando a identificação e a gestão dos riscos de segurança associados a componentes de software individuais utilizados em aplicações.
Em "Recommendations to Improve the Resilience of Canada's Digital Supply Chain" (Recomendações para melhorar a resiliência da Supply Chain digital do Canadá), o CSE defende a utilização de SBOMs para aumentar a transparência e enfrentar eficazmente as ameaças à cadeia de abastecimento de software.
Como o PCI DSS necessita da geração de SBOM
Reconhecendo os riscos crescentes para os dados de cartões de pagamento, a Norma de Segurança de Dados da Indústria de Cartões de Pagamento (PCI DSS) tornou-se uma força motriz para a adoção de SBOM. A versão mais recente, PCI DSS 4.0, exige o uso de SBOMs, ressaltando seu papel crítico na proteção de informações confidenciais. Ao fornecer um inventário detalhado dos componentes de software, os SBOMs permitem que as organizações identifiquem e resolvam vulnerabilidades de forma proactiva, reduzindo o risco de violações de dados dispendiosas e perdas financeiras.
Criado em 2004, o PCI DSS é uma norma de segurança abrangente, concebida para proteger as informações dos cartões de crédito. Define um conjunto de requisitos rigorosos para as empresas que lidam com transacções com cartões de crédito, adaptados ao volume de transacções processadas anualmente. A versão de 2022 do PCI DSS v4.0 introduziu alterações significativas, incluindo o mandato SBOM, para fazer face à evolução das ameaças. A conformidade com o PCI DSS v4.0 é obrigatória até abril de 2024, com requisitos específicos introduzidos gradualmente até 31 de março de 2025.
Fonte: Visão geral do PCI DSS V4.0
Ao exigir SBOMs, o PCI DSS permite que as organizações obtenham uma compreensão abrangente do seu ecossistema de software, permitindo-lhes identificar e resolver vulnerabilidades de forma proactiva. Esta abordagem reduz significativamente o risco de violações de dados dispendiosas e perdas financeiras.
Uma versão mais recente do PCI DSS, a versão 4.0.1, foi lançada em meados de 2024. Isto significa que a versão anterior, 4.0, deixará de ser válida após 31 de dezembro de 2024. No entanto, a nova versão não adiciona ou remove quaisquer regras e não altera os prazos. Por conseguinte, as informações sobre os requisitos SBOM neste blogue aplicam-se às versões 4.0 e 4.0.1.
Conformidade com o requisito 6.3.2 do PCI DSS
O requisito SBOM no PCI DSS v4.0 faz parte dos aprimoramentos mais amplos feitos no PCI DSS em sua última iteração. Introduzido como parte dos 64 novos requisitos adicionados na versão 4.0, o requisito SBOM aborda especificamente a necessidade de as organizações manterem um inventário de componentes de software, concentrando-se particularmente em software personalizado e sob medida.
Este requisito está classificado no Requisito 6 do PCI DSS, que exige a criação e manutenção de sistemas e aplicações seguros através da implementação de medidas de segurança fortes e da realização regular de avaliações e actualizações de vulnerabilidades. Este requisito é essencial para reduzir os riscos colocados pelas vulnerabilidades do software e proteger os dados do titular do cartão. A Secção 6 abrange cinco áreas principais:
- 6.1 Os processos e mecanismos de desenvolvimento e manutenção de sistemas e software seguros são definidos e compreendidos.
- 6.2 O software personalizado e por medida é desenvolvido de forma segura.
- 6.3 As vulnerabilidades de segurança são identificadas e tratadas.
- 6.4 As aplicações Web viradas para o público estão protegidas contra ataques.
- 6.5 As alterações a todos os componentes do sistema são geridas de forma segura.
Mais especificamente, o requisito 6.3.2 é uma atualização importante que resultou de várias violações em que vulnerabilidades em componentes de terceiros, ou violações de fornecedores de componentes de terceiros, levaram a um comprometimento dos dados do titular do cartão. O requisito tem a seguinte redação:
6.3.2.b Examinar a documentação do software, incluindo a do software personalizado e sob medida que integra componentes de software de terceiros, e compará-la com o inventário para verificar se o inventário inclui o software personalizado e sob medida e os componentes de software de terceiros.
As organizações devem documentar e gerir exaustivamente os componentes e serviços específicos utilizados nas suas aplicações. Embora algumas dessas informações possam ter sido cobertas por diagramas de fluxo de dados, os novos requisitos exigem uma documentação muito mais detalhada. Manter o controlo destes detalhes pode ser um desafio à medida que os componentes são actualizados e alterados. É aconselhável utilizar um modelo padrão para registar estas informações. Além disso, alguns repositórios de código-fonte, como o GIT, podem oferecer ferramentas para exportar uma lista de componentes em uso. No mínimo, seu inventário deve incluir:
- Componentes de aplicação (normalmente projectos de repositório)
- Lista de componentes de terceiros
- Lista de dependências da aplicação (ou seja, Tomcat, Jboss, .NET, Middleware)
- Lista de scripts de página de pagamento autorizados
Como o OPSWAT SBOM pode ajudar a cumprir os requisitos do PCI DSS
Os regulamentos exigem cada vez mais SBOMs para garantir a segurança da cadeia de fornecimento de software. No entanto, as organizações estão a lutar para criar inventários precisos da composição do seu código de software.
Fonte: Relatório EGS 2024
A criação de SBOMs exactos e abrangentes representa, no entanto, um desafio substancial para as organizações. Estes documentos exigem um inventário meticuloso dos componentes de software, necessitando de informações detalhadas sobre as suas origens, versões e interdependências. Sem SBOMs precisos, as organizações lutam para identificar, avaliar e mitigar efetivamente os riscos inerentes à sua cadeia de fornecimento de software.
Diretrizes para a geração de SBOMs
OPSWAT O SBOM automatiza a geração de SBOMs para código e contentores, melhorando a segurança e ajudando a conformidade na cadeia de fornecimento de software.
- Identificar todos os componentes e dependências
Identificar com exatidão todos os componentes de software, incluindo bibliotecas de código aberto e de terceiros, juntamente com as suas versões e dependências. Isso forma a base para um SBOM robusto. - Avaliar os riscos do OSS
Avalie os riscos potenciais associados aos componentes OSS. Considere factores como a conformidade com a licença, vulnerabilidades de segurança e estado de manutenção. Priorize os componentes com base na sua criticidade para o software. - Análise das vulnerabilidades do OSS
Utilizar ferramentas de análise de vulnerabilidades e de geração de SBOM para identificar vulnerabilidades conhecidas nos componentes OSS. Dar prioridade às vulnerabilidades com base na sua gravidade e potencial impacto no software.
Utilizar OPSWAT SBOM
OPSWAT O SBOM automatiza a geração de SBOMs para código e contentores, melhorando a segurança e ajudando a conformidade na cadeia de fornecimento de software.
Eis como pode utilizar OPSWAT SBOM para gerar SBOMs de forma eficaz:
Ao fornecer um inventário de todas as bibliotecas e componentes de código aberto utilizados numa aplicação, o OPSWAT SBOM ajuda a gerir as vulnerabilidades de dependência na cadeia de fornecimento de software, permitindo aos utilizadores identificar e corrigir vulnerabilidades nas aplicações de forma eficiente.
Para além de identificar vulnerabilidades, o OPSWAT SBOM valida as licenças associadas a cada componente de software. Isso garante a conformidade com os termos de licenciamento e evita possíveis armadilhas legais. Saiba mais sobre o papel crucial da deteção de licenças no OSS.
OPSWAT O SBOM suporta mais de 10 linguagens de programação, incluindo Java, JavaScript, Go, PHP e Python. Este amplo suporte garante uma vulnerability detection abrangente em vários ecossistemas de desenvolvimento de software.
Sanções por incumprimento
As organizações que não cumprem os padrões do PCI DSS, incluindo o requisito SBOM, podem incorrer em penalidades financeiras que variam de US$ 5.000 a US$ 100.000 por mês. Essas multas podem aumentar com o tempo se os problemas de conformidade não forem resolvidos.
Para além das penalizações financeiras, a não conformidade com o PCI DSS pode levar a desafios legais e operacionais significativos. As consequências legais podem incluir acções judiciais, custos de defesa e acordos substanciais. Além disso, a não conformidade pode desencadear auditorias federais por agências como a Federal Trade Commission (FTC), levando a penalidades adicionais.
Próximos passos para a conformidade com o PCI DSS 4.0
A integração do SBOM na estrutura do PCI DSS 4.0 significa uma mudança fundamental para uma cadeia de fornecimento de software mais segura. Ao utilizar ferramentas avançadas como OPSWAT SBOM, as organizações podem gerir eficazmente os riscos de código aberto, melhorar a conformidade e proteger-se contra violações de dados dispendiosas.
A utilização de SBOMs já não é uma opção, mas uma necessidade. Ao tomar medidas pró-activas para compreender e abordar as dependências de software, as organizações podem construir uma base de segurança robusta que proteja as suas operações e crie confiança nos clientes.
Melhore a sua segurança
Postura com OPSWAT
Comece agora a gerir as dependências de
de código aberto.
