diary/sbom-diario-de-um-devsecops-exausto #226
Description
diary/sbom-diario-de-um-devsecops-exausto
Hoje acordei com o alerta do Slack: “lembre-se de gerar o SBOM do release de amanhã”. Mal abri o olho e já tinha auditoria batendo virtualmente na porta. Antes do café, rodei o pipeline e o que saiu não foi bem uma lista de ingredientes, mas uma confissão de culpa coletiva: 1.243 dependências, 19 críticas, 42 abandonadas. É como se meu código gritasse: “olha, não é só bug, é arqueologia digital!”. O SBOM parece um daqueles sonhos estranhos em que você entra no node_modules e descobre um universo paralelo com bibliotecas que você nunca instalou.
Lá pelas 10h, a reunião com o time de produto começou. Alguém perguntou se o SBOM realmente era necessário ou se era só mais uma moda de compliance. Eu quis responder com sinceridade: “olha, SBOM é igual airbag — você só percebe a falta quando já está batendo na parede”. Mas fiquei quieto, lembrando que qualquer frase mal interpretada vira backlog. O que saiu da minha boca foi um morno: “ajuda na transparência da supply chain”. Tradução: me deixa em paz, só quero terminar esse build.
Na hora do almoço, enquanto eu tentava mastigar um arroz frio, o Jenkins me chamou de volta. O SBOM tinha quebrado porque o CycloneDX plugin insistia em cuspir JSON quando o auditor queria RDF. O erro era tão específico que parecia piada: “Formato não compatível com diretriz internacional 15.4.2”. Sério, se já é difícil alinhar dependência em equipe de quatro devs, imagina alinhar 15 países discutindo formato de SBOM. É o equivalente regulatório do tabs vs spaces.
No meio da tarde, alguém do time de segurança me enviou uma lista de CVEs encontradas no SBOM de ontem. A cereja do bolo? Todas eram conhecidas há mais de seis meses. Fiquei com a sensação de que o SBOM não é bem uma ferramenta de segurança, mas sim uma máquina de constrangimento. Ele não te protege de ataque nenhum, só expõe o quanto você é lento para corrigir o que todo mundo já sabia. É como ter um Prometheus sem alertmanager: o dado tá lá, piscando em vermelho, mas ninguém se mexe.
Às 17h, veio a call com o fornecedor. Eles mandaram o SBOM deles em PDF. Sim, PDF. Aquilo parecia o manual de micro-ondas, com 300 páginas de nomes de bibliotecas que podiam estar ou não atualizadas. Perguntei se havia versão em JSON. Responderam que “isso é responsabilidade do cliente”. Quase perguntei se eles também mandam software compilado em disquete. Segurei a piada. Compliance não gosta de sarcasmo.
Quando achei que o dia estava acabando, o time de infra levantou uma bomba: “e se a gente começar a versionar o SBOM junto com o código?”. Minha alma saiu do corpo por uns segundos. Já pensou em abrir um PR e, além de revisar classe e teste, ter que revisar a lista de 200 dependências que o bot atualizou? O code review já é infernal com lógica de negócio, imagina com inventário regulatório. Vai ser o verdadeiro git diff da depressão.
Às 19h, enquanto revisava o dashboard de vulnerabilidade, percebi que o SBOM estava mentindo. Algumas dependências não apareciam, porque estavam escondidas em scripts internos e pacotes baixados de registries alternativos. O SBOM prometia transparência, mas na prática era igual a log mal configurado: bonito no slide, inútil no incidente. Fiquei pensando que o futuro real seria SBOM vivo, em runtime, atualizando em tempo real. Mas aí lembrei: a gente ainda luta pra colocar healthcheck direito em pod. Sonhar custa caro.
No after-hours, recebi mensagem no Teams: “cliente pediu SBOM em YAML, até amanhã”. Respirei fundo. YAML. O formato que já causou mais brigas em devops do que tabs vs spaces. Se amanhã der erro de indentação, a culpa vai cair em mim, não no auditor que inventou essa exigência. É nesse momento que penso: o problema não é o SBOM, o problema é acreditar que formatos resolvem segurança. É como acreditar que trocar firewall por AI vai impedir estagiário de abrir porta no security group.
Enquanto apagava as últimas luzes do dia, concluí: SBOM é o Prometheus das dependências tóxicas. Ele coleta, organiza, mostra gráfico, mas não resolve. É uma lente que aumenta a vergonha, não um remédio. Talvez seja esse o papel dele: nos forçar a admitir que construímos sistemas críticos em cima de bibliotecas frágeis e mantidas por desconhecidos. O SBOM é aquele amigo inconveniente que aponta o erro em público.
Fechei o notebook com uma certeza estranha. Por mais burocrático que seja, o SBOM pode ser a cutucada que faltava para parar de ignorar o caos do node_modules. Se a dor é inevitável, que pelo menos vire automação. Quem sabe um dia a gente chegue ao ponto de ter CI/CD que não só gera SBOM, mas também aplica patch automático e manda relatório no Slack com “deploy seguro”. Até lá, seguimos na mesma: devSecOps exausto, pipeline chorando, e auditor feliz com mais um PDF que ninguém vai ler.