0
0
A Open Source Security Foundation (OpenSSF) lançou a v1.0 de Níveis da Cadeia de Suprimentos para Artefatos de Software (SLSA) com disposições específicas para a cadeia de suprimentos de software.
As equipes modernas de desenvolvimento de aplicativos reutilizam regularmente o código de outros aplicativos e extraem componentes de código e ferramentas de desenvolvedor de inúmeras fontes. Uma pesquisa da Snyk e da Linux Foundation no ano passado descobriu que 41% das organizações não tinham alta confiança na segurança de software de código aberto. Com os ataques à cadeia de suprimentos representando uma ameaça sempre presente e em constante evolução, as equipes de desenvolvimento de software e as equipes de segurança agora reconhecem que os componentes e estruturas de código aberto precisam ser protegidos.
O SLSA é um projeto de padrões de segurança da cadeia de suprimentos voltado para a comunidade, apoiado por grandes empresas de tecnologia, como Google, Intel, Microsoft, VMware e IBM. A SLSA se concentra em aumentar o rigor da segurança dentro do processo de desenvolvimento de software. Os desenvolvedores podem seguir as diretrizes da SLSA para tornar sua cadeia de suprimentos de software mais segura, e as empresas podem usar a SLSA para tomar decisões sobre se devem confiar em um pacote de software, de acordo com a Open Source Security Foundation.
O SLSA fornece um vocabulário comum para falar sobre segurança da cadeia de suprimentos de software; uma maneira de os desenvolvedores avaliarem as dependências upstream, avaliando a confiabilidade do código-fonte, compilações e imagens de contêiner usadas no aplicativo; uma lista de verificação de segurança acionável; e uma maneira de medir a conformidade com o próximo Secure Software Development Framework (SSDF).
A versão SLSA v1.0 divide os requisitos de nível do SLSA em várias faixas, cada uma medindo um aspecto particular da segurança da cadeia de suprimentos de software. As novas faixas ajudarão os usuários a entender melhor e mitigar os riscos associados às cadeias de fornecimento de software e, finalmente, desenvolver, demonstrar e usar software mais seguro e confiável, diz o OpenSSF. O SLSA v1.0 também fornece orientações mais explícitas sobre como verificar a proveniência, além de fazer as alterações correspondentes na especificação e no formato de proveniência.
Os Níveis de Faixa de Compilação 1-3, que correspondem aproximadamente aos Níveis 1-3 em versões anteriores do SLSA, descrevem os níveis de proteção contra adulteração durante ou após a compilação do software. Os requisitos de Build Track refletem as tarefas necessárias: produzir artefatos, verificar sistemas de compilação e verificar artefatos. As versões futuras da estrutura se basearão em requisitos para abordar outros aspectos do ciclo de vida de entrega de software.
A compilação L1 indica a proveniência, mostrando como o pacote foi construído; Build L2 indica a proveniência assinada, gerada por um serviço de compilação hospedado; e Build L3 indica que o serviço de compilação foi protegido.
Quanto maior o nível, maior a confiança de que um pacote pode ser rastreado até sua origem e não foi adulterado, disse a OpenSSF.
A segurança da cadeia de suprimentos de software é um componente-chave da Estratégia Nacional de Segurança Cibernética dos EUA do governo Biden, pois pressiona os provedores de software a assumir maior responsabilidade pela segurança de seus produtos. E recentemente, 10 agências governamentais de sete países (Austrália, Canadá, Alemanha, Holanda, Nova Zelândia, Reino Unido e Estados Unidos) lançaram novas diretrizes, “Mudando o Equilíbrio do Risco de Segurança Cibernética: Princípios e Abordagens para Segurança por Design e Padrão“, para instar os desenvolvedores de software a tomar as medidas necessárias para garantir que estejam enviando produtos que sejam seguros por design e por padrão. Isso significa remover senhas padrão, escrever em linguagens de programação mais seguras e estabelecer programas de divulgação de vulnerabilidades para relatar falhas.
Como parte da segurança da cadeia de suprimentos de software, as equipes de segurança devem se envolver com os desenvolvedores para educá-los sobre práticas de codificação segura e adaptar o treinamento de conscientização de segurança para incluir os riscos que cercam o ciclo de vida de desenvolvimento de software.
FONTE: DARK READING