Ameaças de cadeia de suprimentos de software

Vetores de ataque para cadeias de suprimentos de software são as várias maneiras pelas quais alguém pode comprometer seu software intencionalmente ou acidentalmente.

Os riscos de software vulnerável incluem vazamento de credenciais ou dados confidenciais, corrupção de dados, instalação de malware e interrupções de aplicativos. Esses problemas resultam em perda de tempo, dinheiro e confiança do cliente.

Os pontos de entrada das ameaças abrangem todo o ciclo de vida do software e podem ter origem dentro ou fora da organização.

Um diagrama que mostra os pontos de entrada dos ataques à cadeia de suprimentos de software

A legenda do diagrama inclui dois conjuntos de ameaças:

O Software Delivery Shield, uma solução totalmente gerenciada de segurança da cadeia de suprimentos de software no Google Cloud, incorpora práticas recomendadas para ajudar a reduzir os dois conjuntos de ameaças.

As subseções deste documento descrevem as ameaças no contexto de origem, builds, implantação e dependências.

Ameaças de origem

Essas ameaças afetam a integridade do seu código-fonte.

  • 1: escrever código não seguro. A falta de práticas de programação seguras pode levar à inclusão não intencional de vulnerabilidades no código. As estações de trabalho inseguras do desenvolvedor também podem introduzir código malicioso ou não seguro. As mitigações incluem o seguinte:

    • Como definir políticas para estações de trabalho do desenvolvedor. O Cloud Workstations fornece estações de trabalho pré-configuradas e totalmente gerenciadas que podem ser personalizadas de acordo com seus requisitos.
    • Digitalização local do código. Source protect do Cloud Code (visualização particular) fornece feedback de segurança em tempo real, incluindo informações sobre vulnerabilidade e licença para dependências. Os desenvolvedores também podem usar a API On-Demand Scanning para verificar imagens de contêiner em busca de vulnerabilidades do pacote de linguagens e do SO.
    • Instrução sobre práticas para tornar o código mais seguro.

  • A: Enviar um código inválido para o repositório de origem. Isso não inclui apenas código malicioso, mas também aqueles que causam involuntariamente vulnerabilidades a ataques como o scripting em vários locais (link em inglês). As mitigações incluem o seguinte:

    • Requer revisão humana para alterações no código-fonte.
    • Uso de ferramentas de verificação e inspeção de código que se integram a ambientes de desenvolvimento integrado e sistemas de controle de origem.

  • B: comprometer o sistema de controle de origem. Restringir o acesso ao sistema de controle de origem e a outros sistemas no pipeline de build e usar a autenticação multifator ajuda a reduzir esse risco.

Ao avaliar a integridade da fonte, examine também os scripts e a configuração de suporte usados para criar e implantar o software. Inclua-os no sistema de controle de origem e nos processos de revisão de código para que você possa se arriscar com vulnerabilidades nesses arquivos.

Consulte Proteger a fonte para saber mais sobre como fazer isso.

Criar ameaças

Essas ameaças comprometem seu software quando você o cria ou empacota ou engana os consumidores do software para que usem uma versão incorreta.

  • C: criar com uma origem que não seja do sistema de controle de origem confiável. Estas são algumas mitigações que ajudam a reduzir esse risco:
    • o uso de serviços de criação, como o Cloud Build, que geram informações de procedência para que você possa validar que suas versões usam uma fonte confiável.
    • Colocar a infraestrutura de CI/CD em um perímetro de rede para evitar a exfiltração de dados dos builds. Para serviços do Google Cloud, use o VPC Service Controls.
    • Armazenamento e uso de cópias confiáveis de dependências de código aberto necessárias em um armazenamento de artefatos particular, como o Artifact Registry.
  • D: comprometer o sistema de compilação. Estas são algumas mitigações que ajudam a reduzir esse risco:
    • Siga o princípio de privilégio mínimo restringindo o acesso direto ao sistema de compilação a indivíduos que precisem dele. No Google Cloud, é possível conceder papéis predefinidos apropriados ou criar papéis personalizados.
    • Usar serviços de build gerenciados, como o Cloud Build. O Cloud Build executa builds temporários configurando um ambiente de VM para cada build e o destruindo após a criação.
    • Coloque sua infraestrutura de CI/CD em um perímetro de rede para evitar a exfiltração de dados dos seus builds. Para serviços do Google Cloud, use o VPC Service Controls.
  • F: empacotar e publicar software que foi criado fora do processo oficial. Com os sistemas de build que geram e assinam a procedência do build, é possível confirmar que o software foi criado por um sistema de build confiável.
  • G: comprometer o repositório em que o software é armazenado para os usuários internos ou externos. Estas são algumas mitigações que ajudam a reduzir esse risco:
    • Armazenamento e uso de cópias confiáveis de dependências de código aberto necessárias em um armazenamento de artefatos particulares, como o Artifact Registry.
    • Validar a criação e a procedência da origem.
    • Restringir permissões de upload a contas não humanas e administradores de repositório dedicados. No Google Cloud, as contas de serviço agem em nome de serviços e aplicativos.

Ameaças de implantação e ambiente de execução

  • H: resolver dependências especificando um intervalo de versões ou uma tag que não está permanentemente anexada a uma versão específica do build pode causar vários problemas:

    • Os builds não são reproduzíveis porque as dependências que um build usa na primeira vez podem ser diferentes das usadas pelo build para execuções futuras do mesmo build.
    • Uma dependência pode ser resolvida para uma versão comprometida ou com alterações que causam falhas no software. Usuários de má-fé podem tirar proveito dessa incerteza para fazer com que seu build escolha a versão de um pacote em vez da versão que você pretende usar. Várias práticas recomendadas para dependências podem ajudar a reduzir os riscos de confiança de dependência.

  • 2: comprometer o processo de implantação. Se você usa um processo de implantação contínua, comprometer esse processo pode introduzir alterações indesejadas no software que você entrega aos usuários. É possível mitigar o risco restringindo o acesso ao serviço de implantação e testando as alterações em ambientes de pré-produção. O Cloud Deploy pode ajudar a gerenciar o processo de entrega contínua e a promoção entre ambientes.

  • 3: implante software comprometido ou não compatível. A aplicação de políticas de implantação pode ajudar a reduzir esse risco. É possível usar a autorização binária para validar se as imagens de contêiner estão em conformidade com os critérios da política e bloquear a implantação de imagens de contêiner de fontes não confiáveis.

  • 4: vulnerabilidades e configurações incorretas no software em execução.

    • Novas vulnerabilidades são descobertas regularmente, o que significa que novas descobertas podem alterar o nível de risco de segurança dos aplicativos em produção.
    • Algumas configurações aumentam o risco de acesso não autorizado, como execução como usuário raiz ou permitir o escalonamento de privilégios na execução de um contêiner.

    O painel de postura de segurança do GKE mostra informações sobre vulnerabilidades do SO e problemas de configuração nas cargas de trabalho em execução.

    No Cloud Run, também é possível ver insights de segurança sobre as revisões implantadas, incluindo vulnerabilidades conhecidas nas imagens de contêiner implantadas.

Consulte Builds de proteção para saber mais sobre como proteger sua origem e Proteger implantações para saber como proteger implantações.

Ameaças de dependência

As dependências incluem dependências diretas nos builds, bem como todas as dependências transitivas, a árvore recursiva de dependências downstream das dependências diretas.

No diagrama, E indica o uso de uma dependência inválida no seu build. Uma dependência ruim pode incluir:

  • Qualquer software de que seu aplicativo depende, incluindo componentes desenvolvidos internamente, software comercial de terceiros e software de código aberto.
  • Vulnerabilidades originadas de qualquer um dos outros vetores de ataque Por exemplo:
    • Um invasor consegue acesso ao seu sistema de controle de origem e modifica a versão de uma dependência usada pelo projeto.
    • Seu build inclui um componente desenvolvido por outra equipe da organização. Eles publicam o build e o componente diretamente dos ambientes de desenvolvimento locais e introduzem acidentalmente uma vulnerabilidade em uma biblioteca usada apenas localmente para testes e depuração.
  • Remoção intencional de uma dependência de código aberto de um repositório público. A remoção pode fazer com que os pipelines de consumo sejam interrompidos se recuperarem a dependência diretamente do repositório público.

Consulte as práticas recomendadas para dependências e aprenda maneiras de mitigar riscos.

Como reduzir ameaças

A integridade geral da cadeia de suprimentos é tão forte quanto a parte mais vulnerável dela. Ignorar um vetor de ataque aumenta o risco de ataque nessa parte da cadeia de suprimentos.

Ao mesmo tempo, você não precisa mudar tudo de uma vez. O efeito de ato cumulativo, mais conhecido como modelo do queijo suíço, aplica-se à segurança da cadeia de suprimentos de software. Cada mitigação implementada reduz o risco. Ao combinar mitigações em toda a cadeia de suprimentos, você aumenta a proteção contra diferentes tipos de ataques.

  • Avalie a postura de segurança usando frameworks e ferramentas que ajudam a avaliar a capacidade da organização em detectar, responder e corrigir ameaças.
  • Saiba mais sobre as práticas recomendadas para proteger sua cadeia de suprimentos de software e sobre os produtos do Google Cloud projetados para oferecer suporte a essas práticas.
  • Use o Software Delivery Shield para proteger o software em toda a cadeia de suprimentos no Google Cloud. Os serviços podem ser implementados de forma gradual com base nas prioridades e na infraestrutura atual.

A seguir