Como fornecer software com segurança
As organizações de hoje estão focadas na velocidade e no tempo de lançamento do software e dos aplicativos. No entanto, as práticas de segurança atuais não conseguem acompanhar essa velocidade, levando a atrasos no desenvolvimento, comprometimentos arriscados e vulnerabilidade a ameaças.
Neste relatório, você aprenderá a resolver o problema de segurança da cadeia de suprimentos de software das seguintes maneiras:
- Adotar padrões e frameworks de todo o setor
- Implementar esses padrões com serviços gerenciados que usam princípios de privilégio mínimo em uma arquitetura de confiança zero
Descubra como migrar rapidamente do código para o build, empacotamento, implantação e software em execução, tudo em uma base segura.
Entenda a cadeia de suprimentos de software
Cenário de segurança atual
Velocidade e tempo de lançamento são as prioridades das organizações em qualquer lugar que criam software e aplicativos para atender às necessidades dos clientes. Esses imperativos estratégicos têm sido a força motriz por trás do enorme crescimento de contêineres como a plataforma escolhida. No ano passado, muitas dessas empresas começaram a aproveitar os benefícios dos contêineres, que incluem menor tempo de lançamento, maior disponibilidade, mais segurança, mais escalonabilidade e custos reduzidos. pensando na abordagem sem servidor também.
As soluções de software reduziram o tempo necessário para oferecer um novo recurso ou até mesmo um novo produto, mas muitas das práticas de segurança atuais são incapazes de acompanhar o aumento na velocidade, levando a um dos três problemas a seguir:
- Os desenvolvedores são prejudicados pelos processos atuais, resultando em atrasos.
- As equipes de segurança e operações fazem compromissos que levam a organização a ameaças
- As equipes de desenvolvimento trabalham nos processos de segurança atuais para cumprir prazos, o que os torna vulneráveis
Nos últimos anos, houve uma série de violações de segurança classificadas como ataques à "cadeia de suprimentos de software".
O Log4Shell era uma vulnerabilidade perigosa no software Apache Log4j identificada em dezembro de 2021. Sinalizada com a pontuação máxima de CVSS de 10, essa vulnerabilidade foi particularmente devastadora devido à popularidade do Log4j, um framework de geração de registros baseado em Java. Duas coisas contribuíram para a gravidade: primeiro, foi muito fácil explorar e permitir a execução completa do código remoto e, em seguida, muitas vezes havia muitas camadas na árvore de dependência e, portanto, elas eram facilmente perdidas.
A Solarwinds, uma empresa de software de gerenciamento de TI, foi atacada por agentes nacionais que injetaram um código malicioso em builds oficiais de softwares de código aberto em uso na empresa. Essa atualização maliciosa foi enviada para 18.000 clientes, incluindo o Departamento do Tesouro e Comércio dos EUA.
A Kaseya, outro provedor de software de gerenciamento de TI, foi atacada por uma vulnerabilidade de zero dia que comprometeu o servidor Kaseya VSA e enviou um script malicioso para fornecer ransomware que criptografava todos os arquivos nos sistemas afetados.
A necessidade urgente de responder a esses e outros incidentes semelhantes levou a Casa Branca a liberar uma Ordem Executiva em maio de 2021. Isso exigiu que as organizações que fazem negócios com o governo federal mantivessem determinados padrões de software segurança.
Cadeia de suprimentos de software
Em muitos aspectos, o termo "cadeia de suprimentos de software" é muito apropriado: os processos usados na criação de uma cadeia de suprimentos de software são muito semelhantes aos da fabricação de um carro.
Um fabricante de automóveis compra várias peças prontas, fabrica componentes próprios e, em seguida, reúne todos eles com um processo altamente automatizado. O fabricante garante a segurança das operações, garantindo que cada componente de terceiros venha de uma fonte confiável. Os componentes próprios são testados extensivamente para garantir que não têm problemas de segurança. Por fim, a montagem é realizada por um processo confiável que resulta em carros prontos.
A cadeia de suprimentos de software é semelhante em muitos aspectos. Um fabricante de software recebe componentes de terceiros geralmente de código aberto que realizam funções específicas e desenvolvem um software próprio, que é a propriedade intelectual principal. Em seguida, o código é executado por meio de um processo de compilação que combina esses componentes em artefatos implantáveis, que são implantados na produção.
O ponto fraco na cadeia
Ele só usa um link não seguro para violar a cadeia de suprimentos de software.
Como no caso dos ataques de alto nível do ano passado, cada etapa do processo pode levar a uma fraqueza que os invasores podem explorar.
Por exemplo, o pacote npm médio tem 12 dependências diretas e cerca de 300 dependências indiretas. Além disso, sabemos que quase 40% de todos os pacotes npm publicados dependem de código com vulnerabilidades conhecidas.
Essas vulnerabilidades podem não tornar o código seguro. Por exemplo, a vulnerabilidade pode estar em uma parte da biblioteca que nunca foi usada. No entanto, essas vulnerabilidades precisam ser verificadas.
A escala desse problema é monumental. Mesmo que uma dessas vulnerabilidades sofresse a correção, é possível que os usuários de má-fé tenham a oportunidade de entrar na sua cadeia de suprimentos de software.
Veja alguns exemplos de ataques que usam vulnerabilidades em cada uma dessas etapas, mostradas no diagrama acima.
| Ameaça | Exemplo conhecido | |
| A | Enviar código inválido para o repositório de origem | Compromissos de hipótese do Linux: o pesquisador tentou inserir intencionalmente as vulnerabilidades no kernel do Linux usando patches na lista de e-mails. |
| B | Plataforma de controle de origem de comprometimento | PHP: o invasor comprometeu o servidor git auto-hospedado do PHP e injetou dois compromissos maliciosos. |
| C | Criar com processo oficial, mas a partir de um código que não corresponda ao controle de origem | Webmin: o Attacker modificou a infraestrutura de compilação para usar arquivos de origem que não correspondam ao controle de origem. |
| D | Plataforma de build de confirmação | SolarWinds: o invasor comprometeu a plataforma de build e instalou um implante para injetar um comportamento malicioso durante cada build. |
| E | Use uma dependência incorreta (por exemplo, AH, recorrente) | event-stream: o invasor adicionou uma dependência inocente e, em seguida, atualizou a dependência para adicionar comportamento malicioso. A atualização não correspondeu ao código enviado ao GitHub (por exemplo, ataque F). |
| F | Faça upload de um artefato que não tenha sido criado pelo sistema de CI/CD | Codecov: o invasor usou credenciais vazadas para fazer upload de um artefato malicioso para um bucket do Google Cloud Storage, de onde os usuários fazem o download diretamente. |
| G | Repositório de pacotes de comprometimento | Ataques em espelhos de pacote: o pesquisador executou espelhos em vários repositórios de pacotes conhecidos, que podem ter sido usados para exibir pacotes maliciosos. |
| H | Induziu o consumidor a usar um pacote inválido | Browserify typesquatting: o invasor fez upload de um pacote malicioso com um nome semelhante ao do original. |
Como fortalecer a cadeia: a liderança inovadora do Google Cloud em código aberto
No Google, desenvolvemos aplicativos em escala global há décadas. Ao longo do tempo, abrimos o código de muitos dos nossos projetos internos para ajudar a aumentar a velocidade dos desenvolvedores. Ao mesmo tempo, desenvolvemos vários processos internos para proteger a experiência de software.
Veja a seguir alguns dos nossos esforços para fortalecer as cadeias de suprimentos de software em todos os lugares.
- Aumento dos investimentos: anunciamos em agosto de 2020 que investiremos US$ 10 bilhões para os próximos cinco anos para fortalecer a segurança cibernética, incluindo a expansão de programas de confiança zero, ajudando a proteger a cadeia de suprimentos de software. o que aumenta a segurança do código aberto.
- Níveis de cadeia de suprimentos para artefatos de software (SLSA): o SLSA é um framework completo para a integridade da cadeia de suprimentos. Ele é um código aberto equivalente a muitos dos processos que implementamos internamente no Google. A SLSA fornece uma prova auditável do que foi criado e como.
- DevOps Research and Assessment (DORA): nossa equipe de DORA conduziu um programa de pesquisa de sete anos, validando vários recursos técnicos, de processo, medição e cultura que aumentam o número de entregas de software e desempenho organizacional.
- Open Source Security Foundation – Cofundamos a Open Source Security Foundation em 2019, um fórum de vários setores sobre a segurança da cadeia de suprimentos.
- Allstar: o Allstar é um app do GitHub instalado em organizações ou repositórios para definir e aplicar políticas de segurança. Isso permite a aplicação contínua das práticas recomendadas de segurança para projetos do GitHub.
- Visão geral do código-fonte aberto: as visões gerais usam métricas de avaliação, como políticas de segurança bem definidas, processo de análise de código e cobertura contínua de testes com fuzzing e ferramentas de análise estática para oferecer uma pontuação de risco a projetos de origem.
Acreditamos que duas coisas são necessárias para superar o problema da segurança da cadeia de suprimentos de software:
- Estruturas e padrões de todo o setor.
- Os serviços gerenciados que implementam esses padrões usando princípios de privilégio mínimo são conhecidos como arquitetura de confiança zero. Uma arquitetura de confiança zero é aquela em que nenhuma pessoa, dispositivo ou rede tem confiança inerente; Em vez disso, toda a confiança, que permite acesso à informação, precisa ser conquistada.
Vamos analisar cada um deles:
Estruturas e padrões gerais do setor
Para entender os princípios básicos de proteção da cadeia de suprimentos de software, vamos começar pela SLSA.
No estado atual, a SLSA é um conjunto de diretrizes de segurança incrementais que são estabelecidas pelo consenso do setor. Na forma final, a SLSA será diferente de uma lista de práticas recomendadas em termos de aplicabilidade: ela aceitará a criação automática de metadados auditáveis que podem ser inseridos em mecanismos de políticas para dar a "certificação da SLSA" a um pacote específico ou plataforma de build.
A SLSA foi desenvolvida para ser incremental e acionável e para fornecer benefícios de segurança em cada etapa. Quando um artefato se qualifica no nível mais alto, os consumidores podem ter certeza de que ele não foi adulterado e pode ser rastreado com segurança para a origem. Isso é difícil, se não impossível na maioria dos softwares hoje em dia.
A SLSA consiste em quatro níveis, sendo que o SLSA 4 representa o estado final ideal. Os níveis mais baixos representam marcos incrementais com garantias de integridade incrementais correspondentes. No momento, os requisitos são definidos da seguinte maneira:
A SLSA 1 exige que o processo de build seja totalmente roteirizado/automatizado e gere procedência. Procedência são metadados sobre como um artefato foi criado, incluindo o processo de builda, a origem de nível superior e as dependências. Conhecer a procedência permite que os consumidores de software tomem decisões de segurança baseadas em riscos. Embora a procedência na SLSA 1 não proteja contra adulterações, ela oferece um nível básico de identificação de origem do código e pode ajudar no gerenciamento de vulnerabilidades.
A SLSA 2 requer o uso de controle de versões e um serviço de build hospedado que gera procedência autenticada. Esses requisitos adicionais oferecem ao consumidor mais confiança na origem do software. Nesse nível, a procedência impede a adulteração na medida em que o serviço de build é confiável. A SLSA 2 também oferece um caminho de upgrade fácil para a SLSA 3.
Além disso, a SLSA 3 exige que as plataformas de origem e criação atendam a padrões específicos para garantir a auditoria da origem e a integridade da procedência, respectivamente. O SLSA 3 oferece proteções muito mais eficientes contra adulterações do que os níveis anteriores, evitando classes específicas de ameaças, como a contaminação entre builds.
No momento, o SLSA 4 é o nível mais alto, que exige uma revisão de duas pessoas de todas as alterações e um processo de compilação hermético e reproduzível. A revisão em duas pessoas é uma prática recomendada do setor para detectar erros e impedir comportamentos inadequados. Os builds herméticos garantem que a lista de dependências da procedência esteja completa. Os builds reproduzíveis, embora não sejam estritamente obrigatórios, oferecem muitos benefícios de auditoria e confiabilidade. Em geral, o SLSA 4 oferece ao consumidor um alto grau de confiança com que o software não foi adulterado. Mais detalhes sobre esses níveis propostos podem ser encontrados no repositório do GitHub, incluindo os requisitos correspondentes de origem e criação/procedência.
A cadeia de suprimentos de software pode ser dividida em cinco fases distintas: código, criação, pacote, implantação e execução. Vamos abordar cada uma dessas fases de acordo com nossa abordagem de segurança.
Serviços gerenciados para cada fase
No Google Cloud, fornecemos ferramentas totalmente gerenciadas, desde código e criação até implantação e execução, com os padrões e as práticas recomendadas acima implementados por padrão.
Proteger sua cadeia de suprimentos de software exige o estabelecimento, a verificação e a manutenção de uma cadeia de confiança que estabeleça a procedência do seu código e que garanta que você está executando o que está em produção. No Google, fazemos isso com atestados gerados e verificados em todo o processo de desenvolvimento e implantação de software, permitindo um nível de segurança ambiente por meio de análises de código, procedência de código verificado e aplicação da política. Juntos, esses processos ajudam a minimizar os riscos da cadeia de suprimentos de software, além de melhorar a produtividade do desenvolvedor.
Na base, temos serviços de infraestrutura seguros comuns, como gerenciamento de identidade e acesso e geração de registros de auditoria. Em seguida, protegemos sua cadeia de suprimentos de software com uma maneira de definir, verificar e aplicar atestados em todo o ciclo de vida do software.
Vamos analisar com mais detalhes como alcançar a segurança ambiente no processo de desenvolvimento usando políticas e procedência no Google Cloud.
Fase 1: código
A proteção da cadeia de suprimentos de software começa quando os desenvolvedores começam a projetar o aplicativo e a escrever código. Isso inclui softwares próprios e componentes de código aberto, cada um com seus próprios desafios.
Dependências e softwares de código aberto
O código aberto permite que os desenvolvedores criem coisas mais rapidamente para que as organizações possam ser mais ágeis e produtivas. No entanto, softwares de código aberto não são perfeitos e, mesmo que nosso setor dependa deles, muitas vezes temos poucos insights sobre as dependências e os diferentes níveis de risco associados. Para a maioria das empresas, o risco resulta principalmente de vulnerabilidades ou licenças.
O software de código aberto, pacotes, imagens de base e outros artefatos de que você depende para formar a base da sua "cadeia de confiança".
Por exemplo, considere que sua organização está criando um software "a". Este diagrama mostra a cadeia de confiança: em outras palavras, o número de dependências implícitas no seu projeto. No diagrama, "b", "h" são dependências diretas, e de "i" a "m" são dependências indiretas.
Agora, considere que há uma vulnerabilidade na parte inferior da árvore de dependências. O problema pode aparecer em vários componentes muito rapidamente. Além disso, as dependências mudam com muita frequência: em um dia médio, 40.000 pacotes npm apresentam uma mudança nas dependências.
O Open Source Insights é uma ferramenta criada pelo Google Cloud que fornece um gráfico de dependência transitiva para que você veja suas dependências e as respectivas dependências na árvore de dependências. O Open Source Insights é atualizado continuamente com orientações de segurança, informações de licenciamento e outros dados de segurança de vários idiomas, tudo em um só lugar. Quando usado em conjunto com as visões gerais de código aberto, que fornecem uma pontuação de risco para projetos de código aberto, o Open Source Insights ajuda os desenvolvedores a fazer escolhas melhores entre os milhões de pacotes de código aberto disponíveis.
Para resolver esse problema, é fundamental se concentrar nas dependências como código. À medida que essas dependências avançam rumo ao fim da cadeia de suprimentos, é mais difícil inspecioná-las. Para proteger suas dependências, recomendamos que você comece com a oferta:
- Use ferramentas como o Open Source Insights e as visões gerais do OSS para entender melhor suas dependências.
- Verifique todos os códigos, pacotes e imagens de base com um processo automatizado que é uma parte essencial do fluxo de trabalho.
- Controle como as pessoas acessam essas dependências. É fundamental controlar rigidamente os repositórios para código próprio e de código aberto, com restrições em torno de requisitos completos de análise e auditoria de código.
Falaremos mais sobre os processos de compilação e implantação, mas também é importante verificar a procedência do build, usar um ambiente de compilação seguro e garantir que as imagens sejam assinadas e posteriormente. validadas no momento da implantação.
Há também uma série de práticas de programação seguras que os desenvolvedores podem empregar:
- Automatizar testes
- Usar linguagens de software que protegem a memória
- Solicitar revisões de código
- Garantir a autenticidade da confirmação
- Identificar códigos maliciosos antecipadamente
- Evitar a exposição de informações confidenciais
- Exigir geração de registros e saída de build
- Aproveitar o gerenciamento de licenças
Fase 2: criação
A próxima etapa para proteger sua cadeia de suprimentos de software envolve o estabelecimento de um ambiente de compilação seguro em grande escala. Essencialmente, o processo de compilação começa com a importação do código-fonte em possivelmente uma das muitas linguagens de um repositório e a execução de builds para atender às especificações apresentadas nos arquivos de configuração.
Provedores de nuvem como o Google oferecem acesso a um ambiente de build gerenciado e atualizado que permite criar imagens em qualquer escala necessária.
Durante o processo de compilação, há várias questões a serem consideradas:
- Seus secrets são protegidos durante e após o processo de compilação?
- Quem tem acesso aos ambientes de compilação?
- E os vetores de ataque ou riscos de exfiltração relativamente novos?
Para desenvolver um ambiente de build seguro, comece com secrets. Eles são essenciais e relativamente fáceis para proteção. Comece garantindo que os secrets nunca sejam texto simples e, se possível, não façam parte do build. Em vez disso, você precisa garantir que eles sejam criptografados e seus builds sejam parametrizados para se referir a secrets externos para usar conforme necessário. Isso também simplifica a rotação periódica de secrets e minimiza o impacto de qualquer vazamento.
A próxima etapa é configurar permissões para seu build. Há vários usuários e contas de serviço envolvidas no processo de compilação. Por exemplo, alguns usuários talvez precisem gerenciar secrets, enquanto outros talvez precisem gerenciar o processo de compilação adicionando ou modificando etapas. Outros ainda podem precisar visualizar registros.
Ao fazer isso, é importante seguir estas práticas recomendadas:
- O mais importante é o princípio de privilégio mínimo. Implemente permissões refinadas para conceder aos usuários e contas de serviço as permissões precisas de que eles precisam para realizar os trabalhos com eficiência.
- É necessário saber como os usuários e as contas de serviço interagem e têm uma compreensão clara da cadeia de responsabilidade, desde a configuração de um build até a execução dele para os efeitos downstream do build.
Em seguida, ao escalonar esse processo, estabeleça limites para seu build na medida do possível e use a automação para escalonar verticalmente por meio de configurações como código e parametrização. Isso permite auditar todas as alterações no processo de compilação de maneira eficaz. Além disso, verifique se você atende às necessidades de conformidade usando o controle de aprovação para builds e implantações confidenciais, solicitações de envio de alterações de infraestrutura e revisões regulares de registros de auditoria orientadas por pessoas.
Por fim, verifique se a rede atende às suas necessidades. Na maioria dos casos, é melhor hospedar seu próprio código-fonte em redes privadas protegidas por firewalls. O Google Cloud oferece acesso a recursos como pools privados do Cloud Build, um ambiente de build sem servidor bloqueado no seu perímetro de rede particular e recursos como VPC Service Controls para evitar a exfiltração de propriedade intelectual.
Autorização binária
Embora o IAM seja um ponto de partida obrigatório e lógico, ele não é à prova de erros. Credenciais vazadas representam um sério risco de segurança. Portanto, para reduzir sua dependência do IAM, é possível alternar para um sistema baseado em atestados menos propensos a erros. O Google usa um sistema chamado autorização binária, que permite a implantação apenas de cargas de trabalho confiáveis.
O serviço de autorização binária estabelece, verifica e mantém uma cadeia de confiança por meio de atestados e verificações de política durante todo o processo. Essencialmente, a autorização binária gera assinaturas criptográficas, atestados, à medida que o código e outros artefatos são transferidos para a produção. Em seguida, antes da implantação, esses atestados são verificados com base nas políticas.
Ao usar o Google Cloud Build, um conjunto de atestados é capturado e adicionado à cadeia de confiança geral. Por exemplo, os atestados são gerados para quais tarefas foram executadas, quais ferramentas e processos de compilação foram usados e assim por diante. O Cloud Build ajuda a atingir a SLSA de nível 1 capturando a origem da configuração do build, que pode ser usada para confirmar se o build foi colocado no script. Os builds com script são mais seguros que os manuais e são necessários para o SLSA nível 1. Além disso, a procedência e os outros atestados do seu build podem ser pesquisados usando o resumo de imagens do contêiner, que cria uma assinatura exclusiva para qualquer imagem e também é necessário para o SLSA nível 1.
Fase 3: pacote
Quando o build estiver concluído, você terá uma imagem de contêiner quase pronta para produção. É essencial ter um local seguro para armazenar as imagens que evitem a adulteração de imagens e uploads não autorizados. O gerenciador de pacotes provavelmente precisará ter imagens para builds próprios e de código aberto, bem como pacotes de linguagens usados pelos aplicativos.
O Artifact Registry do Google Cloud oferece esse repositório. O Artifact Registry é um local único para sua organização gerenciar imagens de contêiner, bem como pacotes de linguagem, como Maven e npm. Ele é totalmente integrado às ferramentas e aos ambientes de execução do Google Cloud e é compatível com protocolos de artefato nativo. Isso facilita a integração com suas ferramentas de CI/CD durante a configuração de pipelines automatizados.
Assim como na etapa de criação, é essencial garantir que as permissões de acesso ao Artifact Registry sejam bem pensadas e sigam os princípios de privilégio mínimo. Além de restringir o acesso não autorizado, o repositório de pacotes pode fornecer muito mais valor. O Artifact Registry, por exemplo, inclui a verificação de vulnerabilidades para verificar as imagens e garantir que elas sejam seguras para a implantação. Esse serviço verifica as imagens em um banco de dados de vulnerabilidades atualizado constantemente para avaliar novas ameaças e pode enviar alertas quando uma vulnerabilidade for encontrada.
Essa etapa gera mais metadados, incluindo um atestado se os resultados de vulnerabilidade de um artefato atendem a determinados limites de segurança. Depois, essas informações são armazenadas no nosso serviço de análise, que estrutura e organiza os metadados do artefato, facilitando a autorização binária. É possível usar isso para impedir automaticamente que imagens perigosas sejam implantadas no Google Kubernetes Engine (GKE).
Fases 4 e 5: implantação e execução
As duas últimas fases da cadeia de suprimentos de segurança de software são implantar e executar. Embora sejam duas etapas separadas, faz sentido pensar nelas juntas como uma maneira de garantir que somente builds autorizados cheguem à produção.
No Google, desenvolvemos práticas recomendadas para determinar que tipos de builds precisam ser autorizados. Isso começa ao garantir a integridade da sua cadeia de suprimentos para que ela produza apenas artefatos confiáveis. Em seguida, ele inclui o gerenciamento de vulnerabilidades como parte do ciclo de vida de entrega de software. Por fim, reunimos essas duas partes para aplicar fluxos de trabalho com base em políticas de verificação de integridade e vulnerabilidades.
Ao chegar a este estágio, você já passou pelas fases de código, build e pacote. Os atestados capturados na cadeia de suprimentos podem ser verificados para autenticidade por autorização binária. No modo de aplicação, uma imagem é implantada apenas quando os atestados atendem às políticas da sua organização e, no modo de auditoria, as violações de política são registradas e acionam alertas. Também é possível usar a autorização binária para restringir a execução de builds a menos que eles tenham sido criados usando o processo do Cloud Build sancionado. A autorização binária garante que apenas códigos revisados e autorizados sejam implantados. .
É essencial implantar suas imagens em um ambiente de execução confiável. Nossa plataforma gerenciada do Kubernetes, o GKE, usa uma abordagem de priorização da segurança em contêineres.
O GKE cuida de muitas das preocupações importantes de segurança do cluster. Os upgrades automáticos de clusters permitem manter o Kubernetes com patches e atualizado automaticamente usando canais de lançamento. Inicialização segura, nós protegidos e verificações de integridade garantem que o kernel e os componentes do cluster do nó não tenham sido modificados e estejam executando o que você pretende e que os nós maliciosos não possam participar do cluster. Por fim, a computação confidencial permite executar clusters com nós em que a memória é criptografada. Assim, os dados podem ser confidenciais mesmo durante o processamento. Combine isso com a criptografia de dados em repouso e em trânsito na rede, e o GKE fornece um ambiente muito seguro, particular e confidencial para executar suas cargas de trabalho em contêiner.
Além disso, o GKE também melhora a segurança dos aplicativos com o gerenciamento de certificados para balanceadores de carga, identidade de cargas de trabalho e recursos de rede avançados com uma maneira eficiente de configurar e proteger a entrada no cluster. O GKE também oferece ambientes de sandbox para executar aplicativos não confiáveis, protegendo o restante das cargas de trabalho.
Com o GKE Autopilot, as práticas recomendadas e os recursos de segurança do GKE são implementados automaticamente, o que reduz ainda mais a superfície de ataque e minimiza a configuração incorreta que pode levar a problemas de segurança.
A necessidade de verificação não é interrompida na implantação. A autorização binária também é compatível com validação contínua, permitindo a conformidade contínua com a política definida, mesmo após a implantação. Se um aplicativo em execução não estiver em conformidade com uma política existente ou adicionada recentemente, um alerta será criado e registrado, dando a você confiança de que o que está sendo executado em produção é exatamente o que você pretendeu.
Gerenciamento de vulnerabilidades
Além de garantir a integridade, outro aspecto da segurança da cadeia de suprimentos é garantir que as vulnerabilidades sejam encontradas rapidamente e corrigidas. Os invasores evoluíram para inserir ativamente as vulnerabilidades em projetos ascendentes. O gerenciamento de vulnerabilidades e a detecção de defeitos precisam ser incorporados em todos os estágios do ciclo de vida da entrega de software.
Quando o código estiver pronto para implantação, use um pipeline de CI/ CD e aproveite as diversas ferramentas disponíveis para fazer uma verificação abrangente do código-fonte e dos artefatos gerados. Essas ferramentas incluem analisadores estáticos, fuzzing e vários tipos de verificadores de vulnerabilidades.
Depois de implantar a carga de trabalho na produção e enquanto ela é executada para atender aos usuários, é necessário monitorar ameaças emergentes e ter planos para tomar medidas imediatas.
Conclusão
Em resumo, a segurança de uma cadeia de suprimentos de software envolve práticas recomendadas, como SLSA, e o uso de serviços gerenciados confiáveis que ajudam a implementá-las.
Isso é essencial para:
- Começar com o código e as dependências e verificar se é possível confiar nelas.
- Proteger seu sistema de compilação e usar atestados para verificar se todas as etapas de build necessárias foram seguidas.
- Verificar se todos os pacotes e artefatos são confiáveis e se não podem ser adulterados.
- Controlar quem pode implantar o quê e manter uma trilha de auditoria. Use a autorização binária para validar os atestados de cada artefato que você quer implantar.
- Executar seus aplicativos em um ambiente confiável e garantir que ninguém faça adulterações durante a execução. Monitore todas as vulnerabilidades recém-descobertas para proteger a implantação.
No Google, desenvolvemos práticas recomendadas para cada etapa dessa jornada no nosso portfólio de produtos. Assim, você tem uma base confiável para desenvolver.
Primeiros passos
Tudo pronto para começar a proteger sua cadeia de suprimentos de software? Para esclarecer, não importa onde você começará. Nenhuma ação protegerá a cadeia de suprimentos inteira. Além disso, nenhuma ação é mais importante do que outra quando falamos da segurança da cadeia de suprimentos. Dito isso, veja quatro recomendações para começar.
1. Fazer o patch do software
Se você tiver implantado o código no ambiente de produção com vulnerabilidades conhecidas, terá feito o trabalho do invasor para elas. A partir desse ponto, não importa o nível de proteção da sua cadeia de suprimentos de software, porque eles já tiveram acesso a elas. Portanto, o patch é essencial.
2. Controle o que está sendo executado no ambiente
Quando estiver usando a aplicação de patches, você poderá controlar sua própria cadeia de suprimentos de software. Isso começa com a capacidade de declarar que o que você está executando realmente veio das suas ferramentas de compilação ou repositórios confiáveis. Esse nível de controle ajuda a evitar ataques propositais e erros intencionais, como no caso de um desenvolvedor que implantou algo que não sabia que era inseguro. Isso oferece uma base sólida para a adição de ferramentas como testes de cliques e autorização binária.
3. Garanta a segurança dos pacotes de fornecedores terceirizados
Um problema emergente em segurança da cadeia de suprimentos é a frequência em que o software dos fornecedores é comprometido para fornecer um canal para ransomware ou acesso não autorizado nas implantações de clientes-alvo. Os pacotes de fornecedores terceirizados executados no ambiente (por exemplo, produtos de gerenciamento de sistemas, produtos de gerenciamento de rede ou produtos de segurança) geralmente têm altos níveis de privilégio. Sugerimos pedir a esses fornecedores para irem além das instruções de segurança padrão para fornecer um grau de garantia sobre os pacotes que você está usando. Pergunte ao cliente qual é o nível de conformidade com SLSA ou se ele está no escopo dos requisitos do Executive Order recente.
4. Ter uma cópia privada do código-fonte
Se você estiver usando um software de código aberto, não use uma versão extraída diretamente da Internet para a criação. Em vez disso, tenha uma cópia privada que precisa de patch para que você tenha um lugar limpo para começar em cada build e consiga saber com 100% de confiança a origem do código-fonte.
Leitura adicional
Práticas recomendadas de DevOps
- Seis anos do relatório State of DevOps, um conjunto de artigos com informações detalhadas sobre os recursos que preveem o desempenho da entrega de software e uma verificação rápida para ajudar você a descobrir como está se saindo e como melhorar.
- Relatório Accelerated State of DevOps 2021 do Google Cloud
- Artigo do Google Cloud: Como migrar para a arquitetura nativa da nuvem: uma abordagem evolucionária para aumentar a produtividade dos desenvolvedores em escala
Como proteger a cadeia de suprimentos de software
- Blog do Google Cloud: O que é a segurança de identidade com confiança zero
- Blog de segurança do Google: Conheça a SLSA, uma estrutura completa para a integridade da cadeia de suprimentos
- Artigo do Google Cloud: Como proteger a cadeia de suprimentos de software
Tudo pronto para dar os próximos passos?
Preencha o formulário para entrarmos em contato com você. Ver formulário