Como fornecer software com segurança

Velocidade e tempo de lançamento são as prioridades das organizações 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 da escolha de contêineres como a plataforma preferida. No ano passado, muitas dessas empresas começaram a considerar a abordagem sem servidor também ao aproveitar os benefícios dos contêineres, que incluem menor tempo de lançamento, maior disponibilidade, mais segurança, mais escalonabilidade e custos reduzidos.

As soluções de software reduziram o tempo necessário para desenvolver e apresentar 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:

1. O trabalho dos desenvolvedores acaba sendo freado pelos processos atuais, resultando em atrasos.
2. As equipes de segurança e operações fazem concessões que expõem a organização a ameaças
3. As equipes de desenvolvimento acabam contornando os processos de segurança para conseguir cumprir prazos, aumentando a vulnerabilidade

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 do 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 essa gravidade: primeiro, era muito fácil explorar e permitir a execução completa do código remoto e, em segundo lugar, com frequência a vulnerabilidade estava a muitas camadas de profundidade na árvore de dependência e, portanto, era facilmente perdida.

A Solarwinds, uma empresa de software de gerenciamento de TI, foi atacada por atores a nível de estados-nação, que inseriram 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 mil clientes, incluindo os departamentos do Tesouro e do Comércio dos EUA.

A Kaseya, outro provedor de software de gerenciamento de TI, foi atacada por uma vulnerabilidade de dia zero que comprometeu o servidor Kaseya VSA e enviou um script malicioso para veicular ransomwares que criptografava todos os arquivos nos sistemas afetados.

A necessidade urgente de responder a esses e outros incidentes semelhantes levou a Casa Branca a emitir uma diretiva, em maio de 2021, determinando que as organizações que fazem negócios com o governo norte-americano federal mantivessem determinados padrões de segurança 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 montagem de um automóvel.

Uma montadora de automóveis compra várias peças prontas, fabrica componentes próprios e, em seguida, reúne tudo isso usando um processo altamente automatizado. O fabricante garante a segurança das operações, certificando-se de que todos os componentes vindos de terceiros sejam de fontes confiáveis. Os componentes próprios são testados exaustivamente para garantir que não há problemas de segurança. Por fim, a montagem é realizada por meio de 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 softwares próprios, que representam 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.

Só é preciso um link desprotegido para que a cadeia de suprimentos de software seja violada.

Como no caso dos ataques de alto nível do ano passado, cada etapa do processo pode levar a uma fraqueza a ser aproveitada pelos invasores.

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ódigos com vulnerabilidades conhecidas.

Nem sempre são essas vulnerabilidades que tornam o código não 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 apenas uma dessas vulnerabilidades permaneça sem ser corrigida, trata-se de uma oportunidade para que usuários de má-fé invadam sua cadeia de suprimentos de software.

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 ajudar a proteger a experiência do 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 isso ocorreu.
• 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 – Somos cofundadores da 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ões gerais do código aberto: as visões gerais usam métricas de avaliação, como políticas de segurança bem definidas, processo de revisão 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 código aberto.

Acreditamos que duas coisas são necessárias para superar o problema da segurança da cadeia de suprimentos de software:

1. Estruturas e padrões de todo o setor.
2. 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:

No estado atual, o SLSA é um conjunto de diretrizes de segurança incrementais que são estabelecidas a partir de um consenso do setor. Na forma final, o SLSA será diferente de uma lista de práticas recomendadas em termos de aplicabilidade: ele aceitará a criação automática de metadados auditáveis que podem ser inseridos em mecanismos de políticas para dar a "certificação do SLSA" a um pacote específico ou plataforma de build.

O SLSA foi desenvolvido para ser incremental e acionável e para oferecer 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 não foi adulterado, e ele pode ser rastreado com segurança até a origem. Isso é algo difícil, se não impossível, na maioria dos softwares hoje em dia.

O 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:

O SLSA 1 exige que o processo de build seja totalmente colocado no script/automatizado e gere procedência. A procedência é representada por metadados sobre como um artefato foi criado, incluindo o processo de build, 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 no 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.

O 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. O SLSA 2 também oferece um caminho fácil de upgrade para o SLSA 3.

Além disso, o SLSA 3 exige que as plataformas de origem e de build 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, exigindo a análise de todas as alterações por duas pessoas e um processo de build hermético e reproduzível. A análise por 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 segurança de 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 build/procedência. 

A cadeia de suprimentos de software pode ser dividida em cinco fases distintas: código, build, pacote, implantação e execução. Vamos tratar de cada uma dessas fases de acordo com nossa abordagem de segurança.

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 apresentadas 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 revisão de código, procedência de código verificado e aplicação das políticas. Juntos, esses processos ajudam a minimizar os riscos da cadeia de suprimentos de software, além de melhorar a produtividade dos desenvolvedores.

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.

A proteção de uma cadeia de suprimentos de software começa quando os desenvolvedores começam a projetar o aplicativo e a escrever código. Isso inclui tanto softwares próprios quanto 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 mais rapidez no trabalho dos desenvolvedores, tornando as organizações mais ágeis e produtivas. No entanto, softwares de código aberto certamente não são perfeitos e, ainda que nosso setor dependa deles, geralemente temos acesso a poucos insights sobre as dependências e os diferentes níveis de risco associados a esses softwares. Para a maioria das empresas, o risco é resultado principalmente de vulnerabilidades ou licenças.

O software de código aberto, os pacotes, as imagens de base e outros artefatos necessários para que você construa 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, de "b" a "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: a cada dia, em média, 40 mil 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 delas 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 no sentido do fim da cadeia de suprimentos, vai ficando mais difícil inspecioná-las. Para proteger suas dependências, recomendamos que você comece com o fornecimento:

• 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 código-fonte aberto, com restrições relacionadas a requisitos completos de revisão e auditoria de código.

Vamos falar mais sobre os processos de compilação e implantação, mas também é importante verificar a procedência do build, usar um ambiente de build 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

A próxima etapa para proteger sua cadeia de suprimentos de software envolve o estabelecimento de um ambiente de build seguro em grande escala. Essencialmente, o processo de build começa com a importação do código-fonte em uma das muitas linguagens possíveis 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 build, há várias questões a serem consideradas:

• Seus secrets estão protegidos durante e após o processo de build?
• Quem tem acesso aos ambientes de build?
• 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 envolvidos no processo de build. Por exemplo, alguns usuários talvez precisem gerenciar secrets, enquanto outros talvez precisem gerenciar o processo de build adicionando ou modificando etapas. Outros ainda podem precisar ver 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 rigorosas necessárias para que eles trabalhem 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 e os efeitos da redução do build.

Em seguida, ao escalonar verticalmente 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 build 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 conduzidas por humanos.

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 particulares 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

Ainda que o IAM seja um ponto de partida obrigatório e lógico, ele não é infalível. 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 propenso a erros. O Google usa um sistema chamado autorização binária, que só permite a implantação 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 build foram usados e assim por diante. O Cloud Build ajuda a atingir o 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 obrigatórios para o SLSA de nível 1. Além disso, a procedência e os outros atestados do build podem ser pesquisados usando o resumo de imagens do contêiner, que cria uma assinatura exclusiva para qualquer imagem e também é obrigatório para o SLSA de nível 1.

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 linguagens, como Maven e npm. Ele é totalmente integrado às ferramentas e aos ambientes de execução do Google Cloud e oferece suporte para os protocolos de artefato nativo. Dessa forma, é fácil integrar o Artifact Registry às ferramentas de CI/CD durante a configuração de pipelines automatizados.

Assim como na etapa do build, é 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 suas 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).

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 formas de garantir que somente builds autorizados cheguem à produção.

No Google, desenvolvemos práticas recomendadas para determinar que tipos de builds precisam ser autorizados. Esse processo começa ao garantir a integridade da cadeia de suprimentos, para que ela produza apenas artefatos confiáveis. Em seguida, 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, já foram vencidas as 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 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 autorizado. A autorização binária garante que sejam implantados apenas códigos revisados e autorizados. .

É essencial implantar as imagens em um ambiente de execução confiável. Nossa plataforma gerenciada do Kubernetes, o GKE, usa uma abordagem orientada por 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 continuar 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 conteinerizadas.

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 Autopilot do GKE, 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 é acaba 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 que já existia ou que foi adicionada recentemente, um alerta será criado e registrado, dando a você segurança de que o que está sendo executado em produção é exatamente o que foi pretendido por você.

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 upstream. 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 novas ameaças e ter planos para adotar ações de correção imediatas.

Conclusão

Em resumo, a segurança de uma cadeia de suprimentos de software envolve práticas recomendadas, como o 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 build 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 que e manter uma trilha de auditoria. Usar 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. Monitorar 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.

Tudo pronto para começar a proteger sua cadeia de suprimentos de software? Apenas para esclarecer as coisas, não importa onde você vai começar. Não existe uma mesma ação capaz de 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, aqui estão quatro recomendações para começar.

1. Fazer o patch do software

Se você implanta o código no ambiente de produção com vulnerabilidades conhecidas, está fazendo o trabalho do invasor no lugar dele. A partir daí, não importa o nível de proteção da sua cadeia de suprimentos de software, porque eles já tem acesso a ela. Portanto, o patch é essencial.

2. Controle o que está sendo executado no seu ambiente

Quando estiver usando a aplicação de patches, você vai poder controlar sua própria cadeia de suprimentos de software. Isso começa com a capacidade de afirmar que o que você está executando realmente veio das suas ferramentas de build ou repositórios confiáveis. Esse nível de controle ajuda a evitar tanto ataques propositais quanto erros involuntários, 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 novo problema de segurança da cadeia de suprimentos é a frequência com que softwares de fornecedores são comprometidos 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 que você alcance um certo nível de garantia com relação aos pacotes que está usando. Pergunte a esses fornecedores qual é o nível de conformidade com o SLSA ou se eles estão no escopo dos requisitos das diretrizes recentes do governo relacionadas à segurança.

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 mantida com patches para que você tenha um lugar seguro para começar em cada build e consiga saber com 100% de confiança a origem do código-fonte. 

Práticas recomendadas de DevOps

1. 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.
2. Relatório Accelerated State of DevOps 2021 do Google Cloud
3. 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

1. Blog do Google Cloud: O que é a segurança de identidade com confiança zero
2. Blog de segurança do Google: conheça a SLSA, um framework de ponta a ponta para a integridade da cadeia de suprimentos
3. Artigo do Google Cloud: Estratégia "shift-left" na segurança: proteção de cadeias de suprimentos de software