Systematic Control of the SbD-ToE Practices
This document defines the model for the systematic and continuous control of the application of the practices prescribed across all the chapters of the manual Security by Design - Theory of Everything (SbD-ToE).
📌 The objective is to ensure that all security practices are effectively applied, traced, validated and audited per application, over time.
🧭 Governance of practices by technical domain
| Chapter / Technical Domain | Expected Governance Mechanisms | Examples of Evidence / KPI |
|---|---|---|
| Ch. 02 - Requirements | Validation of the application by L1–L3, exception management, traceability evidence | Checklist applied, % of REQ applied / justified |
| Ch. 03 - Threat Modelling | Execution per milestone, defined owner, periodic update | Models per application, review history |
| Ch. 05 - Dependencies and SBOM | Automatic generation of SBOM, SCA analysis, record of findings | Findings reports, % resolved and justified |
| Ch. 07 - Secure CI/CD | Validation of pipelines, tracing of executions, bypass control | Audited executions, formal bypass approvals |
| Ch. 08 - Secure IaC | Continuous validation of modules, owners per environment, traceability | Issues + owners per resource, % of modules validated |
| Ch. 09 - Containers and Images | Application of image policies, origin and signature validations | Validated catalogue, scanner evidence |
| Ch. 10 - Security Testing | Execution by L1–L3, findings management, periodic revalidation | Test evidence, resolution plan |
| Ch. 11 - Deployment and Execution | Runtime validation, isolation, controlled executions | Execution control, versioned logs |
| Ch. 13 - Training and Third Parties | Verification of training by profile, onboarding with validation | List of training by function, onboarding checklist |
🧩 Format of the control per application
Each application must have a compliance repository, with:
- Binary checklist per chapter (
20-checklist-revisao.md) - Application status per practice (yes / exception / not applicable)
- Evidence of validation and approval
- History of changes and decisions
- Identification of the person responsible for accepting the status of each practice, when supported by automated validations.
⚠️ There must be traceable and versioned files (e.g.
.yaml,.md, GRC dashboards).
🔁 Continuous validation cycle
| Phase | Expected action |
|---|---|
| 🧱 Project start | Activate control mechanisms and owners per practice |
| 📥 Integration of changes | Review the status of the impacted controls |
| 🚀 Pre-release | Verify compliance and justified exceptions |
| 📊 Audit / review | Validate the overall status by chapter and domain |
📡 Supervision, KPIs and Escalation
-
The status of the practices must be consolidated in operational dashboards with:
- % of practices fulfilled per application / team
- Open exceptions per chapter
- Average revalidation cycle
-
Persistent failures must be reported to risk management or GRC with an action plan.
✅ Conclusion
This model makes it possible to:
- Govern the adoption of SbD-ToE in a continuous, transparent and auditable way
- Consolidate security information from all applications in a single point
- Support decisions, audits and the evolution of maturity based on evidence
📌 This control is the basis of the comprehensive governance of application security, and must be activated by all the teams that adopt SbD-ToE.