À medida que todos estão ficando cada vez mais conscientes, protegendo suas cadeias de fornecimento de software deve ser uma parte vital da estratégia de segurança cibernética de cada organização.
Uma das principais dificuldades na criação de uma estratégia abrangente para mitigar as ameaças à cadeia de abastecimento de software é a complexidade e a diversidade das cadeias de abastecimento. Cada cadeia de abastecimento é única e os elementos envolvidos estão em constante mudança, tornando difícil confiar na sua própria cadeia de abastecimento, muito menos no software que ela produz.
Neste artigo, descreveremos uma plataforma de conformidade contínua que permite que consumidores e produtores de software demonstrem de forma transparente confiança e conformidade para proteger o SDLC, promovam melhores práticas de segurança, atendam aos requisitos regulatórios e mitiguem riscos cibernéticos utilização aatestados.
Nosso modelo proposto consiste em blocos definidos que podem ser facilmente estendidos e integrados à sua pilha, independentemente da plataforma ou dos casos de uso de sua preferência. Terminaremos demonstrando uma política básica de verificação usando Ferramenta Valint do escriba para mostrar que esse processo não é tão complicado quanto você pode temer.
Teoria do caos na cadeia de suprimentos
Um dos principais desafios na segurança das cadeias de abastecimento é a enorme complexidade dos sistemas envolvidos. Sua cadeia de suprimentos de software inclui cada software envolvido na criação de seu produto final, seja como parte do ambiente ou como um software integrado à sua base de código. Você pode dizer por esta descrição que essas cadeias de suprimentos são vastas e incluem tudo, desde o momento em que um desenvolvedor começa a escrever o código, passando pela compilação, teste, integração e até o ponto em que o produto final está sendo executado e incorporando cada parte do código. software e biblioteca usados ao longo do caminho.
Definir o modelo de segurança para tais sistemas requer a compreensão da vasta gama de soluções de programação idiomas, gerenciadores de pacotes, produtos, pilhas de tecnologia, serviços de CI, provedores de nuvem, importações de dependências, VMs, sistemas operacionais e outros componentes que podem ser incluídos em uma determinada cadeia de fornecimento. É essencial considerar a ampla gama de ativos que podem estar em risco dentro de tal sistema, incluindo aplicações, tokens, chaves e outras formas de permissões de acesso.
Visão geral do modelo de verificação de políticas
Nosso modelo proposto inclui vários blocos de construção que funcionam juntos para garantir a segurança e a conformidade de uma cadeia de suprimentos. Esses blocos de construção são necessários para verificar continuamente os aspectos de segurança do software e a conformidade com a regulamentação da cadeia de fornecimento de software.
- evidência: objetos imutáveis que devem ser consumidos automaticamente pelas políticas. Esses objetos contêm metadados necessários para permitir a aplicação de políticas e atender aos requisitos de conformidade. O conteúdo de evidências inclui metadados sobre artefatos, eventos e configurações, mas também pode coletar relatórios, configurações ou verificações reais.
evidência pode vir em formato assinado e não assinado. Sugerimos seguir o in-toto especificação de atestado utilizando o assinado atestado e não assinado afirmação formatos, respectivamente.- Atestados (também conhecidos como evidências assinadas verificáveis): Evidência verificável ligada a um determinado contexto ambiental, transmitindo confiança usando alguma forma de assinatura PKI.
- Contexto ambiental: as informações contextuais unem o modelo.
Responde à questão de onde vêm as evidências e que informações elas contêm. É importante que o contexto esteja vinculado à evidência em vez de fazer parte dela, uma vez que você pode ter várias evidências vinculadas ao mesmo contexto e este modelo permite uma busca e recuperação de evidências mais fácil e eficiente.
Em termos básicos, um contexto ambiental é um sistema de rotulagem onde a maioria dos rótulos é lida no ambiente, plataforma ou artefatos. Os rótulos fornecem acesso normalizado a muitos processos do seu processo de desenvolvimento e pipeline de CI/CD. Aspectos relacionados à origem das evidências, como repositórios Git, tags e commits, mas também nomes de fluxo de trabalho, nomes de trabalhos, runID e assim por diante. O contexto ambiental também pode incluir aspectos do assunto, como hashes de artefatos, nomes e tags.
O contexto pode ser visto como uma extensão do in-toto Especificação de atestado, integrado à carga assinada. Utilizando o sistema de rotulagem, podemos fornecer à fase de avaliação de políticas uma forma de consultar provas através de rótulos numa série de aspectos. Além disso, os dados de contexto podem ser utilizados como parte do processo de avaliação de políticas, acrescentando “consciência situacional” às evidências.
- Políticas: Um conjunto de módulos de política configurados pelo usuário que definem o relatório de conformidade necessário. As políticas podem especificar os padrões mínimos de segurança ou os níveis de conformidade exigidos para diferentes tipos de produtos ou sistemas incluídos no seu pipeline de construção ou no seu processo de desenvolvimento. Mais importante ainda, as avaliações políticas resultantes criam relatórios de conformidade que são atestados também. Isso nos permite não apenas gerenciar os relatórios de conformidade – por exemplo, expor seu status de conformidade às partes interessadas – mas também utilizar o relatório de conformidade para políticas mais complexas que podem abranger um escopo maior de regulamentação de conformidade para uma organização. As políticas podem ser agrupadas em módulos de política. São plug-ins que implementam conjuntos de regras de política que compartilham algumas características (semelhantes aos módulos de software). Esses plug-ins são fornecidos por Provedores de Políticas (mais sobre isso mais tarde).
A avaliação de um módulo de política fornece resultados que incluem avaliações, detalhes de conformidade e veredictos referentes à regulamentação de segurança em questão. Além disso, os resultados incluem o histórico de evidências necessárias para retroceder o módulo de evidências avaliado quanto à conformidade. - Lojas: serviços que fornecem recursos de hospedagem, upload/download e consulta de evidências (mais sobre isso posteriormente). Eles podem ser utilizados em registros de imagens (OCI como armazenamento), serviços dedicados (ou seja, Scribe Service) ou simplesmente no sistema de arquivos local.
- Provedores de políticas: São entidades (empresas, organizações) responsáveis por assinar e disponibilizar módulos de políticas. Ao fornecer apólices como uma espécie de atestado, os provedores transmitem confiança e transparência à própria apólice. Por exemplo, um Atestado de Pacote OPA pode capacitar os reguladores a publicar e assinar pacotes OPA oficiais que implementam módulos de políticas.
Ao utilizar esses blocos de construção, nosso modelo permite que as organizações verifiquem a segurança e a conformidade de seus pipelines de construção e do ciclo de vida de desenvolvimento com relativa facilidade.
Como funciona
O ponto de partida deste fluxo de trabalho é um desenvolvedor ou sistema, gerando evidências para um produto ou componente de software. O conteúdo da evidência, bem como informações contextuais, assuntos e assinaturas, são coletados e carregados em um armazenamento de evidências.
Por outro lado, os relatórios de conformidade são criados avaliando políticas adequadas às necessidades e requisitos organizacionais.
Usando informações contextuais, as avaliações de políticas podem consultar as evidências produzidas pela sua cadeia de fornecimento e garantir que elas contenham todas as informações que a regulamentação possa exigir.
Como benefício adicional, as políticas e os relatórios de conformidade são acessíveis como provas, proporcionando transparência e confiança, bem como um histórico de todas as provas envolvidas. Isso permite que as organizações gerenciem relatórios de conformidade, mas também os utilizem como atestados confiáveis para transmitir confiança aos consumidores de software..
Ao utilizar este fluxo, as organizações e as partes interessadas podem reduzir os riscos, proporcionar transparência e garantir a conformidade na sua cadeia de abastecimento, reduzindo o impacto do caos e melhorando a segurança geral e a confiança nos seus produtos.
Avaliação da política
A avaliação de uma política é feito através da verificação de um conjunto de módulos de política, cada um atendendo a regulamentações e necessidades de conformidade específicas.
Uma avaliação de política faz a cada módulo duas perguntas simples:
- Que evidências são necessárias para cumprir o módulo?
- Quais são os critérios para as evidências comprovarem o cumprimento?
Por exemplo, no contexto da Estrutura SLSA (níveis da cadeia de suprimentos para artefatos de software), os módulos de política podem especificar que a evidência de proveniência do SLSA assinada e uma verificação de postura de segurança para o pipeline de construção são necessárias para cumprir os requisitos de segurança. As evidências fornecidas por esses módulos seriam então verificadas para garantir que atendem a todos os requisitos do SLSA.
- Que evidências são necessárias para cumprir os requisitos do SLSA?
- Um atestado de proveniência SLSA (evidência assinada) do artefato de construção.
- Verificação da postura de segurança do pipeline de CI que produz o artefato.
- Quais são os critérios para as evidências comprovarem o cumprimento dos requisitos do SLSA?
- Ambas as evidências devem incluir informações que atendam a todos os requisitos do SLSA.
Para este exemplo, o atestado de proveniência SLSA precisa descrever seu processo de construção de imagem em sua totalidade, enquanto o atestado de postura de segurança precisa verificar se o SCM que armazenou a origem da imagem usa regras de proteção de ramificação.
- Ambas as evidências devem incluir informações que atendam a todos os requisitos do SLSA.
Outro exemplo de módulo de política é o Módulo Verificar Artefato, que especifica que alguns artefatos devem ser assinados por uma fonte confiável. Utilizando atestados (evidência assinada verificável) Assinatura PKI (Public Key Infrastructure), para atender a exigência de alguma pessoa/entidade específica que necessite assinar os artefatos e também atestar o contexto de origem dos artefatos.
A Módulo Verificar Artefato responde às seguintes perguntas:
1. Que provas são necessárias para demonstrar a conformidade com os requisitos de segurança?
- Evidência que descreve um artefato que inclui uma assinatura PKI (atestado).
2. Como podem estas provas ser verificadas para garantir a conformidade?
- A assinatura do atestado PKI é válida.
- A identidade do certificado PKI corresponde aos requisitos do usuário.
- O assunto da evidência corresponde aos requisitos do usuário.
- O formato e a origem correspondem aos requisitos do usuário.
Da teoria à prática
Vamos nos aprofundar na implementação deste modelo que atualmente é suportado pela ferramenta Valint.
Vejamos um exemplo simples de política que especifica como verificar as assinaturas e a origem de uma imagem.
Especificamente, precisamos verificar se as evidências satisfazem os seguintes critérios:
- O tipo de evidência é o atestado CycloneDX SBOM que descreve uma imagem.
- O artefato é assinado por minhaempresa.com.
- A imagem se origina de um fluxo de trabalho Circle-CI acionado pelo minha_imagem_src descanso.
Política de Modelo
No exemplo anterior, a política era estática e verificada apenas para uma imagem específica chamada minhaempresa/minha_imagem. No entanto, muitas vezes é preferível ter políticas que suportem recursos de modelo/variáveis. Isso permite definir requisitos que podem ser aplicados a vários processos ou artefatos semelhantes em seu pipeline de construção de CI/CD.
Para modelar a política, você pode usar uma variável em vez de bloquear a política estaticamente para um produto. No exemplo acima, você pode alterar o nome_artefato valor para `$MY_IMAGE`em vez disso, permitir que os avaliadores configurem uma política para uma infinidade de imagens que exigem as mesmas regulamentações de conformidade.
Olhando para o futuro
At Escriba, o nosso objetivo final é mitigar os riscos na cadeia de abastecimento através de um modelo de conformidade verificável e baseado em evidências. Um dos primeiros lugares para testar esse modelo é no pipeline de construção de CI/CD. Acreditamos que esta abordagem de verificação de evidências é a chave para garantir a transparência e a responsabilização na cadeia de abastecimento, com benefícios para todas as partes interessadas envolvidas. Nosso modelo encapsula muitas das ideias emergentes na comunidade da cadeia de fornecimento de software, definindo o relacionamento entre muitas delas. Estamos comprometidos em inovar e melhorar a transparência da cadeia de fornecimento de software. Se este modelo despertou seu interesse, encorajo você a conferir nosso Documentação CLI Valint onde expandimos os recursos e usos da ferramenta. Sinta-se à vontade para experimentar.
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
