Melhores práticas de segurança da cadeia de suprimentos de software

A cadeia de suprimentos de software refere-se a tudo e todos que estão conectados ao seu código de software de alguma forma durante todo o ciclo de vida de desenvolvimento. Cada software é composto de vários componentes. Além do código proprietário escrito do zero, o código também requer infraestrutura de software externa, serviços em nuvem e sistemas operacionais para funcionar corretamente. Os registros, repositórios, bases de código e até mesmo as pessoas que escreveram este software fazem parte da cadeia de fornecimento de software.

Cada nó nesta cadeia complexa é um ponto potencial de vulnerabilidade que pode afetar o desempenho e a segurança do seu software de algumas maneiras. A vulnerabilidade introduzida em qualquer ponto desta cadeia de dependência tem sérias ramificações a jusante. Isso ocorre porque a complexidade da cadeia de abastecimento de software mascara os riscos e torna difícil prever e identificar sem uma estrutura padronizada para proteger a cadeia de abastecimento. É por isso que é importante que os desenvolvedores e organizações de produtos aprenda o que é segurança da cadeia de suprimentos de software.

A segurança da cadeia de suprimentos de software refere-se ao conjunto de práticas padronizadas implementadas para proteger seu software contra vulnerabilidades potenciais em todo o ciclo de vida de desenvolvimento de software, desde o ponto de desenvolvimento do aplicativo até por meio de integração e implantação contínuas (pipeline de CI/CD).

É importante que as equipes de segurança entendam e sigam a lista de práticas recomendadas de segurança da cadeia de fornecimento de software para manter a cadeia de fornecimento de software de sua organização segura. Esta postagem detalha as melhores práticas da cadeia de suprimentos que você deve conhecer.

Melhores práticas para proteger sua cadeia de suprimentos de software

Esta seção faz referência às práticas padrão que os desenvolvedores e organizações de produtos precisam seguir para proteger sua cadeia de fornecimento de software. Você pode usar essas diretrizes como uma estrutura básica para descrever, avaliar e medir as práticas de segurança da sua organização nos diferentes estágios do ciclo de vida do software. Essas práticas recomendadas abrangem a fase de aquisição, desenvolvimento e implantação da cadeia de fornecimento de software para garantir a integridade do seu ambiente de desenvolvimento, código-fonte e produto final.

Adquira componentes bem protegidos

Incorporar componentes de terceiros ao software é uma prática padrão para desenvolvedores, pois permite que eles aproveitem os recursos de API existentes para fornecer as funcionalidades desejadas, em vez de criar do zero. Os componentes de terceiros podem estar na forma de software comercial proprietário ou de ferramentas gratuitas de código aberto. Ao adquirir qualquer um desses componentes, é importante considerar a segurança como um dos critérios mais importantes que o componente de software deve atender.

Para determinar a segurança de componentes de terceiros, pode ser necessário realizar análises de segurança avançadas, como análise de composição segura, análise de banco de dados de vulnerabilidades, avaliação de código-fonte e análise de avaliação de risco. O resultado dessas verificações ajudará a determinar se este componente é seguro e deve ser permitido para o seu produto

Além disso, os componentes selecionados precisam ser monitorados continuamente usando um serviço automatizado de rastreamento de vulnerabilidades para identificar vulnerabilidades o mais rápido possível e removê-las imediatamente.

Crie componentes de software seguros internamente, aderindo a práticas de codificação seguras

Embora os componentes de software externos incorporados ao seu software sejam importantes, a segurança e a integridade dos produtos de software também dependem das práticas de codificação seguras que você segue internamente.

Toda organização precisa de uma estrutura abrangente de ciclo de vida de desenvolvimento de software que incorpore práticas de codificação seguras para garantir que os artefatos criados estejam em conformidade com as diretrizes estipuladas.

Para começar, a integridade de seus produtos de software e dos artefatos que você constrói internamente depende da qualidade de sua equipe. Sua equipe de desenvolvimento deve incluir especialistas em desenvolvimento, garantia de qualidade, profissionais de segurança cibernética e engenheiros de construção com bom conhecimento das práticas de segurança padrão.

A equipe de gerenciamento de produtos também deve incluir arquitetos de segurança, gerentes de produtos e líderes de produtos que trabalhem para garantir a conformidade com políticas de desenvolvimento seguras. Algumas das estratégias básicas para garantir que você esteja criando artefatos de software seguros internamente incluem:

• Gerando documentos de design e arquitetura para cada artefato
• Criação de modelos de ameaças para produtos de software
• Definição e implementação de testes de segurança
• Definir critérios de lançamento específicos para avaliar o produto
• Estabelecer políticas de tratamento de vulnerabilidades para cada produto
• Documentar e publicar procedimentos de segurança para cada versão de software

 Use conjuntos de ferramentas de software seguros de terceiros e bibliotecas de compatibilidade

Muitos ambientes de desenvolvimento integrados (IDE) usados ​​no processo de desenvolvimento de software são independentes. Isso significa que eles permitem que você execute várias etapas do processo de desenvolvimento, como codificação, compilação, empacotamento e depuração de código – tudo na mesma ferramenta. Alguns IDEs também possuem ferramentas para conectar uma fonte a um repositório externo. IDEs com esta função suportam múltiplas linguagens de compilador. Além dessas funções principais, os desenvolvedores podem estender os recursos do IDE que usam com plug-ins. Esta é uma fonte potencial de vulnerabilidade para o ambiente de desenvolvimento local, devido à complexidade de fontes não confiáveis ​​como esta.

Para manter seu ambiente de desenvolvimento seguro, todos os IDEs e plugins a serem usados ​​dentro do ambiente devem ser auditados e pré-aprovados após serem verificados em busca de vulnerabilidades e validados.

Além dos plug-ins que ampliam os recursos do seu ambiente de construção, outra categoria de ferramentas de construção de terceiros que você pode precisar para verificar vulnerabilidades são as cadeias de ferramentas de software e bibliotecas de compatibilidade. Essas ferramentas de sistema operacional de terceiros são instaladas no ambiente de desenvolvimento para permitir o uso de utilitários e comandos específicos exclusivos desse sistema operacional. Por exemplo, um ambiente de desenvolvimento Windows pode exigir alguns comandos do sistema operacional exclusivos do sistema operacional Linux durante o processo de construção, a fim de fornecer compatibilidade entre os dois sistemas durante o processo de produção.

Da mesma forma, as bibliotecas de conversão de API também ajudam a criar um ambiente de codificação comum para dois sistemas operacionais diferentes. Essas cadeias de ferramentas de API são ferramentas comerciais e de código aberto e precisam ser acessadas em busca de vulnerabilidades antes de serem adotadas em seu ambiente de construção e usadas em seu projeto.

Mitigar a modificação ou exploração do código-fonte por pessoas internas

De acordo com a Agência de Segurança Cibernética e de Infraestrutura (CISA), um insider é qualquer pessoa com acesso autorizado ou conhecimento dos recursos de uma organização. Indivíduos que têm ou tiveram acesso às suas instalações, rede, equipamentos e sistemas podem potencialmente comprometer a integridade do seu produto de software, seja intencionalmente ou inconscientemente.

Como parte dos esforços para proteger seu software, você deve garantir que o processo de desenvolvimento tenha políticas em vigor para evitar a exposição intencional ou não intencional a códigos maliciosos em seu código de produção por pessoas internas, como pessoal comprometido, engenheiros mal treinados ou funcionários inativos. Algumas das medidas que você pode implementar para mitigar isso incluem:

• Processo de check-in de código-fonte balanceado e autenticado
• Verificação de segurança automatizada em busca de vulnerabilidades
• Treinamento seguro em desenvolvimento de software
• Fortalecendo o ambiente de desenvolvimento
• Priorizando revisões de código

Armazene código ou executáveis ​​e revise todas as alterações antes da aprovação

O controle de versão é uma das práticas padrão que pode ajudar a manter a integridade do seu software. Como parte do seu processo de integração e implantação contínua (pipeline de CI/CD), você precisará manter um repositório para armazenar seu código e executáveis. Isso fornece um histórico de funcionamento do seu código para que você possa rastrear facilmente o que entrou na pilha de desenvolvimento até aquele ponto.

Você também precisará de um sistema de aprovação contínua para revisar todas as alterações feitas em seu software antes de serem aprovadas. Isso é particularmente útil ao colaborar com outros desenvolvedores em equipes. A solução de problemas é mais fácil neste caso, pois você pode identificar facilmente as alterações à medida que são feitas e quem as está fazendo.

Não importa quão simples ou complexo seja o software que você está construindo, um sistema de controle de versão ou código-fonte facilita a visualização e o rastreamento de todas as alterações feitas em seu código, o rastreamento do histórico de versões quando necessário ou até mesmo a reversão para uma versão anterior do seu código. código quando necessário.

Criar e manter um SBOM para cada pacote de software criado

A Lista de Materiais de Software é uma documentação vital que detalha todos os componentes de terceiros incorporados ao seu produto de software. Um SBOM facilita a validação de todos os componentes aprovados de um software e a identificação fácil de quaisquer vulnerabilidades ou defeitos. Para cada pacote de software criado, você também deve criar e manter um SBOM para ele.

Uma lista de materiais de software pode ser preparada com base nas especificações definidas em formatos padrão, como as tags Software Package Data Exchange (SPDX), CycloneDX e Software Identification (SWID), conforme definido pelo Linux, OWASP e NIST, respectivamente.

Para cada produto de software que você cria, os fornecedores ou proprietários dos componentes de terceiros que você usa devem fornecer uma Lista de Materiais de Software abrangente. As entregas do seu projeto e os SBOMs fornecidos pelo fornecedor também podem ser validados usando uma ferramenta de análise de composição (SCA).

Mesmo que o fornecedor não forneça um SBOM, o SBOM gerado com a ferramenta de análise de composição de software ainda pode fornecer as informações necessárias para descrever os componentes de terceiros do software. O processo de gerando SBOMs deveria ser automatizado. Automação SBOM é vital porque os fornecedores e desenvolvedores terceirizados precisam gerar um novo SBOM cada vez que um software de terceiros é modificado, e fazer isso manualmente é impraticável. O SBOM atualizado descreverá qualquer aprimoramento ou alteração no código do componente e seu relacionamento com o produto de software.

Endureça o ambiente de construção

Uma das maneiras de garantir a integridade do seu software é proteger o ambiente de desenvolvimento contra possíveis vulnerabilidades. Isso inclui o ambiente de desenvolvedor individual e o ambiente geral de construção de produção.

Quer seu ambiente de construção esteja hospedado na nuvem ou no local, você precisa configurá-lo e implementar medidas para proteger o servidor e a rede, ao mesmo tempo que controla quem tem acesso a quê. Realizar a devida diligência na otimização e proteção do ambiente de construção dessa forma garantirá a integridade do seu código-fonte e do produto final.

Proteger o pipeline de construção envolve proteger todos os sistemas que você usa durante o processo de construção do seu produto. Isso inclui repositórios de código, servidores de assinatura, estações de trabalho de engenharia, servidores de implantação e assim por diante. Algumas das medidas que você pode implementar para proteger sua infraestrutura de pipeline de construção incluem:

Sistemas de bloqueio

Para proteger seus sistemas, você deve limitar as operações do sistema às funções específicas que o sistema deve executar. Por exemplo, seu sistema de compilação deve ser usado apenas para operações de compilação e nada mais.

Limite atividades de rede externas e fora da LAN

As atividades de rede de entrada e saída podem expor seu sistema a ataques. Você deve bloquear todas as atividades externas e fora da LAN e limitar as conexões externas aos URLs necessários.

Monitore os sistemas quanto a vazamentos de dados

Para garantir a integridade do código-fonte do seu produto, você deve configurar suas defesas de segurança cibernética para proteger seu repositório, estação de trabalho e outras partes do seu ambiente de construção contra exfiltração e infiltração de dados. Isso envolve bloquear todos os comportamentos maliciosos, isolar aplicativos e configurar sistemas de detecção para detectar qualquer intrusão assim que ocorrer.

Configure seu pipeline de controle de versão

Seu pipeline de código deve ser controlado por versão. Ao fazer quaisquer alterações em seu produto, as atualizações devem ser feitas no código de configuração e não nos sistemas reais.

Autenticação multifatores

Cada sistema que faz parte do seu ambiente de construção deve ser configurado com autenticação multifator sempre que possível. Medidas de segurança adicionais, como acesso baseado em funções, privilégios mínimos e assim por diante, também devem ser implementadas. A diretriz do NIST também recomenda um sistema de autorização dupla para todos os sistemas críticos ou confidenciais em seu ambiente de construção.

Segrege sua rede de engenharia

Seu sistema de compilação só deve ser acessado por meio de uma rede de engenharia isolada, diferente do restante da rede da sua organização. Quando possível, a rede de engenharia deverá estar offline.

Analise cada vulnerabilidade para reunir informações suficientes para planejar sua correção

Ao desenvolver software, devem ser implementadas medidas para garantir que o seu produto e todos os seus componentes estejam livres de vulnerabilidades conhecidas de alto risco. Da mesma forma, quando novas vulnerabilidades são descobertas ou relatadas por um cliente, você deve responder imediatamente ao incidente. Em alguns casos, isso exigirá que você atualize seu sistema para mitigar os riscos associados à vulnerabilidade recém-descoberta.

Os fornecedores de software devem ter um processo em vigor para aceitar atualizações ou relatórios sobre possíveis vulnerabilidades ou defeitos em seus produtos, sejam de pesquisadores terceirizados ou de clientes. Você também precisa ter um sistema automatizado que notifique sobre atualizações de vulnerabilidades anunciadas por organizações confiáveis, como a Agência de Segurança Cibernética e de Infraestrutura (CISA).

Toda organização precisa de uma política interna de gerenciamento de vulnerabilidades que esteja em conformidade com as diretrizes padrão. Alertas sobre ameaças de alto risco devem ser avaliados com base na relação entre o seu produto e seus componentes que podem ter sido afetados pela vulnerabilidade relatada. Sua equipe de engenharia também deve ter um sistema abrangente para revisar, diagnosticar e possivelmente resolver problemas

Manutenção de componentes

Um produto de software e seus componentes nunca são estáticos. Você deve ter em mente que componentes de terceiros integrados em seus produtos podem ser modificados ou atualizados periodicamente pelo fornecedor. Você deve monitorar essas modificações especialmente quando elas estão relacionadas a vulnerabilidades e exposições comuns (CVEs).

Uma grande parte da manutenção de seus componentes de software é monitorar mecanismos padrão de relatórios de CVE e outros canais de suporte para determinar se vulnerabilidades recentemente identificadas em um componente de terceiros incorporado em seu produto afetam a integridade de seus próprios sistemas e tomar as ações apropriadas para mitigar os riscos ( caso existam).

Ao selecionar componentes de terceiros a serem incluídos em seu produto, você deve verificar o contrato para garantir que o proprietário do componente tenha políticas sobre como notificar as organizações do produto sobre atualizações em seus sistemas, a presença de vulnerabilidades e o prazo para vulnerabilidade. resolução, bem como quaisquer ações que você possa precisar executar para garantir a segurança ideal.