- Definição de segurança da cadeia de suprimentos de software
- Ataques às cadeias de fornecimento de software: por que são tão comuns?
- O SSDF (NIST 800-218) foi finalizado e está em vigor
- SLSA é uma estrutura que você deve cumprir
- Como proteger sua cadeia de suprimentos de software?
- Validar a integridade do software é um desafio
- Garantia de código em todo o SDLC
- Segurança da cadeia de suprimentos de software explicada
- Automatizando a avaliação de conformidade com SLSA
- Scribe Security - um novo padrão de segurança da cadeia de suprimentos de software
- Como o escriba pode ajudar?
O que é segurança da cadeia de suprimentos de software?
A cadeia de fornecimento de software abrange tudo o que influencia ou desempenha um papel em um produto ou aplicativo durante todo o seu ciclo de vida de desenvolvimento de software (SDLC).
Nos últimos anos, os ataques à cadeia de fornecimento de software estão a tornar-se mais prevalecentes e mais sofisticados. Em seu relatório de 2022, Gartner afirma: “Antecipe a expansão contínua da superfície de ataque empresarial e aumente o investimento em processos e ferramentas para detecção e remediação de ameaças de identidade e integridade da cadeia de suprimentos digital.”
É mais importante do que nunca proteger todos os componentes, atividades e práticas SDLC envolvidas na criação e implantação de software. As equipes de desenvolvimento e os fornecedores de software devem garantir que utilizam apenas componentes de código livres de vulnerabilidades conhecidas e encontrar maneiras de validar a integridade de sua construção, verificando se há adulterações não autorizadas.
- Definição de segurança da cadeia de suprimentos de software
- Ataques às cadeias de fornecimento de software: por que são tão comuns?
- O SSDF (NIST 800-218) foi finalizado e está em vigor
- SLSA é uma estrutura que você deve cumprir
- Como proteger sua cadeia de suprimentos de software?
- Validar a integridade do software é um desafio
- Garantia de código em todo o SDLC
- Segurança da cadeia de suprimentos de software explicada
- Automatizando a avaliação de conformidade com SLSA
- Scribe Security - um novo padrão de segurança da cadeia de suprimentos de software
- Como o escriba pode ajudar?
Definição de segurança da cadeia de suprimentos de software
A cadeia de suprimentos de software refere-se a tudo o que está envolvido no desenvolvimento de um aplicativo durante todo o ciclo de vida de desenvolvimento de software (SDLC). A criação e implantação de software exige a proteção das atividades, processos e componentes de sua cadeia de suprimentos. Há muitos fatores a serem considerados a esse respeito, incluindo código personalizado (componentes internos), dependências e bibliotecas de código aberto (componentes de terceiros), ferramentas e infraestrutura DevOps que compõem o processo de CI/CD e, finalmente, desenvolvedores e DevOps equipes.
É responsabilidade das organizações realizar essas atividades de segurança e fornecer provas de seus esforços de segurança aos consumidores.
Ataques às cadeias de fornecimento de software: por que são tão comuns?
Os pipelines de software modernos são ambientes automatizados que dependem de uma variedade de ferramentas para integração e entrega contínuas. Um projeto de software pode acabar incluindo milhares de dependências de código aberto.
Atores maliciosos podem fazer com que bibliotecas não autorizadas sejam legítimas, explorando “falhas lógicas” em gerenciadores de pacotes de código aberto. Por exemplo, pacotes com malware podem ser atribuídos a mantenedores confiáveis sem o seu conhecimento. Essa confiança equivocada pode introduzir vulnerabilidades problemáticas e ocultas em seu código. Essas vulnerabilidades podem fornecer aos invasores acesso a dados confidenciais ou permitir que plantem malware e sistemas de controle em toda a cadeia de suprimentos.
O ambiente de desenvolvimento moderno tem suas próprias vulnerabilidades, e uma variedade de ataques à cadeia de suprimentos de software visaram o pipeline de CI/CD para inserir código malicioso em algum ponto do processo de desenvolvimento. Também aqui, uma suposição de confiança zero é a abordagem adequada para ganhar confiança no produto de software final – verificar, verificar e validar cada etapa da cadeia de desenvolvimento interna.
Os pipelines de CI/CD atuais carecem de visibilidade e controles para proteger adequadamente o processo de desenvolvimento de software. Eles também têm dificuldade para detectar adulterações de código, tornando esse vetor de ataque ainda mais atraente.
O SSDF (NIST 800-218) foi finalizado e está em vigor
A estrutura SSDF (NIST 800-218) exige que os fornecedores implementem práticas de segurança que abranjam o Ciclo de Vida de Desenvolvimento de Software (SDLC). Promove transparência e medidas resistentes a adulterações, num esforço para reduzir vulnerabilidades de segurança e interferências maliciosas.
Especificamente, contém diretrizes para uma abordagem baseada em evidências para proteger o próprio software contra adulteração.
O SSDF tem quatro partes principais:
01 /
Preparar a Organização (PO):
Certifique-se de que as pessoas estejam preparadas e que os processos e a tecnologia estejam em vigor para realizar o desenvolvimento seguro de software no nível da organização e, em alguns casos, para grupos ou projetos de desenvolvimento individuais.
02 /
Proteja o Software (PS):
Proteja todos os componentes de software contra qualquer acesso não autorizado ou adulteração.
03 /
Produza software bem protegido (PW):
Produza software bem protegido com vulnerabilidades de segurança mínimas em seus lançamentos.
04 /
Responder a vulnerabilidades (RV):
Identifique vulnerabilidades residuais em versões de software, responda adequadamente para resolver essas vulnerabilidades e evite que vulnerabilidades semelhantes ocorram no futuro.
Você não deve se referir ao SSDF como uma lista de verificação, mas sim como um guia para planejar e implementar uma abordagem baseada em riscos e em evidências para o desenvolvimento de software seguro.
As empresas devem tomar medidas para melhorar a sua postura de segurança, a fim de facilitar a conformidade com as mudanças regulamentares emergentes.
SLSA é uma estrutura que você deve cumprir
Uma estrutura originada no Google, chamada SLSA (Supply-chain Levels for Software Artifacts), fornece diretrizes sobre como alcançar quatro níveis de proteção da cadeia de suprimentos de software. A estrutura concentra-se na integridade da construção dos artefatos com a intenção de evitar adulterações e proteger os artefatos.
SLSA funciona desta maneira: você implementa listas de verificação de controles de segurança que deve implementar em seu pipeline, e esses controles estão em subdomínios como sistemas de controle de origem, sistemas de construção e dependências que você traz para seus projetos de software.
O SLSA estabelece quatro níveis de conformidade com o objetivo de chegar ao nível 4, que teria o maior valor de segurança, mas teria uma lista de requisitos mais longa.
A estrutura SLSA é baseada no conceito de proveniência. Um documento que representa uma “cadeia de evidências” que denota a origem dos artefatos e o processo de construção. À medida que você sobe nos níveis de SLSA, você precisa proteger melhor as próprias evidências.
Você deve considerar o SLSA como um padrão do setor, um nível de proteção e conformidade reconhecível e acordado ao qual você deve aderir.
Como proteger sua cadeia de suprimentos de software?
Contudo, gostaríamos de sublinhar três classes principais de controles de segurança:
1. Proteja a configuração do seu ciclo de vida de desenvolvimento de software
Credenciais comprometidas, controle insuficiente de permissões e sistemas de construção vulneráveis criam superfícies de ataque que afetam o produtor do software. Os invasores que exploram essas vulnerabilidades podem roubar segredos inseguros ou adulterar artefatos de software. Uma gama de soluções comerciais e de código aberto desta classe pode fornecer controles para mapear lacunas na postura de segurança e remediá-las.
2. Evite depender de dependências vulneráveis ou maliciosas
Invariavelmente, novas vulnerabilidades continuarão a ser descobertas em softwares comerciais e de código aberto. Os produtores de software devem mitigar este risco atualizando componentes vulneráveis de código aberto, verificando vulnerabilidades autoinfligidas em seu código proprietário e informando os consumidores de software sobre a lista de materiais de software (SBOM) e suas implicações associadas. Esses consumidores podem, por sua vez, agir de acordo.
Contas de projetos de código aberto sequestradas e pacotes maliciosos disfarçados de legítimos representam riscos adicionais, afetando principalmente o roubo de segredos de pipelines. A comunidade de código aberto e alguns fornecedores comerciais estão trabalhando para resolver isso por meio de reputação aprimorada e detecção de comportamento malicioso.
3. Valide a integridade e a construção segura dos artefatos de software
A segurança cibernética requer uma defesa profunda. Os ataques podem passar despercebidos ao usar a abordagem tradicional de redução da superfície de ataque, detecção e reputação para proteção. Além disso, hoje em dia, os consumidores de software a jusante têm pouca influência sobre estes controlos. No máximo, eles podem contar com auditorias de segurança pontuais, como varredura de código que fornece um instantâneo da vulnerabilidade, de fornecedores que não criam uma confiança real de que o artefato de software está bem protegido e protegido durante o ciclo de vida de desenvolvimento.
Uma nova e emergente classe de controles está agora disponível e atesta continuamente a integridade de cada construção de artefato de software e o processo de desenvolvimento seguro. Estes atestados não são respeitáveis e podem ser partilhados entre produtores e consumidores a jusante que procuram validação. O não repúdio é conseguido através de métodos criptográficos e, portanto, aumenta significativamente o preço para qualquer invasor que se infiltre na cadeia de abastecimento.
Esta abordagem é considerada essencial por especialistas na área de segurança da cadeia de suprimentos de software. No entanto, embora existam alguns blocos de construção de código aberto para suportar esta classe de controles, apenas alguns fornecedores podem fornecer uma solução integrada.
Uma solução completa de cadeia de fornecimento de software deve incluir:
A coleta de evidências e sua assinatura como atestados dos processos de desenvolvimento e construção de software. Normalmente, essa evidência são hashes de arquivos com metadados que são comparados entre etapas relevantes do processo, eventos sobre etapas relacionadas à segurança, como identidades de committers de código, revisões de código, testes automáticos de segurança e assim por diante. Também é necessário fornecer um atestado quanto à postura de segurança do processo de construção do produtor de software no momento em que o artefato de software foi construído.
Um armazenamento de atestados seguro que permite visibilidade e oferece suporte a análises, como a validação da integridade do código.
Um mecanismo de política que mede esses atestados em relação a uma política definida pela organização ou baseada em padrões para validação e demonstração de conformidade.
Um centro de compartilhamento de informações relacionadas à confiança entre produtores ou consumidores de software; isso pode ser inter ou intraempresa).
Validar a integridade do software é um desafio
Teoricamente, verificar a integridade do código deveria ser fácil. Basta comparar os arquivos, certo? Na realidade, há muito a considerar. Para começar, cada linguagem compila arquivos de maneira diferente. Além disso, os arquivos são usados de maneira muito diferente dependendo de sua finalidade. Alguns devem ser alterados, enquanto outros são excluídos e outros são criados durante o processo de compilação.
Adicione a isso o fato de que as empresas não querem entregar seus códigos proprietários umas às outras.
Garantia de código em todo o SDLC
Scribe se propõe a proteger todo o seu SDLC continuamente. Com evidências coletadas de várias partes do processo de desenvolvimento e construção, a Scribe usa assinatura digital para criar atestados infalsificáveis.
Depois de assinada, cada prova pode ser verificada posteriormente para garantir que todos os processos ocorreram conforme planejado e que nenhuma alteração não planejada ocorreu.
Seguindo as melhores práticas estabelecidas no SSDF, o Scribe permite que você empregue políticas de bom senso para aumentar sua confiança durante todo o processo de desenvolvimento. Políticas como exigência de commits assinados, 2FA para desenvolvedores, revisão de código por duas pessoas, etc., ajudam a gerar confiança de que cada software foi produzido seguindo a postura de segurança correta.
Coletar todas essas evidências em um único local, juntamente com um relatório de integridade de código e um resumo de todas as políticas e atestados permite maior visibilidade e confiança no processo de desenvolvimento e nos artefatos de software produzidos no final e está alinhado com as diretrizes do SSDF que estão em vigor. na base da nova regulamentação cibernética.
Permitir que assinantes selecionados visualizem a conformidade do produto com os requisitos da política e os resultados de integridade oferece aos usuários maior visibilidade e confiança em seus pipelines de desenvolvimento e no produto de software final.
O resultado final não é apenas a detecção de adulteração de código ou pipeline, mas também a capacidade de atestar os testes e procedimentos de segurança que ocorreram durante o projeto e construção do software, bem como a integridade do código-fonte e dos pacotes de código aberto. usado na construção dele.
Segurança da cadeia de suprimentos de software explicada
Automatizando a avaliação de conformidade com SLSA
A segurança dos pipelines dinâmicos deve ser medida continuamente. SLSA (Níveis da cadeia de suprimentos para artefatos de software) define quatro níveis de proteção da cadeia de suprimentos de software, juntamente com diretrizes sobre como alcançá-los.
Uma avaliação de conformidade SLSA pode ser automatizada para atender aos seus requisitos. Mas como uma organização deve proceder para adquirir um? Existem práticas recomendadas específicas que você deve seguir?
Assista a este vídeo onde compartilhamos as melhores práticas para implementação de automação, usando ferramentas de código aberto como Sigstore e OPA em cenários do mundo real. As melhores práticas conceituais e técnicas esclarecem detalhes e desafios do mundo real de avaliação e automatização da conformidade com SLSA.
| Antes de usar o Scribe | Depois de usar o Escriba | |
|---|---|---|
| Trust Hub – Compartilhamento de informações |
|
|
| SDLC seguro – Política e conformidade |
|
|
| Detecção de integridade e violação |
|
|
| Visibilidade |
|
|
| Postura de segurança |
|
|
Scribe Security - um novo padrão de segurança da cadeia de suprimentos de software
Rastreie todos os detalhes e eventos no processo de desenvolvimento de software, bem como a integridade dos componentes e artefatos de software
Verifique se não ocorreu adulteração em toda e qualquer parte do processo de desenvolvimento de software
Verifique a integridade das ferramentas CI/CD usadas para construir o código
Confirme a integridade do processo de desenvolvimento – garantindo que as etapas relacionadas à segurança foram conduzidas de acordo com a política da organização e não foram ignoradas
Ao coletar e assinar evidências de tudo e qualquer coisa que acontece com o código, em cada estágio do ciclo de vida de desenvolvimento você torna mais difícil para os invasores adulterarem arquivos, ferramentas ou o comportamento esperado do seu pipeline de CI/CD.
ajudar?
