SbD-ToE 4 CRA: Playbook de Implementação
Visão Geral
Objetivo: Transformar requisitos CRA em ações concretas usando controlos existentes do SbD-ToE.
Princípio: Reutilizar > Inventar. Muitas capacidades (SBOM, patching, testes) já existem, mas a conformidade CRA exige também contexto de produto, papel de operador económico, support period, reporting formal e rota documental própria.
Este playbook é mais defensável quando aplicado a:
- fabricante de produto com elementos digitais
- fornecedor que precisa de organizar evidência técnica para uma leitura
CRA - contextos com produto versionado, contacto de segurança, período de suporte e responsabilidades de operador económico
Fora desse contexto, o SbD-ToE continua útil como base técnica, mas a leitura já não é uma leitura CRA completa.
📚 Recursos de Suporte: Para templates práticos e exemplos de implementação, consultar Exemplo-Playbook com toolchains, KPIs, RACI e processos de vulnerability handling reutilizáveis.
Mapa Rápido CRA → SbD-ToE
| Área CRA | SbD-ToE | Ação | Evidência |
|---|---|---|---|
| Ciclo de Vida Seguro | Cap. 02, Cap. 06, Cap. 07, Cap. 11 | Política ciclo de vida, support period e gates | Política aprovada; pipeline YAML; registo de support period |
| Vulnerability Handling | Cap. 05, Cap. 10, Cap. 12 | Processo triagem + SLA | Registos triagem; métricas SLA |
| SBOM | Cap. 05 | Geração contínua + export | Ficheiros CycloneDX por release |
| Patching Rápido | Cap. 05, Cap. 07 | Workflow patch automático | Pull requests patch + tempos |
| Reporte Exploração | Cap. 12, Cap. 14 | Runbook técnico + interface de notificação regulatória | Runbook; matriz de comunicação; JSON exemplo |
| Documentação Segurança | Cap. 04, Cap. 11 | Guia de segurança do produto + contact point + fim de suporte | PDF/Markdown guia publicado; tabela de suporte |
| Exceções | Cap. 02 addon 08, Cap. 14 | Política exceções CRA | Registos exceções + aprovadores |
| Cadeia Fornecimento | Cap. 05, Cap. 09, Cap. 14 | Checklist supply chain físico | Checklist preenchida |
Fases de Implementação (≈ 6–9 meses)
Fase 1 (M0–M1): Fundamentos, Scope Gate & Governance
- Designar Owner CRA (GRC + AppSec)
- Criar Política "Segurança de Produto & CRA" (aprovada por gestão)
- Mapear roles SbD-ToE → papéis CRA (fabricante, importador, distribuidor, substantial modification quando aplicável)
- Definir matriz criticidade produto (base L1–L3 adaptada)
- Registar support period e regra de comunicação de fim de suporte por linha de produto
Evidências: Ata aprovação; matriz criticidade; política versão 1.0; registo de papéis e suporte
Fase 2 (M1–M2): SBOM & Inventário
- Ativar geração automática SBOM (build pipeline)
- Validar cobertura (≥95% componentes listados)
- Criar export sanitized CycloneDX
- Repositório "SBOM Releases" (controlado, versionado)
Evidências: SBOM v1; relatório cobertura; script export
Fase 3 (M2–M3): Vulnerability Handling & SLAs
- Definir severidade (Critical/High/Medium/Low)
- Estabelecer SLA patch (Critical ≤15d, High ≤30d, Medium ≤90d)
- Automatizar criação de issue para CVE crítico
- Dashboard patch compliance
Evidências: Política SLA; dashboard inicial; issues exemplo
Fase 4 (M3–M4): Testes & Gate Release
- Integrar SAST/DAST/fuzzing pipeline
- Criar gate "no-critical-known" (release bloqueada)
- Processo exceção crítica (board-level)
- Template relatório qualidade release
Evidências: Logs pipeline; configuração gate; relatório release #1
Fase 5 (M4–M5): Disclosure & Comunicação Externa
- Publicar security.txt + chave PGP
- Página "Vulnerability Disclosure Policy"
- Runbook triagem reporte externo
- Canal email/portal dedicado
- Identificar ponto de contacto de segurança para utilizadores e investigadores
Evidências: Página pública; registo primeiro teste reporte; contacto publicado
Fase 6 (M5–M6): Reporte de Exploração Ativa
- Definir critérios de "explorada ativamente" (IOC, telemetria confirmada)
- Criar script export JSON incidente + SBOM componente afetado
- Runbook notificação autoridade / CSIRT coordenador e matriz de comunicação a utilizadores
- Simulação exercício interno
Evidências: Script; runbook; relatório exercício; matriz de comunicação
Fase 7 (M6–M7): Documentação de Segurança do Produto
- Escrever Guia Segurança (instalação segura, atualização, contacto, support period, fim de suporte)
- Validar com AppSec + engenharia
- Publicar versão 1.0 (Markdown/PDF)
- Processo atualização por release
Evidências: Guia v1; diff v1→v2 (exemplo)
Fase 8 (M7–M8): Cadeia Fornecimento Expandida
- Inventariar firmware/hardware (se aplicável)
- Checklist integridade (hash, assinatura, origem)
- Processo atualização segura (secure channel)
- Métrica cobertura supply chain (≥90%)
Evidências: Checklist preenchida; métrica cobertura
Fase 9 (M8–M9): Métricas & Melhoria Contínua
- Métricas: MTTP (Mean Time To Patch), % SLA cumprido, vulns abertas por severidade
- Reunião retrospectiva trimestral
- Plano melhoria (top 3 blockers)
- Ajuste políticas conforme revisão legal/regulatória
Evidências: Dashboard; ata retrospectiva; plano melhoria
Checklists
Checklist SBOM
- Pipeline gera SBOM automaticamente
- Formato CycloneDX/SPDX validado
- Export sanitized criado
- Versão SBOM associada a release
- Cobertura ≥95% componentes
- Processo atualização documentado
Checklist Vulnerability Handling
- Severidade definida (Critical/High/Medium/Low)
- SLA patch documentado
- Issues automáticas para críticos
- Dashboard patch compliance ativo
- Política exceções CRA publicada
- Exceções críticas aprovadas board
Checklist Release Gate
- SAST integrado
- DAST integrado
- Fuzzing (se aplicável)
- Gate bloqueia CVE crítico conhecido
- Relatório qualidade release arquivado
- Processo override exceção formal
Checklist Disclosure
- security.txt publicado
- Chave PGP acessível
- Página política disclosure publicada
- Canal reporte funcional (email/portal)
- Runbook triagem interna
- Ponto de contacto de segurança identificado
- Tempo resposta médio
<5 dias úteis
Checklist Reporte Exploração
- Critérios "explorada ativamente" definidos
- Script export JSON pronto
- Runbook notificação autoridade
- Matriz de comunicação a utilizadores
- Simulação concluída
- Evidência testes arquivada
Checklist Documentação Segurança
- Guia instalação segura
- Guia atualização + rollback
- Contacto segurança (security@)
- Support period documentado
- Data de fim de suporte comunicável
- Recomendações configuração endurecida
- Secção gestão de vulnerabilidades
- Versão e data
Checklist Supply Chain Física (se aplicável)
- Lista firmware/hardware
- Hashes/assinaturas verificados
- Canal atualização seguro
- Processo de validação integridade
- Registos auditáveis
Métricas-Chave
| Métrica | Definição | Objetivo Inicial |
|---|---|---|
| MTTP Crítico | Tempo médio até patch crítico | ≤15 dias |
| % SLA Cumprido | (Vulns patch dentro SLA) / total | ≥90% |
| Cobertura SBOM | % componentes identificados | ≥95% |
| Tempo Médio Resposta Disclosure | Receção → primeira resposta | ≤5 dias úteis |
| Gate Efetividade | Releases bloqueadas por CVE crítico | 100% bloqueadas |
| Exceções Críticas Ativas | Nº exceções críticas abertas | Tendência decrescente |
Artefactos a Manter (Data Room)
| Artefacto | Tipo | Frequência Atualização |
|---|---|---|
| Política Segurança Produto & CRA | Documento | Anual / quando requisito muda |
| Registo de Papéis CRA & Support Period | Documento | Por linha de produto / revisão de release |
| SBOM Releases | Ficheiros | Cada release major/minor |
| Dashboard Vulnerabilidades | Painel | Contínuo (live) |
| Relatórios Qualidade Release | Documento | Cada release |
| Guia Segurança Produto | Documento | Cada release major |
| Runbook Exploração Ativa | Documento | Anual / exercícios |
| Registos Disclosure | Tickets / Issues | Contínuo |
| Checklist Supply Chain | Documento | Trimestral |
Exceções (Política Resumida)
Categorias:
- Inaceitáveis: RCE crítico, bypass autenticação, exposure credenciais em claro
- Aceitáveis (TTL curto ≤30d): Crítico sem patch disponível + compensação robusta
- Aceitáveis (TTL médio ≤90d): High com mitigação parcial
Registos: ID | Vulnerabilidade | Severidade | Justificação | Aprovador | TTL | Mitigação | Data Revisão
Escalação: Crítico → Board; High → CISO/AppSec; Medium/Low → AppSec.
Próximos Passos Depois da Fase 9
- Avaliação formal conformidade (legal + técnico)
- Preparar documentação para eventual auditoria/regulador
- Integração com outras normas (ex: DORA, NIS2) - evitar duplicação
- Refinar métricas (MTTP por componente, densidade vulnerabilidades)
- Automatizar geração relatório trimestral CRA
Recursos Práticos de Implementação
Para suporte concreto na implementação deste playbook, consultar os seguintes exemplos reutilizáveis:
- 🛠️ Opções de Toolchain - Comparação de ferramentas SCA, SBOM e vulnerability management
- 📊 KPIs e Targets - Métricas de patching e SBOM coverage adaptáveis ao CRA
- 👥 RACI e Governance - Matrizes de responsabilidades para vulnerability handling
- 📝 Relatório de Incidentes - Template adaptável para reporte de exploração ativa (CRA)
Estes recursos demonstram implementações práticas das abstenções deliberadas do SbD-ToE.
Referências
- Análise normativa CRA
- SbD-ToE Capítulos 01–14
- ENISA: Vulnerability Disclosure Guidelines
- ISO/IEC 29147 & 30111
- CycloneDX, SPDX
Versão: 1.0
Data: Novembro 2025
Nota: Este playbook complementa a análise normativa CRA com abordagem sequencial prática e não substitui a rota formal de conformidade do regulamento.