Não seja o elo mais fraco: o papel dos desenvolvedores na segurança da cadeia de fornecimento de software

Todas as mensagens

Quando três agências governamentais dos EUA se reúnem para “encorajar fortemente” os desenvolvedores a adotarem certas práticas, você deve prestar atenção. A CISA, a NSA e a ODNI, em reconhecimento da ameaça dos hackers cibernéticos e na sequência do ataque à SolarWinds, anunciaram que publicarão em conjunto uma coleção de recomendações para proteger a cadeia de fornecimento de software para evitar tais vulnerabilidades no futuro. . O anúncio deixou claro que o objetivo do documento é incentivar os desenvolvedores a adotarem as melhores práticas, afirmando que “Esses princípios incluem planejamento de requisitos de segurança, projeto de arquitetura de software a partir de uma perspectiva de segurança, adição de recursos de segurança e manutenção da segurança do software e da infraestrutura subjacente."

Este guia está organizado em uma série de três partes e será lançado coincidindo com o ciclo de vida da cadeia de fornecimento de software. Parte 1 da série, que se concentra em recomendações para desenvolvedores de software, foi lançado em agosto de 2022. As duas partes restantes serão lançadas em um futuro próximo: a parte 2 se concentrará nos fornecedores de software e a parte 3 se concentrará nos clientes que recebem o software. O objetivo final é que esta série ajude a promover a comunicação entre estas três principais partes interessadas e entre os profissionais de segurança cibernética para facilitar o aumento da resiliência e melhorar globalmente. segurança da cadeia de suprimentos de software.

Embora nem sempre seja claro de quem é a responsabilidade de garantir a segurança do software, independentemente de quem possa assumir a responsabilidade geral em sua organização específica, isso novo guia deixa bem claro que todos os desenvolvedores devem se familiarizar com essas novas práticas recomendadas e que todos eles têm um papel na segurança da cadeia de fornecimento de software. Ou, se me permitem ser mais direto: Desenvolvedores, vocês desempenham um papel fundamental na segurança da cadeia de fornecimento de software da sua organização! E por esse motivo, pensamos que seria útil ler um resumo (relativamente) curto desta primeira parte do guia, só para você. Aí vem. 

O guia em poucas palavras:

Entre as extensas listas de ameaças potenciais mencionadas neste guia prático para desenvolvedores, existem algumas vulnerabilidades importantes que foram identificadas e você deve certificar-se de resolvê-las e se preparar para elas:

  • Recursos que não foram devidamente documentados ou que implementam funcionalidades arriscadas
  • Mudanças ocultas nas principais suposições de segurança entre o momento da avaliação de segurança e a entrega do código 
  • Mudanças corporativas para as partes interessadas da cadeia de suprimentos
  • Codificação abaixo do padrão ou práticas de segurança

Todos os gerentes de gestão, finanças e programas têm a responsabilidade de abordar a segurança da cadeia de fornecimento de software, mas a integridade do segurança da cadeia de suprimentos de software muitas vezes depende da vigilância dos desenvolvedores de software e da conscientização de todas as partes interessadas da cadeia de abastecimento. A Parte 1 do guia centra-se no papel dos promotores e nas ameaças inerentes a cada fase do processo de desenvolvimento, e oferece recomendações para estratégias de mitigação que devem tornar-se práticas padrão. 

Etapa 1: critérios e gerenciamento seguros do produto

O desenvolvimento seguro começa com o reconhecimento da importância da segurança da cadeia de fornecimento de software por todas as principais partes interessadas nas equipes de produto e desenvolvimento. Os cenários de ameaça são comuns e podem ser claros para todos; o desafio é colocar todos na mesma página no que diz respeito às políticas de mitigação que foram decididas. Estas políticas devem abranger todo o processo: o design e a arquitetura, a modelagem de ameaças, a codificação, os planos de testes de segurança, os critérios de lançamento e como gerenciar vulnerabilidades no futuro. Parte disso também inclui avaliar as capacidades das equipes e garantir que elas tenham sido devidamente treinadas para suas tarefas e, em seguida, definir práticas de documentação e revisões periódicas de segurança e avaliações de ameaças.

Etapa 2: Desenvolvimento seguro de código

Quando se trata de desenvolvimento de código, as práticas corretas para codificação segura já foram definidas no SSDF. Esta é a razão pela qual, na medida em que a linguagem de programação não tenha sido predeterminada, as considerações de segurança também deverão fazer parte dessa decisão. O guia fornece orientação útil para desenvolvedores, abordando uma ampla gama de cenários, como a inserção de código-fonte prejudicial por “insiders” (por exemplo, desenvolvedores), software de código aberto e as melhores práticas para lidar com isso. Como criar um ambiente seguro para codificação (incluindo configurações de construção seguras e ferramentas de software de terceiros) e posteriormente testar a segurança de um produto integrado. Como é provável que as vulnerabilidades também surjam após a entrega, também existem recomendações para lidar com as vulnerabilidades relatadas e garantir que futuras extensões de software externo não comprometam a integridade da segurança do produto.

Etapa 3: fortalecer o ambiente de construção

Depois que o código for desenvolvido com segurança, a segurança da cadeia de fornecimento de software exige que o ambiente de construção seja reforçado de acordo com os mesmos padrões do próprio software. Comprometer o sistema de construção é uma forma atraente de se infiltrar no código, pois ocorre em um estágio do processo de desenvolvimento que é naturalmente menos examinado pelos desenvolvedores. 

Etapa 4: entrega de código

A última fraqueza abordada pelo guia abrange o estágio final da cadeia de fornecimento de software – entrega de código. Mesmo quando o código foi devidamente protegido até este ponto, ainda existem duas vulnerabilidades principais na cadeia de abastecimento que devem ser mitigadas. A primeira é a validação final do pacote, que pode ser explorada, por exemplo, expondo inadvertidamente metadados, credenciais de desenvolvedor ou inventário de código aberto. A outra etapa que é frequentemente testada quanto a pontos fracos é o sistema de distribuição, que pode ser comprometido por um ataque man-in-the-middle que pode assumir uma ou mais etapas da entrega.

Ao aplicar estas práticas de mitigação de riscos ao nível do desenvolvimento de software, os fornecedores de software podem evitar pontos fracos que podem levar, por exemplo, à infiltração de atualizações, manipulação de assinatura de código e “surpresas” escondidas no código-fonte aberto.

Não existe almoço grátis: o custo oculto do software de terceiros

Via GIPHY

Uma chave contribuidor para a velocidade do desenvolvedor tornou-se a capacidade de incorporar efetivamente software de terceiros. Isto tornou possível que os desenvolvedores se concentrassem, por exemplo, na inovação ou na função, ao mesmo tempo que utilizavam componentes prontos para escalabilidade ou interfaces. Esse aumento no uso de software de terceiros criou um grande desafio para a segurança da cadeia de fornecimento de software. Além de realizar uma avaliação desse código de acordo com os mesmos padrões usados ​​para avaliar o seu próprio, o guia sugere verificar os binários em busca de vulnerabilidades e avaliar os riscos resultantes. Os resultados desta avaliação devem levar em consideração a decisão de usar ou não um componente de software específico. A seleção de um componente de software também deve levar em conta a sua origem; incorporar componentes de terceiros em seu código-fonte é o início de um longo relacionamento e você deve se esforçar para trabalhar com parceiros em quem possa confiar. Propriedade do código, práticas de codificação e políticas de gerenciamento de versão são apenas alguns pontos a serem considerados ao selecionar uma fonte confiável. Pense em todas as atualizações, lançamentos e trabalhos de manutenção futuros para cada componente à medida que novas ameaças são descobertas. O desafio será monitorar todas as alterações de terceiros, avaliar vulnerabilidades e responder adequadamente, às vezes sob forte pressão de tempo. 

Aumente a segurança da sua cadeia de suprimentos de software com um SBOM

Uma prática fundamental para garantir a integridade a longo prazo da sua cadeia de fornecimento de software é manter um Lista de Materiais de Software (SBOM). O SBOM é um inventário detalhado dos componentes de software que compõem uma determinada solução. 

Isso economizará tempo e esforço e, o mais importante, reduzirá sua exposição a ameaças contínuas. Cada componente de software incorporado ao seu produto deve vir com seu próprio SBOM, que deve ser validado e mesclado em um único SBOM “mestre” para o produto. Se você pretende incorporar componentes que não vêm com um SBOM, você precisará conduzir sua própria análise usando ferramentas de análise de composição de software (SCA).

Quanto mais preciso e descritivo for o SBOM, mais fácil será mantê-lo e consultá-lo. Dada a velocidade vertiginosa com que os componentes de software são atualizados, um SBOM bem estruturado pagará dividendos quando chegar a hora de rastrear e registrar cada atualização, patch ou lançamento. Ainda mais importante, uma vez descoberta uma ameaça à segurança, cada momento é crítico. Lembrete: O segurança da sua cadeia de fornecimento de software sempre será tão forte quanto o seu elo mais fraco. Quando houver dezenas de componentes de software em risco, você ficará grato por um SBOM que tenha todas as respostas.

Para um fluxo de trabalho eficiente, um SBOM útil deve incluir pelo menos estes três componentes:

  1. Campos de dados – Estes são os descritores dos componentes que você implementou. Ser capaz de identificar facilmente quais componentes foram usados, mesmo muito depois de o desenvolvimento ter sido concluído, ajuda a monitorá-los com eficácia em busca de vulnerabilidades.  
  2. Suporte de automação – O monitoramento automático do SBOM exige que eles também sejam identificados em um dos formatos legíveis por máquina aceitos. 
  3. Práticas e promessas – Gerenciar um SBOM requer um entendimento comum das práticas de manutenção, como frequência de versões, dependências, incógnitas conhecidas, distribuição e entrega, controle de acesso e como acomodar erros.

Compartilhar o SBOM entre as partes interessadas de um produto específico (o desenvolvedor de software, o fornecedor de software e o cliente) ajuda a promover a transparência e o alinhamento, aumentando a capacidade de uma cadeia de fornecimento de software de defender o produto contra ameaças à segurança. Deve-se observar que, dadas todas as partes móveis de uma cadeia de fornecimento de software, a manutenção consistente de tal SBOM — que pode ser facilmente referenciado, monitorado e mantido — é um desafio complexo. 

Palavras finais: Como você pode levar a segurança da sua cadeia de suprimentos de software para o próximo nível?

À medida que a segurança da cadeia de fornecimento de software se torna cada vez mais crucial, as organizações são repetidamente desafiadas a construir uma confiança transparente no software que fornecem ou utilizam. Como se espera que a adoção do SBOM como prática recomendada cresça, ter uma ferramenta que permita superar esse desafio é um passo fundamental para estabelecer a segurança da cadeia de suprimentos de software. É por isso que lançamos recentemente o primeiro centro de segurança baseado em evidências para produtos de software, permitindo que seus usuários construam confiança em seu software entre equipes e organizações. Esta plataforma fácil de usar ajudará as equipes de desenvolvimento a mitigar os riscos da cadeia de fornecimento de software, tornando o SBOM acessível, fácil de usar e, o mais importante:tornar a segurança dos produtos de software transparente para clientes, compradores e equipes de segurança

Se você, como desenvolvedor de software, está preocupado com as ameaças à segurança da sua cadeia de fornecimento de software, recomendamos que você experimente a plataforma; é de uso gratuito, sem compromisso. Ao implementar nosso fluxo de trabalho, você poderá compartilhar seus SBOMs em toda a sua cadeia de suprimentos.  

Bandeira

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.