Proteger a sua cadeia de abastecimento de software desde a compilação até à implementação

Evitar que imagens de containers não verificadas, não assinadas ou vulneráveis cheguem ao ambiente de produção. Este guia mostra como os controlos de registo privado, a verificação de vulnerabilidades, a assinatura de artefactos e as políticas de admissão do Kubernetes criam um fluxo de trabalho aplicável em toda a cadeia de abastecimento de software. 
ComeçarManaged Private Registry
Ilustração de nomes de domínio

Verificar cada componente no seu pipeline

A segurança da cadeia de abastecimento de software significa verificar continuamente cada dependência, package e artefacto num pipeline de CI/CD. A confiança deve abranger a origem, package públicos, tecnologia externa, componentes de terceiros, elementos de compilação, registos e a versão final. Uma ameaça pode entrar através de dependências alteradas ou processos comprometidos. Comece por identificar cada componente orientado para o cliente em relação a uma estrutura reconhecida, como a orientação do NIST ou os princípios SSCS. As equipas podem então saber onde faltam provas, aplicar práticas de codificação segura e assinar resultados com o Cosign. Esta abordagem baseada em estruturas permite-lhe aplicar a garantia em toda a cadeia, em vez de depender de um único ponto de controlo. Cada parte pode rastrear o que entrou na compilação, como foi processado e que provas suportam a implementação.
[object Object]

Construir a garantia de lançamento em controlos verificáveis

Projetos Private Harbor, políticas Trivy, assinatura Cosign e jurisdição europeia
Community@2x.png
Limitar o acesso ao registo
Cyber Security@2x.png
Bloquear vulnerabilidades conhecidas
Magnifying Glass Check@2x.png
Verificar a origem e a resiliência

Proteger todas as fases que os atacantes podem visar

O que é a segurança da cadeia de abastecimento num ambiente de containers moderno?

O que é a segurança da cadeia de abastecimento num ambiente de containers moderno? Protege o percurso desde o código-fonte até às dependências de terceiros, passando pelos sistemas de compilação, pelo armazenamento de imagens e pelos pontos finais de implementação. A segurança da cadeia de abastecimento de software considera que estes processos estão interligados, uma vez que um ataque numa das extremidades pode comprometer todos os controlos subsequentes.

Proteção do repositório de origem

Um repositório de origem é um alvo claro. Um atacante pode roubar credenciais, alterar código, desativar uma regra de revisão ou introduzir uma dependência que parece legítima. A primeira linha de defesa é composta por fontes de transferência controladas, revisão por pares obrigatória e ramos protegidos. As equipas devem também bloquear versões de dependências e verificar somas de verificação, licenças e origens em vez de aceitar entradas variáveis para cada compilação. Estas verificações reduzem o risco de importar software malicioso ou não autorizado de terceiros.

Criar percursos de ataque à infraestrutura

A infraestrutura de compilação apresenta diferentes percursos de ataque. Runners comprometidos, segredos expostos ou imagens base modificáveis podem alterar um artefacto depois de os programadores terem aprovado o seu código-fonte. Isolar os processos de compilação, utilizar credenciais de curta duração e registar as entradas exatas. Esta abordagem apoia a segurança da imagem de container ao tornar as alterações de código inesperadas mais fáceis de rastrear.

Controlos de registo para cluster

A rota de registo para cluster precisa de controlos independentes. Um atacante pode substituir uma imagem aprovada, reutilizar uma etiqueta antiga ou explorar permissões de implementação excessivas. O acesso com o mínimo de privilégios restringe o que cada identidade pode publicar ou obter. Referências imutáveis ligam manifestos a imagens precisas, enquanto o Kyverno pode rejeitar lançamentos que careçam de provas fidedignas ou violem requisitos de segurança.

Uma gestão eficaz da cadeia de abastecimento de software começa com um inventário. Registar bibliotecas de primeira e terceira partes, imagens base, licenças e ferramentas de compilação utilizadas por cada aplicação. Associar cada lista de materiais de software (SBOM) ao projeto, ao commit e à execução do pipeline que gerou o respetivo artefacto. Esta relação ajuda as equipas de cibersegurança a identificar serviços afetados quando um componente sensível é comprometido. Escolher uma ferramenta que exporte provas legíveis por máquina e compare versões de forma automatizada. O inventário deve ser desenvolvido em paralelo com o software, em vez de depender de trabalho manual periódico. Atribuir um contacto para tópicos de dependências, exceções e remediação, para que a responsabilidade permaneça clara.
Executar testes de segurança suficientemente cedo para oferecer aos programadores resultados acionáveis. A automatização do pipeline pode examinar dependências de código-fonte, camadas de containers e configuração antes da promoção. Definir os limiares de análise de CVE de acordo com a exposição da carga de trabalho e o impacto nos negócios, e encaminhar os resultados com falhas para a equipa responsável. Uma verificação mal sucedida deve impedir a progressão, em vez de gerar um alerta de ficheiro não lido. Registar o problema, o package afetado, a gravidade e a resposta aprovada. Esta evidência ajuda a proteger a qualidade do lançamento, mantendo as decisões de segurança da cadeia de abastecimento de software consistentes entre aplicações.
A assinatura de imagens prova que processo controlado aprovou um artefacto. Assinar cada imagem com um resumo imutável após a conclusão bem-sucedida dos testes necessários e, em seguida, conservar a proveniência que identifica a revisão de origem, o criador e o fluxo de trabalho. Evitar assinar apenas etiquetas mutáveis, uma vez que uma etiqueta pode posteriormente referenciar conteúdos diferentes. Separar as permissões de assinatura do acesso geral de programadores e pipelines. A verificação deve utilizar identidades fidedignas ou chaves públicas definidas pela sua organização. Um processo de compilação comprometido não pode criar evidências aceitáveis a menos que também satisfaça a política de assinatura.
Um controlador de admissão do Kubernetes fornece o ponto de decisão final antes de as cargas de trabalho entrarem num cluster. Configure-o para rejeitar imagens não assinadas, registos não aprovados, critérios de vulnerabilidade falhados ou proveniência em falta. O Kyverno e o OPA Gatekeeper podem expressar estas condições como políticas controladas pela versão. Teste cada regra com cargas de trabalho representativas antes de a aplicar em produção. Comece em modo de auditoria para encontrar exceções legítimas, depois coloque os controlos maduros em modo de bloqueio. Mantenha um caminho de exceção autorizado com um proprietário, motivo e data de validade. O cluster pode então avaliar a evidência de lançamento de forma consistente, mesmo quando um controlo anterior é ignorado ou mal configurado.
Uma gestão eficaz da cadeia de abastecimento de software começa com um inventário. Registar bibliotecas de primeira e terceira partes, imagens base, licenças e ferramentas de compilação utilizadas por cada aplicação. Associar cada lista de materiais de software (SBOM) ao projeto, ao commit e à execução do pipeline que gerou o respetivo artefacto. Esta relação ajuda as equipas de cibersegurança a identificar serviços afetados quando um componente sensível é comprometido. Escolher uma ferramenta que exporte provas legíveis por máquina e compare versões de forma automatizada. O inventário deve ser desenvolvido em paralelo com o software, em vez de depender de trabalho manual periódico. Atribuir um contacto para tópicos de dependências, exceções e remediação, para que a responsabilidade permaneça clara.

Atribuir a responsabilidade por quatro prioridades de governação

Código fidedigno e gestão de fornecedores

Um líder nomeado deve definir critérios de fonte e fornecedor fidedignos, apoiado por recursos de aprovisionamento, engenharia e segurança. Utilize o SLSA como orientação para uma maior integridade de compilação e proveniência sem assumir um nível de obtenção específico. Adapte as revisões à dimensão da organização e ao risco da cadeia de abastecimento de software.

Aplicação de políticas e infraestrutura em conformidade

Os proprietários de segurança e de plataforma devem traduzir as obrigações de conformidade em aplicação de políticas mensuráveis em todo o código, cloud e infraestrutura. Defina quem pode aprovar exceções, que provas devem fornecer e como os controlos cumprem os requisitos internos.

Documentação, auditorias e provas

Atribuir um recurso responsável para manter a documentação de decisões, dependências e alterações de controlo. Auditorias regulares devem testar se os registos correspondem à prática operacional. Dar aos revisores apoio suficiente para rastrear um problema até ao seu proprietário, versão afetada e resolução.

Prontidão para incidentes e responsabilidade pela remediação

Um líder de segurança deve coordenar as funções de resposta antes que um atacante as teste. Manter um plano para abordar potenciais problemas, cobrindo triagem, contenção, comunicação com as partes interessadas e recuperação. Cada ação necessita de um responsável, recursos de apoio e prazos adequados à exposição ao risco da organização.

Operar o Harbor através de quatro pilares de segurança

Controlar o acesso com precisão

O Harbor suporta RBAC ao nível do projeto e da equipa para separar cargas de trabalho e responsabilidades empresariais. Criar contas de robô com acesso restrito para as tarefas de envio e receção no âmbito da CI/CD, em vez de partilhar credenciais de utilizador com acesso generalizado. Associar cada identidade a um objetivo, atualizar a sua palavra-passe e eliminar os acessos não utilizados. Esta prática limita o impacto da exposição de credenciais enquanto protege a publicação diária.

Detetar componentes inseguros continuamente

Combinar verificações contínuas do Trivy com a análise da composição do software (SCA) e a gestão de dependências. Estas ferramentas detetam vulnerabilidades conhecidas, packages desatualizados e indicadores de código malicioso dentro de cada componente. Produzir um relatório claro para cada versão, incluindo gravidade, localização e estado de remediação. As equipas podem, assim, distinguir os resultados que constituem um obstáculo das exceções aceites e perceber quando novas informações afetam os artefactos armazenados.

Ligar fluxos de trabalho de desenvolvimento

Integrar a plataforma com o GitLab CI, Tekton e outros fluxos de trabalho de desenvolvimento aprovados. Manter as decisões de política próximas do pipeline para que uma verificação falhada devolva feedback útil antes da promoção. As referências de gestão de código-fonte (SCM) devem associar cada artefacto ao respetivo commit, execução de compilação e responsável. As equipas de DevSecOps têm então um registo consistente em vez de provas separadas dispersas pelos sistemas.

Preparar a resposta operacional

Manter um plano de resposta a incidentes para credenciais comprometidas, imagens inseguras e controlos falhados. Definir quem pausa a distribuição, remove uma versão afetada, investiga o acesso e aprova a recuperação. Os alertas precisam de um responsável e de um percurso de resposta esperado; gerá-los apenas não reduz o risco. Fazer exercícios para confirmar que as equipas de segurança e de plataforma conseguem encontrar o relatório relevante, isolar o conteúdo e comunicar decisões. Este pilar operacional transforma a deteção numa ação oportuna em toda a plataforma de entrega.

Preservar provas fidedignas para cada lançamento

A visibilidade do lançamento depende de provas que mostrem quem produziu um artefacto, de onde veio e como foi testado. Gerar e reter resultados do Trivy, dados da lista de materiais de software e assinaturas para cada imagem e conjunto de gráficos Helm. Isto permite à organização identificar cada tipo de conteúdo e investigar um potencial problema de segurança. Integrar verificações com o GitLab CI para automatizar o feedback do programador antes de o software entrar no ambiente controlado. Testes consistentes também apoiam a consciencialização de segurança ao mostrar por que razão um lançamento falhou. Proteger as chaves de assinatura Cosign através do OVHcloud Key Management Service, utilizando armazenamento baseado em HSM FIPS 140-2. A gestão centralizada de chaves ajuda a garantir que cada assinatura gerada está ligada a material de chave controlado, em vez de a um segredo de pipeline exposto.
[object Object]
Aplicar a sua política de lançamento de containers com a OVHcloud
Construir uma rota controlada desde a saída de CI/CD até à implementação em Kubernetes com o Managed Private Registry e o Managed Kubernetes Service. Avaliar como a validação de registo, a prova de lançamento e a aplicação no cluster podem impedir imagens não lidas, não assinadas ou vulneráveis antes da produção. Descubra o Managed Private Registry e, em seguida, avalie a integração com Kubernetes para as suas cargas de trabalho, modelo de política e responsabilidades operacionais.
Explorar percurso do registo