No dia 22 de março o NIST lançou a versão final do SSDF 1.1 (Secure software development framework).
A estrutura foi publicada inicialmente em setembro de 2021 como uma versão preliminar. Todas as práticas e tarefas de alto nível permanecem as mesmas, com muitas diferenças centradas nos vários exemplos fornecidos.
Qual é a estrutura NIST SP 800-218? O SSDF consolida recomendações de práticas recomendadas de longa data para o desenvolvimento seguro de software. Sua abordagem personalizável e independente do setor foi criada para facilitar as comunicações entre departamentos (e produtores/adquirentes) para ajudar a definir objetivos estratégicos e avaliar as lacunas atuais.
O NIST recomenda equilibrar o risco com o custo, a viabilidade e a aplicabilidade ao decidir quais práticas implementar. A automação é um recurso fundamental a ser considerado com o objetivo desejado de automatizar o máximo possível de verificações e processos que promovem a segurança do software.
Diferenças entre as versões final e preliminar:
Verificação de integridade – Ao discutir vulnerabilidades, há mais foco na verificação de integridade ao analisar seu código e bibliotecas/produtos adquiridos de fontes externas.
Atestados imutáveis - A responsabilidade pela implementação das práticas pode ser distribuída entre diferentes organizações, especialmente quando se considera a complexidade das cadeias de fornecimento de software. A visibilidade cai significativamente quanto mais a montante ou a jusante você avança na cadeia. É por isso que o NIST recomenda codificar a responsabilidade partilhada que envolve tanto os fornecedores como os consumidores de uma plataforma/serviço num contrato ou acordo. Deve ficar claro qual parte é responsável por cada prática e tarefa e como cada fornecedor atestará a sua conformidade com o acordo. O axioma “confiar, mas verificar” é válido aqui – atestados imutáveis que podem ser facilmente partilhados entre produtores e adquirentes de software são fundamentais para aumentar a confiança de todas as partes interessadas na cadeia de fornecimento de software.
Envolvimento da comunidade de código aberto – O NIST afirma que o trabalho futuro provavelmente assumirá a forma de casos de uso específicos e que pretende colaborar com a comunidade de código aberto. Considerando que a maioria dos produtos de código comercial em uso atualmente inclui elementos significativos de código-fonte aberto, é natural incluir a comunidade de código-fonte aberto no planejamento e implementação da segurança do ciclo de vida do software.
Pontuações de gravidade de vulnerabilidade como um KRI (indicador chave de risco) – Outra mudança que está entrando em vigor são as pontuações de gravidade como um indicador-chave. Sabendo que grande parte do pessoal de segurança cibernética sofre de fadiga de alerta, faz sentido que cada organização defina a escala de pontuação de vulnerabilidade certa para ela e o tratamento específico que cada pontuação merece.
Menos acesso humano, mais automação – O NIST incentiva a minimização do acesso humano direto aos sistemas de cadeia de ferramentas, como serviços de construção. Quanto mais pessoas tiverem acesso, mais erros poderão acontecer. Isto vai, mais uma vez, na mesma linha da recomendação para uma maior automatização.
SBOMs com integridade – Ao discutir a SBOM (lista de materiais de software), o NIST recomenda empregar forte proteção à integridade do artefato, bem como fornecer uma maneira para os destinatários verificarem essa integridade. Os destinatários podem ser pessoas de dentro e de fora da organização, por isso faz sentido empregar um sistema de terceiros para compartilhar SBOMs seguros.
Integridade binária versus código-fonte – Se a integridade ou procedência dos binários adquiridos não puder ser confirmada, sugere-se construir esses binários novamente a partir do código-fonte. Isso pressupõe que você possa verificar a integridade e a procedência do código-fonte. É responsabilidade de todos os elos da cadeia de fornecimento de software fornecer provas verificáveis de integridade, por meio de assinaturas digitais ou outros mecanismos como um SBOM.
Resumo
No geral, o NIST considera que “as práticas, tarefas e exemplos de implementação do SSDF representam um ponto de partida a considerar. Eles foram feitos para serem alterados e personalizados e para evoluir com o tempo.”
O SSDF não é uma lista de verificação que você deve seguir, mas fornece orientação para planejar e implementar uma abordagem baseada em riscos para proteger o desenvolvimento de software.
Ao contrário das regulamentações baseadas na lei dos EUA, o SSDF será baseado nos negócios – o governo aproveitará o seu poder de compra para fazer com que o mercado adira a este novo quadro de melhores práticas. Se você não conseguir demonstrar adesão à estrutura, não será considerado para contratos governamentais. É provável que vejamos um efeito cascata, onde as organizações que consideram candidatar-se a contratos governamentais exigirão que todos os seus vendedores e fornecedores também cumpram, e assim por diante, ao longo da cadeia de fornecimento de software.
Para saber mais sobre as novas regulamentações e o SSDF, confira nosso webinar sobre “Desmistificando as novas regulamentações de segurança cibernética em 2022”.
Este conteúdo é oferecido a você pela Scribe Security, um fornecedor líder de soluções de segurança de cadeia de suprimentos de software ponta a ponta – fornecendo segurança de última geração para artefatos de código e processos de desenvolvimento e entrega de código em todas as cadeias de suprimentos de software. Saiba mais.
Artigos Relacionados
