Equipes que consomem pacotes open source sem um processo uniforme de ingestão não conseguem responder rápido a um incidente com dependência maliciosa nem provar de onde veio cada artefato em produção. O S2C2F (Secure Supply Chain Consumption Framework), mantido pela OpenSSF, organiza esse problema em práticas concretas e níveis de maturidade que cabem em qualquer pipeline. A ação prioritária é padronizar como todo desenvolvedor baixa dependências: cache interno de artefatos, inventário automatizado e scan obrigatório antes do primeiro uso.
O que é o S2C2F
O S2C2F é um processo de redução de risco focado em como organizações consomem software open source, cobrindo pacotes NuGet, npm, PyPI, contêineres e código-fonte espelhado. O framework agrupa 8 práticas em 4 níveis de maturidade, para que o progresso seja incremental em vez de um salto único. Cada prática reúne requisitos identificados por códigos estáveis, o que permite cobrar evidência específica de cada time em vez de discutir abstrações.
As práticas cobrem o ciclo completo: ingerir artefatos por fontes aprovadas, escanear por vulnerabilidades e malware, manter inventário do que está em produção, atualizar dependências, auditar proveniência e integridade, aplicar política de consumo, reconstruir de fontes confiáveis e corrigir problemas a montante. A lógica de fundo é controlar todas as entradas de artefatos: se cada time baixa código de um jeito diferente, nenhuma política de segurança se sustenta em escala.
Na Microsoft, o S2C2F é usado desde 2019 e depois foi doado à OpenSSF, onde segue evoluindo de forma aberta. A página oficial da Microsoft descreve o modelo como parte do processo interno de engenharia de segurança, paralelo ao SDL, e a especificação no repositório da OpenSSF detalha requisitos, ameaças mapeadas e ferramentas de exemplo.
Como avaliar sua maturidade
A avaliação é feita no nível da organização, não de um único projeto, porque times diferentes têm processos distintos de consumo. O método recomendado tem três etapas: preparar entrevistas com uma amostra diversa de times, aplicar um questionário padrão e planejar melhorias com base no nível encontrado.
Perguntas úteis para o diagnóstico incluem: de onde o time baixa open source (npmjs.com, pypi.org, curl, clone direto, binário versionado no repositório); se usa lock files; se mistura pacotes internos e externos no mesmo feed, cenário típico de dependency confusion; como fica sabendo de vulnerabilidades e em quanto tempo corrige; se escaneia pacotes por malware antes do uso; se consegue bloquear um pacote conhecido como malicioso; e se existe plano de resposta para o caso de consumir um componente comprometido.
O resultado raramente é uniforme: um time pode ter automação de atualização e outro ainda corrigir à mão. O objetivo do levantamento é elevar todos ao mesmo nível mínimo, padronizando processo e ferramenta, antes de investir em requisitos avançados que só fazem sentido sobre uma base estável.
Práticas distribuídas por nível
A tabela resume o foco de cada nível e exemplos de requisitos que sustentam a cobrança por evidência:
| Nível | Foco | Exemplos de requisitos |
|---|---|---|
| L1 | Controle básico das entradas | ING-1 gestores de pacote confiáveis; ING-2 cache local de artefatos; SCA-1 scan de vulnerabilidades; INV-1 inventário automatizado |
| L2 | Velocidade e configuração segura | UPD-2 atualização automática; ENF-1 blindagem dos arquivos de fonte de pacote; AUD-3 validação de integridade; INV-2 plano de resposta a incidentes |
| L3 | Barreira contra pacotes maliciosos | SCA-4 scan de malware antes do download; ING-3 deny list; ING-4 espelhamento interno do código; ENF-2 feed curado obrigatório |
| L4 | Confiança no binário | REB-1 reconstrução em ambiente confiável; REB-2 assinatura do que é reconstruído; REB-3 SBOM gerado na reconstrução; AUD-4 validação de SBOMs recebidos |
O nível L4 é tratado pela especificação como aspiracional: custa caro em escala e faz sentido para as dependências mais críticas dos projetos mais críticos, não para tudo. Reconstruir de fonte em ambiente confiável é a defesa contra ataques que alteram o binário durante o build, como os casos históricos de CCleaner e SolarWinds citados no documento.
Velocidade de correção importa
A meta declarada é corrigir pacotes vulneráveis em menos de 72 horas, ritmo calibrado pela exploração do SaltStack em até 3 dias após o anúncio da falha. O argumento é direto: se o adversário opera em dias, a correção manual e reativa perde a corrida. Por isso a atualização automática de dependências aparece já no nível L2, com ferramentas gratuitas como Dependabot e Renovate abrindo pull requests de atualização.
Isso conecta o S2C2F ao debate de priorização de correção por risco, tratado no guia Priorização de correções por risco: o modelo em 4 perguntas: a automação só entrega valor se o time souber o que corrigir primeiro, o que depende do inventário do nível L1.
Plano de adoção priorizado
P1 — parar o sangramento (30 dias): implantar cache de artefatos como caminho único de download; ativar scan de vulnerabilidades no pull request; gerar inventário automatizado ou SBOM de cada serviço. Sem这三项, nenhum incidente em dependência pode ser contido com prazo previsível.
P2 — fechar o ciclo (90 dias): configurar arquivos de fonte de pacote com mapeamento de fonte e lock files contra dependency confusion; validar hash ou assinatura dos artefatos consumidos; ativar atualização automática com meta de correção medida por MTTR; escrever o plano de resposta para consumo de componente malicioso, com deny list atualizável em minutos.
P2 avançado (dois trimestres): escanear malware antes do download, espelhar o código-fonte das dependências mais usadas e restringir o consumo a um feed curado. Reserve a reconstrução de fonte e a validação de SBOMs assinados de terceiros para as dependências que sustentam ativos de alto valor.
Sinais a verificar
Indicadores de que a organização está pronta para subir de nível: pulls de dependência fora do cache interno caem a zero nas auditorias; o tempo médio entre divulgação e correção de vulnerabilidade é medido e caindo; o plano de resposta a componente malicioso foi exercitado em tabletop, no formato descrito em Tabletop de crise: transforme o exercício em aprendizado; e o inventário responde em minutos onde cada versão de um pacote roda em produção.