CADEIA DE SUPRIMENTOS DE SOFTWARE
Segurança da cadeia de suprimentos de software: o que pode dar errado e o que checar
A maior parte do código que você entrega foi escrita por outra pessoa, e chega à produção por um pipeline de CI com acesso aos seus segredos. Segurança da cadeia de suprimentos de software (supply chain security) é proteger esse caminho: os pacotes dos quais você depende, o build que transforma código em artefatos e as credenciais no meio. Este guia cobre as principais ameaças, os frameworks SLSA e SBOM e exatamente quais partes a Nurbak checa.
Criar conta e conectar GitHubNão guardamos seu código. Só escrevemos quando você pede um PR de correção.
Dependências também são seu código
Um CVE conhecido em um pacote que você importa é tão explorável quanto um bug seu. Saber quais versões são afetadas é o mínimo.
O CI faz parte da cadeia
Um workflow que roda código não confiável com permissão de escrita ou segredos pode deixar alguém de fora mudar o que você entrega.
Segredos são as chaves
Tokens no código, em commits antigos ou embutidos em imagens Docker permitem que um atacante publique, faça deploy ou leia dados em seu nome.
Claros sobre o escopo
A Nurbak checa esses riscos no seu repo. Ela não gera SBOMs, não assina artefatos e não detecta pacotes maliciosos além de advisories conhecidos.
As principais ameaças à cadeia de suprimentos de software
Dependências vulneráveis
Pacotes diretos e transitivos com CVEs publicados. A correção costuma ser subir a versão, se você souber qual versão corrige. Análise de composição de software.
Pacotes maliciosos e typosquatting
Pacotes publicados para parecer com outros populares, ou pacotes legítimos tomados por um atacante e atualizados com código malicioso. Os registries removem muitos, mas novos continuam aparecendo.
pull_request_target no GitHub Actions
O GitHub avisa que esses workflows são privilegiados e podem ter permissão de escrita e segredos, então não devem fazer checkout de código não confiável de forks.
Injeção de scripts em workflows
Colocar valores como o título de um pull request direto em um script de run permite que um atacante injete comandos. O GitHub recomenda passá-los por uma variável de ambiente.
Actions de terceiros sem fixar
Uma tag como @v3 pode ser movida. O GitHub diz que fixar uma action em um commit SHA completo é hoje a única forma de usá-la como release imutável.
Segredos vazados
API keys e tokens no código, no histórico do git ou em Dockerfiles. Apagar a linha não os tira dos commits antigos. Scanner de segredos.
Frameworks: SLSA e SBOM
SLSA
Supply-chain Levels for Software Artifacts é um framework de segurança, um checklist de padrões e controles para evitar adulteração, melhorar a integridade e proteger pacotes e infraestrutura (slsa.dev).
Níveis de build do SLSA
No SLSA v1.0, o Build L1 pede provenance mostrando como o pacote foi construído, o L2 acrescenta provenance assinada gerada por uma plataforma de build hospedada e o L3 exige uma plataforma de build reforçada.
SBOM
A CISA descreve um software bill of materials como um inventário aninhado, uma lista dos ingredientes que compõem os componentes de software. A Nurbak não gera SBOMs. O que é SBOM.
Ameaças à cadeia de suprimentos e o que a Nurbak checa
Cada ameaça, um controle comum e se a Nurbak a cobre. Quando não cobre, dizemos.
| Ameaça | Controle comum | O que a Nurbak faz |
|---|---|---|
| Dependências vulneráveis | SCA a cada mudança, lockfiles, atualizações rápidas | Encontra CVEs de dependências via OSV e informa a versão corrigida |
| Pacotes maliciosos, typosquatting | Revisar dependências novas, lockfiles, advisories do registry | Só aponta pacotes com advisories conhecidos no OSV. Não detecta pacotes maliciosos novos |
| Uso indevido de pull_request_target | Nunca fazer checkout de código não confiável em workflows privilegiados | Checa workflows do GitHub Actions em busca de uso arriscado de pull_request_target |
| Injeção de scripts em workflows | Passar a entrada não confiável por variáveis de ambiente | Checa workflows do GitHub Actions em busca de injeção |
| Actions sem fixar | Fixar actions de terceiros em um commit SHA completo | Não está entre as checagens listadas aqui. Siga a orientação do GitHub |
| Segredos vazados | Scan de segredos, inclusive do histórico, e rotação | Encontra segredos no código, no histórico do git e em Dockerfiles |
| Adulteração do build | Provenance SLSA, assinatura de artefatos | Não. A Nurbak não assina artefatos nem gera provenance |
| Inventário desconhecido | Gerar e compartilhar um SBOM | Não. A Nurbak não gera SBOMs |
Como a Nurbak checa a cadeia de suprimentos do seu repo
Crie uma conta e conecte o GitHub. Funciona com repos públicos e privados.
Escolha um repo. O modelo próprio da Nurbak o analisa em infraestrutura efêmera.
Receba CVEs de dependências com a versão corrigida, problemas em GitHub Actions e Dockerfiles e segredos no histórico do git, com um score de segurança de 0 a 100.
Abra com um clique um pull request com a correção e um teste de regressão de segurança.
Com um plano, o repo é escaneado de novo todos os dias, então CVEs recém-publicados também são detectados.
Perguntas sobre segurança da cadeia de suprimentos de software
O que é segurança da cadeia de suprimentos de software?
É proteger tudo o que entra no seu software e o caminho que ele percorre até a produção: dependências open source, sistemas de build e CI, as credenciais que eles usam e os artefatos que publicam. Um atacante que compromete qualquer uma dessas peças pode chegar aos seus usuários sem tocar no seu próprio código.
Quais são as ferramentas de segurança da cadeia de suprimentos?
Existem ferramentas SCA que cruzam suas dependências com bases de vulnerabilidades, scanners de segredos, scanners de configuração de CI e IaC, geradores de SBOM e ferramentas de assinatura e provenance para builds. A Nurbak cobre as três primeiras para o seu repo no GitHub: CVEs de dependências via OSV, segredos inclusive no histórico do git e checagens de GitHub Actions, Docker, Terraform e Kubernetes.
Como melhorar a segurança da cadeia de suprimentos no npm?
Faça commit do lockfile, revise dependências novas antes de adicioná-las, mantenha as versões atualizadas e cruze-as com vulnerabilidades conhecidas. O próprio comando npm audit envia uma descrição das suas dependências para o registry padrão e pede um relatório de vulnerabilidades conhecidas. A Nurbak também checa as dependências npm contra o OSV e mostra a versão corrigida.
A Nurbak detecta pacotes maliciosos?
Só quando um pacote tem um advisory conhecido na base do OSV. A Nurbak não analisa o comportamento dos pacotes para detectar pacotes maliciosos ou de typosquatting novos, então combine com os advisories do registry e uma revisão cuidadosa das dependências novas.
A Nurbak gera SBOM ou assina artefatos?
Não. A Nurbak não gera SBOMs, não assina artefatos e não produz provenance SLSA. Ela encontra dependências vulneráveis, segredos e configurações erradas de CI no seu repo. Nosso guia o que é SBOM explica como eles funcionam.
Quais riscos do GitHub Actions a Nurbak checa?
A Nurbak revisa seus workflows em busca de injeção de scripts a partir de entrada não confiável e uso arriscado de pull_request_target, além de outras configurações erradas em GitHub Actions, Dockerfiles, Terraform e Kubernetes. Veja o scanner de segurança para GitHub e nosso guia de ferramentas de detecção de segredos.
Quanto custa?
O primeiro scan é grátis e mostra completos os 3 achados mais importantes, mais 1 PR de correção grátis. Os planos são US$ 79 por mês para 1 repo e US$ 199 por mês para até 5 repos, com scans diários. Acima de 5 repos há um plano Enterprise. Cobramos por repo, não por desenvolvedor. Veja os preços.
Cheque hoje a cadeia de suprimentos do seu repo
Conecte o GitHub e receba grátis seu score de segurança e seus 3 achados mais importantes.
Escanear meu repo