Garantia Contínua: Uma Prática Integral para Segurança da Cadeia de Fornecimento de Software

Este é o segundo de uma série de artigos que examinam as novas diretrizes NIST SP 800-218. O primeiro artigo pode ser encontrado aqui.

Garantia Contínua:
Uma prática integral para segurança da cadeia de suprimentos de software

Conforme discutimos em nosso artigo anterior, as diretrizes estabelecidas pelo Instituto Nacional de Padrões e Tecnologia dos EUA (NIST) alterarão drasticamente a forma como os produtos e serviços de software são fornecidos ao governo dos Estados Unidos. 

Especificamente, NISTSP 800-218 estabelece um conjunto de práticas de desenvolvimento de software seguro de alto nível que devem ser integradas em cada ciclo de vida de desenvolvimento de software (SDLC). Espera-se que a incorporação destas práticas em toda a cadeia de fornecimento de software promova produtos e serviços mais seguros para entrega não apenas ao governo dos EUA, mas, em última análise, em todas as indústrias e em todo o mundo. 

Neste artigo, analisamos o papel crítico da Garantia Contínua (CA) no atendimento a esses novos requisitos. 

Visão geral: o que é garantia contínua e como funciona? 

CA é um conceito e um conjunto de soluções em desenvolvimento, complementares aos já familiares conceitos de integração, desenvolvimento e teste contínuos da disciplina DevOps. A CA coleta granularmente evidências sobre todos os eventos no ciclo de vida de desenvolvimento, incluindo a construção e implantação do produto, que podem afetar a segurança do eventual produto de software. É um meio para os consumidores de software (como usuários, compradores e outras partes interessadas no risco) controlarem o risco dos produtos que utilizam. 

Hoje, as empresas aplicam uma infinidade de ferramentas de segurança para melhorar a segurança dos produtos de software que desenvolvem. No entanto, raramente utilizam uma política global para definir o padrão para a utilização consistente destas ferramentas. Além disso, se os consumidores de produtos de software forem de outra organização, eles não terão nenhuma das informações ou ferramentas necessárias para definir o nível de risco. Em suma, este é o ponto cego da cadeia de fornecimento de software que a CA pretende dissipar. 

O resultado imediato da CA é um meio de garantir que os produtos de software não foram adulterados e que testes críticos relacionados à segurança foram realizados durante o desenvolvimento, mas há mais a se ganhar com isso.

Para impedir a adulteração por invasores ou o encobrimento de componentes ocultos de origem duvidosa, como de países proibidos, a CA transforma as evidências coletadas em um atestado resistente à falsificação, assinando as informações criptograficamente e armazenando-as em um armazenamento imutável em um ambiente seguro e isolado. 

Ao tornar as evidências coletadas legíveis por máquina, um mecanismo de política pode validar continuamente as normas ou regras definidas pelas partes interessadas no risco para cada versão ou atualização do produto. Dessa forma, as partes interessadas podem ter certeza da conformidade de um produto com seus padrões de segurança. 

Conceitualmente, o uso da metodologia CA também melhora a qualidade do produto. Ao controlar o padrão básico para revisão de código e testes de segurança com uma política central para os pipelines de um produto específico, seriam eliminadas inconsistências e alterações ad hoc em processos ordenados.

Por que Contínuo?

As configurações de segurança no processo de desenvolvimento não são novidade. Por exemplo, você já deve ter estabelecido que nenhum binário irá para produção sem verificação de vulnerabilidades. 

Hoje, os ciclos de entrega de software estão cada vez mais curtos. Como resultado, os cantos podem ser cortados. A revisão do código pode ser ignorada ou os testes de segurança ou procedimentos importantes podem não ser executados. Além disso, novos CVEs e explorações são relatados o tempo todo e novas versões de componentes são publicadas constantemente. 

Todos esses fatores combinados exigem que testemos continuamente os componentes em relação ao padrão de segurança definido para verificar se os processos utilizados ainda estão em conformidade com a política de segurança. 

As políticas de segurança são determinadas pelo detentor do risco. Aqui estão alguns exemplos de regras de política que podem ser empregadas: 

• Permitir o uso de pacotes de código aberto somente de uma lista aprovada
• Exigir dois revisores para cada solicitação pull.
• Verifique se todos os componentes proprietários no artefato final podem ser rastreados até os repositórios de controle de origem.

Elevando o nível de segurança do software

Os ataques à cadeia de fornecimento de software alteram o comportamento esperado dos componentes de software. Hoje, esses ataques dependem da falta de capacidade tanto dos consumidores quanto dos produtores de software para verificar a integridade dos componentes do software. 

No entanto, ao assinar evidências de todas as partes do ciclo de vida de desenvolvimento — desde as dependências de código aberto até o produto final — e comparar continuamente essas evidências com o que é esperado, os invasores enfrentarão maiores dificuldades ao tentarem adulterar arquivos, ferramentas ou o comportamento esperado do seu pipeline de CI/CD.     

Coletando evidências: exemplos e recomendações

Aqui estão alguns exemplos de evidências que podem ser coletadas ao longo do SDLC:

E aqui estão os tipos de políticas que podem ser utilizadas, usando estas evidências:

O futuro da garantia contínua de código

Na Estrutura de Desenvolvimento Seguro de Software de fevereiro de 2022 (SSDF), o NIST sugere que a implementação de ferramentas de segurança em todo o processo de desenvolvimento deve depender significativamente da automação. A nossa abordagem à Garantia Contínua é consistente com esta recomendação. 

Mesmo que você tenha certeza de que todas as etapas e proteções de segurança foram configuradas corretamente, você ainda deve fornecer os meios para garantir aos clientes e fornecedores que sua política de segurança foi aplicada de forma consistente e contínua. Todas as partes interessadas, produtores de software (desenvolvedores ou fornecedores) e consumidores (usuários ou compradores) devem ser capazes de examinar e verificar contínua e automaticamente as evidências de cada elo da cadeia de fornecimento de software para garantir que seus próprios critérios de segurança sejam atendidos. 

A confiança na cadeia de fornecimento de software é baixa neste momento e esta é uma fonte constante de preocupação para todas as partes interessadas. Aumentar a visibilidade das medidas de segurança que foram implementadas e fornecer evidências de Garantia Contínua de Código são essenciais para reconstruir a confiança na cadeia de fornecimento de software e produzir produtos comprovadamente mais seguros.