SbD Enablement

Comece com Assess & Roadmap.

Primeiro, diagnosticamos a maturidade Security by Design, expomos gaps silenciosos e priorizamos o que vale a pena fazer. Só depois se decide Build, Run, My KG ou My MCP.

§01 — O pipeline (o motor)

O método de produção de conhecimento — produtizado.

31 normas externas decompostas → normalizadas no AppSec Core (CO·P·M·EP), coverage-preserving, SHACL-validado, servido no point of execution pelo MCP. A oferta comercial é correr esse mesmo pipeline na organização.

01

Normalizar as normas internas

Políticas, standards, decisões de arquitetura, guidelines de código e runbooks ingeridos e normalizados no mesmo substrato AppSec Core. Coverage-preserving. Cada claim traça à fonte interna.

02

Configurar o manual custom

Seleção das partes do manual público SbD-ToE aplicáveis — por perfil de risco (L1/L2/L3), stack e contexto regulatório. Resultado: manual custom = substrato público + selecção da organização.

03

Entregar no point of execution

O resultado é servido às pessoas e aos agentes da organização no momento da decisão — IDE, PR, pipeline. As regras próprias, com os IDs próprios, entregues a quem precisa, e quando.

normas internas+manual públicoAppSec CoreMy KGMy MCProles & agentes (point of execution)

As políticas internas saem da wiki e passam a ser conhecimento acionável por máquina, entregue no ponto de mudança com a mesma rastreabilidade do manual público. Construímos sobre o substrato aberto e adaptamo-lo à realidade da organização.

§02 — Como se contrata

Três linhas. Um bundle. Uma espinha.

Assess & Roadmap → (escolher iniciativas) → Build → (plano acordado) → Run. Build-to-Run embrulha a espinha toda.

Assess & Roadmap(escolher iniciativas)Build(plano acordado)Run
Linha 1 · Advisory

Assess & Roadmap

Projeto · âmbito fixo · tempo & preço

Porta de entrada, baixo compromisso. Diagnostica a maturidade, expõe os gaps em silêncio, prioriza o que faz diferença primeiro.

  • Maturidade vs SbD-ToE — onde estão os controlos em silêncio
  • Iniciativas priorizadas com esforço e custo
  • Plano faseado, defensável internamente
Entregável
Relatório de gaps + roadmap priorizado.
Pré-requisito
Sem pré-requisitos.
Falar sobre Assess & Roadmap
Linha 2 · Implementation

Build

Projeto · âmbito fixo · tempo & preço

Executa o que o roadmap escolheu. Normaliza as normas internas no Knowledge Graph, põe de pé o MCP custom, instala o operating model e integra no SDLC.

  • My SbD Knowledge Graph (pipeline coverage-preserving, SHACL)
  • My MCP Tools no point of execution — IDE, PR, pipeline
  • Operating model + capacitação por role
Entregável
Iniciativas a funcionar em produção + plataforma (My KG + My MCP) viva.
Pré-requisito
Requer Assess & Roadmap.
Falar sobre Build
Linha 3 · Managed service

Run

Retainer · subscrição · recorrente

O programa AppSec/SbD operado como serviço: governa a documentação, gere as áreas, operacionaliza as equipas, mede a postura e mantém a plataforma current.

  • Cadências, revisões, exceções, champions
  • KG e MCP mantidos current (re-pin, smoke, deploy governado)
  • Postura medida — não declarada
Entregável
Programa de segurança vivo, medido e gerido — conforme o plano de Run acordado no roadmap.
Pré-requisito
Requer Build (ou um Build-to-Run integrado).
Conhecer o Run
Bundle flagship

Build-to-Run

Assess + Build delimitado · transição para Run

A jornada integrada num só wrapper: do diagnóstico a um programa gerido a correr. Para quem quer o caminho completo, comprometido à partida.

  • Assess + Build como um projeto único, delimitado
  • Transição governada para Run segundo plano acordado
  • Um único contacto comercial e técnico
Entregável
Programa de segurança a correr, da maturidade inicial à operação contínua, num só engagement.
Pré-requisito
Sem pré-requisitos. Embrulha a espinha toda.
Falar sobre Build-to-Run
§03 — O âmbito (os módulos)

Seis módulos. Cada Build/Run cobre os que o roadmap priorizou.

§01

Secure SDLC Assessment

Maturidade da organização mapeada ao SbD-ToE — dos Fundamentos à Governança. Diagnóstico que cruza pessoas, processo e plataforma com o substrato AppSec Core.

Resultado
Imagem honesta de onde a organização está e onde os controlos caem em silêncio.
Entregável
Relatório de gaps por capítulo e por role + plano de adopção faseado, com esforço e custo por iniciativa.
Cap. 00–14
§02

Norm Normalization — o pipeline

Políticas, standards, decisões de arquitetura e runbooks internos decompostos e normalizados no AppSec Core. Coverage-preserving: nada cai em silêncio, cada claim traça à fonte interna. É o mesmo pipeline que construiu o manual público — aplicado ao corpus da organização.

Resultado
As regras internas deixam de viver numa wiki que ninguém lê e passam a ser machine-actionable.
Entregável
Knowledge Graph v1 da organização — normas internas com IDs rastreáveis no namespace próprio, SHACL-validado, release imutável.
Pipeline · AppSec Core · SHACL
§03

MCP & Agentic Adoption

Rollout do MCP custom a servir o KG privado. Integração nos IDEs, nos PR bots e nos pipelines. Role-skills geradas para os roles da organização — regeneram quando a fonte muda. Snapshots privados; o KG nunca sai do perímetro.

Resultado
As regras próprias chegam a quem precisa, no momento da decisão — não em slides, não em wikis.
Entregável
Servidor MCP a servir o KG no point of execution + role-skills instaladas + lifecycle gerido (re-pin, smoke, deploy).
MCP · Role-skills · Lifecycle
§04

AppSec Operating Model

RACI, governança, cadências, exceções e champions. State layer de postura e atestação persistente — o que está implementado, o que tem evidência, o que expira quando.

Resultado
A segurança passa a ter dono, ritmo e medida — não fica refém de heróis pontuais.
Entregável
Operating model documentado + KPIs e gates definidos + state layer operacional, ligado ao KG e ao MCP.
Cap. 12 · 14
§05

Regulatory Enablement

DORA, NIS2, CRA e GDPR levados ao point of execution através de regulatory_activation — a obrigação aponta para as áreas do manual e a evidência traça à fonte. AI Act em indexação; PCI-DSS via overlay corporativo. Cross-check ≠ declaração de conformidade.

Resultado
A auditoria deixa de ser uma corrida no fim do ciclo. A obrigação está activa no commit certo.
Entregável
Cross-check norma → áreas + padrões de evidência técnica + integração no operating model. A aprovação fica do lado de quem tem a autoridade.
Cross-check · §regulatory
§06

Training & Enablement

Workshops por papel — Architect, Developer, AppSec, QA, DevSecOps, Product — ancorados em Formação e Onboarding e nas role-skills do MCP. Não é formação genérica: é a regra interna, com o ID interno, no contexto real.

Resultado
Equipas capacitadas a partir do mesmo substrato que o MCP serve — sem desalinhamento entre o que se aprende e o que se aplica.
Entregável
Workshops entregues por role + role-skills instaladas + playbooks de onboarding contínuo.
Cap. 13
§08 — Princípio Honesto

cross-checkcompliance.

Similaridade ≠ aplicabilidade. A IA não cria autoridade.

Damos-te evidência técnica determinística e mapeamentos rastreáveis às normas (NIS2, DORA, CRA, GDPR; AI Act em indexação). Não fingimos o veredicto regulatório — esse continua a ser dado pelo auditor com mandato. Esta honestidade é o que torna o substrato confiável.

NIS2DORACRAGDPRENISA-CSAAI Act (indexing)
A linha honesta

Cross-check ≠ declaração de conformidade. A autoridade fica com quem a tem.

A ShiftLeft entrega o substrato, o pipeline e a plataforma. A IA não cria autoridade — propõe, decompõe, mapeia. As normas internas são aprovadas por humanos da própria organização. Vende-se rigor produtizado, não rótulos.

Começar pelo Assess & Roadmap.

Baixo compromisso, alta clareza. Em poucas semanas, a organização sabe onde estão os controlos em silêncio e qual a primeira iniciativa que paga o caminho.