OWASP SPVS: Lições da Segurança do Software Pipeline

Durante anos, os atacantes visavam aplicativos individualmente. Agora, mudaram de tática: por que comprometer um aplicativo quando se pode comprometer todos? pipeline que constrói muitos? Xygeni's Alerta antecipado de malware (MEW) detectou 4,452 pacotes maliciosos em 2025 e Mais 1,281 em 2026 até agora.Cada incidente de grande repercussão dos últimos anos afetou um elo diferente na cadeia de desenvolvimento de software:

• Ventos Solares (2020)Compromisso com o ambiente de desenvolvimento; atualizações ocultas enviadas para 18,000 clientes.
• Codecov (2021)Uma imagem Docker mal configurada permitiu que invasores modificassem um script bash de upload, exfiltrando segredos de CI de mais de 23,000 clientes.
• CircleCI (2023)O roubo de cookies de sessão no laptop de um engenheiro resultou na obtenção de tokens de acesso de produção; todos os clientes foram instruídos a rotacionar seus dados confidenciais.
• Porta dos fundos dos utilitários XZ (2024) Uma campanha de engenharia social que durou vários anos e alcançou praticamente todas as distribuições Linux.
• ações-tj (2025) — uma cascata na cadeia de suprimentos do GitHub Actions que contaminou um componente usado por mais de 23,000 repositórios.
• Ataques contra Aqua Trivy e check-marx (2026) — A campanha TeamPCP transformou dois scanners de segurança amplamente utilizados em vetores de ataque e, em seguida, usou os dados roubados. CI/CD credenciais para serem propagadas em cascata para npm, OpenVSX e PyPI.

Cada ataque explorou uma parte diferente do pipelineAmbiente de compilação, ferramentas de CI, dependências, credenciais de desenvolvedor, confiança do mantenedor, referências mutáveis ​​a artefatos. A maioria das organizações responde com controle pontual, um scanner na CI, autenticação de dois fatores no IdP e proteção de ramificação. mainO que normalmente falta é uma forma de perguntar. Estamos sistematicamente cobertos? em vez de Nos lembramos de habilitar o X após o último incidente?

Os fornecedores de segurança de aplicativos estão diretamente na mira, pois comprometer um deles afeta todos os clientes que confiam em seus produtos. A pressão para migrar de controles reativos para uma postura sistemática não é teórica. Isso é précisO que motivou a adoção do OWASP SPVS? standard como um projeto de alta prioridade.

O que é um SPVS e por que sua estrutura é importante.

A história de origem é simples. Na LASCON 2023, Farshad Abasi e Cameron Walters não paravam de se perguntar: onde está o ASVS para pipelineOWASP ASVS havia dado à segurança de aplicativos uma abordagem abrangente e verificável. standardNão existia nada equivalente para CI/CD.

Existia o OWASP Top 10. CI/CD Riscos, que era orientado para a conscientização, não testável; SLSA, que se concentrava apenas na proveniência da compilação; S2C2F, que se concentrava apenas no consumo de dependências; e OpenSSF O scorecard abrangia verificações específicas do repositório. Cada um cobria uma parte. Nenhum cobria o todo.

A lacuna: cada estrutura abrangia uma parte importante de software supply chain securitymas nenhum forneceu uma solução completa e verificável. standard para todo o CI/CD pipeline.

Essa conversa se transformou em dois anos de trabalho e, em outubro de 2025, o grupo de trabalho SPVS lançou a versão 1.0: 127 requisitos ao longo do ciclo de vida (Planejar, Desenvolver, Integrar, Lançar e Operar), estratificados em três níveis de maturidade: L1 (Fundamental), L2 (Integral), L3 (Integral) e L4 (Integral). Standarde Nível 3 Avançado. Todos os requisitos são mapeados para NIST SP 800-53, OWASP. CI/CD Top 10 e CWE.

É aqui que a maioria das organizações encontra dificuldades. Elas verificam as dependências, mas ignoram a governança de lançamentos. Assinam os artefatos, mas não modelam as ameaças aos seus sistemas. pipeline arquitetura. Eles monitoram a produção, mas não seus ambientes de construção.

Esta é a tese que justifica o esforço. Os pontos fortes em uma etapa não compensam as fraquezas em outra. Os atacantes precisam apenas de um elo para romper. Um ciclo de vida. standard O SPVS obriga você a verificar todos eles, e a progressão de L1 para L2 para L3 permite que você faça isso sem tentar resolver tudo de uma vez. O SPVS não substitui o SLSA, S2C2F, Scorecard ou Sigstore; ele fornece a estrutura que indica onde cada um deles se encaixa.

Adaptando o Standard para a sua organização

O primeiro passo natural é uma auditoria direta da sua organização e infraestrutura de software em relação a cada requisito. Uma planilha do Google, com dados disponíveis no site oficial, pode ser utilizada. Requisitos SPVS CSV Funciona bem como ponto de partida. Três visualizações são úteis: uma matriz de requisitos com status e responsável por controle, um mapa de calor por repositório e um dashboard O progresso é detalhado por etapa e nível. Os resultados alimentam naturalmente um roteiro técnico, um documento dinâmico que abrange todas as etapas, do planejamento à operação.

A maioria das organizações de engenharia maduras já estará por volta do nível 2 quando fizer esse mapeamento inicial. Essa é, na verdade, uma posição vantajosa: significa que a primeira fase pode se concentrar em sanar lacunas específicas, em vez de construir as bases do zero.

Uma planilha, porém, é apenas um instantâneo, e o SPVS exige mais. A versão 1.1.7 exige uma auditoria trimestral dos administradores do VCS; as versões 5.1.1 a 5.1.3 adicionam auditorias regulares de usuários, revisão de logs de acesso e monitoramento de acesso privilegiado; diversos controles das versões 2.1.x, 3.3.x e 4.2.x exigem a higienização contínua do fluxo de trabalho YAML. Executado manualmente em toda a organização, isso representa meio dia de rastreamento de cliques a cada trimestre, com um risco real de omissões silenciosas. É o tipo de tarefa que ou é automatizada ou só é revisada depois que algo ruim acontece.

Alguns controles do SPVS não são itens de lista de verificação pontuais. Eles exigem revisão recorrente, evidências de auditoria e detecção de desvios em repositórios, usuários, fluxos de trabalho e acesso privilegiado.

A solução é criar ou adotar ferramentas que funcionem sob a identidade do proprietário da organização e produzam um pacote trimestral estruturado: lista de administradores, proteção de branches, cobertura de CODEOWNERS, padronização do YAML do fluxo de trabalho com ações fixadas e permissões explícitas. pull_request_target Controle de acesso, autenticação de dois fatores (2FA) de membros, aplicativos GitHub instalados e chaves de implantação. O que antes era meio dia de arqueologia em planilhas se torna um único comando que gera JSON e Markdown. A revisão trimestral entre os CISO e os administradores da organização tornam-se um decisreunião de discussão, não de coleta de dados, e as conclusões acionáveis ​​se tornam problemas pendentes com SLAs baseados em gravidade.

Uma política de lista de permissões, incluindo administradores aprovados, aplicativos aprovados e permissões por função para repositórios e fluxos de trabalho, deve existir como um arquivo YAML em um repositório com controle de versão, sujeito à revisão de pull requests pela equipe de segurança. Qualquer alteração na lista de permissões deixa um registro de revisão, gerando automaticamente evidências de auditoria. O efeito é transformar controles que eram aspiracionais, como "deveríamos realizar auditorias trimestrais", em controles rotineiros, como "a auditoria deste trimestre foi concluída na segunda-feira", e fornecer à organização um mecanismo repetível para a detecção de desvios, conforme exigido pelo princípio de segurança de ponta a ponta.

Os atritos que você deve levar em consideração ao planejar.

Os controles técnicos são a parte fácil. As pessoas são mais difíceis.

O exemplo mais notável é quase sempre o da CODEOWNERS. Adicionando .github/workflows/ @your-org/security Em todos os repositórios parece trivial. Um arquivo, uma linha. Mas significa que os engenheiros que vêm mesclando alterações de fluxo de trabalho por conta própria há anos agora precisam de uma revisão de segurança. Até mesmo pessoas preocupadas com segurança se opõem: Eu escrevi esse fluxo de trabalho, eu o entendo, por que estou esperando?

É preciso uma conversa franca para entender o porquê. Fluxos de trabalho podem exfiltrar credenciais, redirecionar artefatos e prejudicar os consumidores subsequentes. Uma segunda opinião não é sinal de desconfiança; é a mesma lógica da verificação de quatro olhos em alterações no banco de dados de produção. Ter um incidente concreto e recente na cadeia de suprimentos para apresentar, seja do setor ou do seu próprio ambiente, ajuda enormemente. Nada cristaliza um controle como um exemplo real de sua ausência.

Outros atritos seguem o mesmo formato:

• Permissões explícitas: Bloqueios em fluxos de trabalho causam falhas na integração contínua até que os colaboradores compreendam as permissões com escopo. Isso não é um problema de permissões, mas sim um problema de modelo mental.
• Imutabilidade das tags: interrompe a ferramenta de lançamento que vinha sendo reetiquetada silenciosamente há anos.
• Assinado commits: Criar atrito na integração até que as chaves GPG ou SSH estejam configuradas corretamente em todas as estações de trabalho. O SPVS torna isso obrigatório em todos os repositórios e para todos os colaboradores, não apenas nos principais.
• Substituindo os tokens de acesso pessoal clássicos: A abrangência de diversos repositórios e arquivos de fluxo de trabalho afeta praticamente todas as equipes.

O padrão que funciona: introduzir cada controle com uma ameaça específica que ele bloqueia, realizar um teste piloto em um ou dois repositórios, implementar com exceções permitidas e desativar as exceções em um cronograma definido. Os engenheiros que mais resistem, na maioria das vezes, tornam-se os maiores defensores da medida quando entendem a lógica por trás disso.

Um ponto mais importante: o princípio de ponta a ponta se aplica aqui. Não se pode escolher quais controles implementar. Reforçar a fase de construção enquanto se deixa a governança de lançamento frouxa gera uma falsa sensação de segurança, que é exatamente o tipo de falha que os autores do SPVS apontam. Cada etapa precisa avançar em conjunto, mesmo quando um controle específico parece desproporcional isoladamente.

Custo: Aproximadamente um mês de tempo de engenharia foi gasto na Fase 1, focada na conformidade com o Nível 2 para uma pequena organização, distribuído entre as equipes de DevOps, Segurança e revisão de engenharia. O investimento se paga facilmente. Um único incidente evitado na cadeia de suprimentos já o compensa várias vezes. Organizações maiores devem orçar proporcionalmente mais, mas a estrutura em fases, do Nível 1 ao Nível 2 e ao Nível 3, significa que o valor é entregue antes da conclusão do programa.

O que vem a seguir?

A versão 1.5 do SPVS está chegando com controles relacionados à IA: procedência do código assistido por IA, guardrails Para fluxos de trabalho de CI que chamam LLMs, revise os registros gerados por IA. pull requestse defesas contra ameaças emergentes como o slopsquatting, em que os atacantes registram nomes de pacotes que os assistentes de codificação de IA interpretam erroneamente, e o malware operacional gerado por IA que a CrowdStrike relata em atividade. Organizações que já etiquetam com auxílio de IA commitOs departamentos de relações públicas e de relações governamentais, ao incluírem essa adaptação em suas diretrizes internas de desenvolvimento, perceberão que ela é incremental, e não um novo programa de trabalho.

A versão 2.0 deverá aprimorar o monitoramento em tempo de execução e os requisitos do ciclo de vida das credenciais. Um roteiro organizacional razoável: eliminar as lacunas restantes do Nível 3 até o final do segundo trimestre de 2026, incluindo SLSA provenance integrado standard CI/CD, portões manuais para implantações em produção e provedor de identidade centralizado, e então passam para o modo de manutenção. Cada novo repositório começa em conformidade e cada auditoria trimestral detecta desvios precocemente.

Um sincero agradecimento a Farshad Abasi, Cameron Walters e ao grupo de trabalho OWASP SPVS. Projetos como este facilitam o trabalho de qualquer organização que deseje implementar a segurança da cadeia de suprimentos de forma sistemática, em vez de reativa.

Principais lições

Algumas coisas que são aplicáveis ​​além do nosso contexto específico:

• Para experimentar: Baixe o arquivo CSV com os requisitos do SPVS e mapeie seus controles atuais em uma planilha. Você saberá em um dia se eles se encaixam.
• Escolha um nível-alvo e conclua-o antes de tentar o próximo. A transição de L1 para L2 e para L3 é uma funcionalidade, não uma limitação.
• O processo de pipeline é o alvo. Os controles centrados na aplicação são necessários, mas não suficientes; trate o pipeline como uma superfície de ataque de primeira classe.
• Verifique tudo pipeline, não uma única peça. A robustez na análise de dependências não compensa uma governança de lançamentos deficiente ou ambientes de compilação não monitorados.
• Planilhas são instantâneos; a deriva é contínua. Automatize o processo de criação de sistemas, mesmo que seja uma ferramenta interna simples, para detectar discrepâncias entre as auditorias.
• O trabalho organizacional é mais difícil do que o trabalho técnico. Reserve um tempo para conversas e testes piloto antes da implementação, e explique a ameaça específica que cada controle bloqueia.

Para ler mais

• OWASP: Garanta o Pipeline Verificação Standard (SPVS) v1.0Página do projeto OWASP.
• Farshad Abasi: Por que criamos o OWASP SPVS?Artigos da OWASP SPVS.
• Farshad Abasi: Pipeline Os ataques estão piorando. Veja como se preparar.Artigos da OWASP SPVS.
• Farshad Abasi: OWASP SPVS versus outras estruturas de cadeia de suprimentosArtigos da OWASP SPVS.
• OWASP: 10 topo CI/CD Riscos de segurançaPágina do projeto OWASP.
• SLSA: Níveis da cadeia de suprimentos para artefatos de software. slsa.dev.
• OpenSSF: Scorecard. securityscorecards.dev.