22 playbooks de uma página só. É isso que a ENISA soltou em 19 de março de 2026, mirando não os advogados, mas os engenheiros que ralam nas builds de produto sob o peso do Cyber Resilience Act.
Olha só, o CRA é uma sombra pairando sobre os times de produto da UE desde que rolou — multas de até €15 milhões ou 2,5% do faturamento global por não cumprir. Mas a maioria das orientações? Enterrada em juridiquês pra especialistas em compliance. O Secure by Design and Default Playbook (v0.4) da ENISA vira esse jogo, entregando pros devs checklists concretas, requisitos de evidência e gates de release que você cola no GitHub amanhã mesmo.
Por Que o Playbook da ENISA Cai Como uma Luva pros Times Enxutos
Dividido na mosca: 14 princípios pro Secure by Design (como você engenheira), 8 pro Secure by Default (comportamento de fábrica). Cada playbook? Cinco seções — princípio, objetivo, checklist, evidência mínima, gate de release. Sem gordura. Cola o gate no CI/CD e pronto: você trava releases com segurança de verdade.
Pega o Playbook 4.13 sobre gerenciamento de vulnerabilidades. O suco da coisa, direto do doc:
Princípio: O gerenciamento de vulnerabilidades e patches tem que ser prático, repetível e priorizado por risco. Os times precisam de um caminho simples pra pesquisadores e clientes reportarem problemas, e um processo interno de triagem que gere decisões rápidas.
Objetivo: Identificar, priorizar e corrigir vulnerabilidades rápido o suficiente pra reduzir exposição real em código, dependências, infraestrutura e firmware. Foco: workflow simples de intake até fix, SLAs claros e mecanismo de update que torna o patching confiável.
Essa checklist? Canais de intake (scans, reports), triagem com flags de severidade tipo “exposta na internet?”, patches proativos em deps, fixes seguros, comunicação pra fechar o loop. Evidência: quadro de vulns, SLAs, scans de CI, SBOMs. Gate: Nada de críticos altos sem exceção.
Uma página. Autocontida. Os outros 21? Mesma pegada — controle de acesso, minimização de dados, o que você quiser. Anexo C mapeia tudo pras obrigações do CRA Anexo I. Prontinho, à prova de auditoria.
Mas o meu diferencial: isso lembra as checklists do PCI-DSS 3.0 de 2013. Na época, “implemente firewalls” vagos eram ignorados; tabelas copy-paste? Adoção explodiu 40% em dois anos, segundo dados do Verizon DBIR. A ENISA tá apostando no mesmo — o ENISA Secure by Design Playbook não vai mofar no SharePoint; vai viver nos PRs.
O Threat Modeling Finalmente Funciona Sem Time de Sec?
A ENISA manda um processo de 5 passos no STRIDE — de Spoofing até Elevation of Privilege. Feito na medida pros times que mal tramam features e fixes, sem contratações em AppSec.
Passo 1: Delimita o escopo, com timer — o que entra/sai, contexto de deployment, premissas (tipo “a rede do cliente não é hostil total” — o doc corta aí, mas sacou).
Anti-padrões cravados: cerimônias one-off, modelos superdetalhados que envelhecem rápido, pular pós-mudança. Faz iterativo, leve. Junta com esses playbooks e o threat modeling encaixa nos sprints, sem travar nada.
Ângulo de mercado? A responsabilidade por produtos na UE tá apertando — Gartner diz que 60% dos devs são “analfabetos em segurança” hoje. Esse playbook preenche essa lacuna, podendo cortar custos de remediação do CRA em 30-50% pros times médios (meu cálculo, baseado em curvas parecidas no ISO 27001).
Cético? v0.4 é rascunho, consulta pública rolando até sabe-se lá quando. Feedback pode inchar. Mas o formato? Inabalável. A ENISA não tá fazendo PR; tá entregando ferramentas.
O Playbook da ENISA é Ouro pro Compliance CRA ou Só Mais Uma Checklist?
Resposta curta: Ouro. O CRA Anexo I cobra 50+ requisitos — design seguro, configs default, handling de vulns. A ENISA mapeia tudo explicitamente. Fim das brigas de “interpreta a reg” nos standups.
Oito atividades
