Capítulo Operacional
This chapter is considered operational in the Security by Design - Theory of Everything (SbD-ToE) model. Its function is to apply, automate and validate the practices defined in the foundational chapters, guaranteeing their continuous and measurable execution.
The operational chapters implement SbD-ToE in specific technical contexts. These chapters translate the foundational prescriptions into practices of verifiable execution, promoting the continuous integration of security throughout the software lifecycle.
Dependencies, SBOM and SCA
The use of Open Source Software (OSS) and third-party libraries is common and recommended: it accelerates delivery and avoids reinventing the wheel.
However, without governance, material risks arise: abandoned components, known CVEs, malicious packages and a lack of visibility over the supply chain.
This chapter establishes operational foundations for secure, traceable and auditable dependency management, including:
- SBOM updated per build,
- SCA integrated into CI/CD with gates,
- governance of exceptions,
- prohibition of libraries copied manually into the repository, and
- update automation with impact assessment (bots that open PRs when the change is safe and request human intervention when there is impact on the code).
The requirements described here apply to any stack/language.
They focus on ensuring that:
- every dependency is known, approved and traceable,
- every build produces a complete SBOM,
- vulnerabilities are detected and triaged,
- updates are automated with impact analysis (semver, release notes, changelogs, tests and static call graphs),
- no library enters “by manual copy” outside the package manager.
⚠️ Normative note - Limits of the dependency inventory
The SBOM represents the best possible approximation of a system's composition at a given moment, but does not constitute an absolute truth.
Dependencies may be introduced indirectly or emergently (e.g. tooling, pipelines, code generation, runtime loading).
This chapter prescribes explicit practices to define inventory boundaries, detect deviations and govern unintended dependencies, ensuring effective control of the software supply chain.
Links to other chapters:
- Ch. 02 - Security Requirements (REQ-DEP-xxx),
- Ch. 07 - Secure CI/CD (pipelines and gates),
- Ch. 09 - Containers (images as supply chain artefacts),
- Ch. 14 - Governance (requirements placed on suppliers).
🧭 What it covers technically
- Secure management of dependencies (OSS, commercial, internal).
- Generation and maintenance of SBOM (CycloneDX/SPDX).
- Integration of automated SCA into CI/CD.
- Formal process for exceptions and risk acceptance.
- Internal repositories as the single source of trust.
- Prohibition of locally copied dependencies (JS, PHP, DLLs, JARs, etc.).
- Update automation with impact assessment (Renovate/Dependabot/similar):
- automatic PRs when the impact is nil/low (compatible semver patch/minor, green tests),
- handoff to human intervention when there is impact (major/breaking, changed APIs).
🧪 Governance pillars
- Approved internal repositories as the single source.
- Dependency policy with approval criteria and pinning.
- SBOM per build, versioned and accessible.
- Automatic SCA with gates by severity and criticality (L1–L3).
- Formal exceptions with a deadline and compensating mitigation.
- Periodic audits to prevent manually copied libraries.
- Update automation with impact assessment and integration into tests/gates.
⚙️ How it must be done
- Configure package managers to use only internal repositories.
- Generate an SBOM on every build (CycloneDX/SPDX); archive it.
- Integrate SCA with automatic blocking for critical CVEs (thresholds per Lx).
- Formalise exceptions (e.g.
excecoes.yaml) and review them periodically. - Enable update bots with:
- analysis of semver, release notes and diffs,
- execution of tests and validations (CI),
- “auto-merge” PRs conditioned on proven no-impact,
- a “requires-human” label when there is impact on the code (breaking).
- Remove manually copied libraries and replace them with declared dependencies.
📆 When to apply
- Start: policy and configuration of internal repositories.
- New dependency: review of origin/licence/maintenance/CVEs.
- Build: generate SBOM + run SCA.
- Release: validate findings and exceptions.
- Regular cycle: update dependencies (bots) and review findings.
- Critical CVE: assess impact and remediate affected versions.
👥 Who is involved
| Role/Function | Main contribution |
|---|---|
| Developer / Lead | Adding dependencies, initial triage, pinning, fixes |
| AppSec Engineer | Policies, tuning, gates, exceptions and risk review |
| DevOps / CI/CD | SBOM, SCA, internal repositories, update bots |
| QA | Evidence, regression tests, validation of bot PRs |
| Product Owner | Go/no-go decision in the face of findings/residual risk |
| GRC / Management | Audit, compliance, evidence retention |
🎯 What for
- Reduce the risk of vulnerable/abandoned components.
- Guarantee traceability and a rapid response to CVEs.
- Accelerate time‑to‑fix with bots that assess impact, automate safe PRs and request human intervention when necessary.
- Avoid hidden risks (manually copied libraries).
- Comply with SSDF, SLSA, NIS2 and good market practice.
🧮 Proportional application L1–L3
| Practice | L1 (low) | L2 (medium) | L3 (high/crit.) |
|---|---|---|---|
| SBOM | Basic per build | Complete per release | Signed + integrity verification |
| SCA | Warning | Blocking High/Critical | Blocking Medium+ |
| Pinning | Recommended | Mandatory | Mandatory + verified provenance |
| Exceptions | Simple | Formal + periodic review | Formal + executive validation |
| Internal repository | Recommended | Mandatory | Mandatory + signature/verification |
| Locally copied libraries | Prohibited (policy) | Periodic audit | Enforcement in CI/CD |
| Update bots | Optional | Active with auto‑PR and no‑impact merge | Active + impact analysis + canary + gates |
📜 Relevant Organisational Policies
| Policy | Mandatory | Application | Minimum expected content |
|---|---|---|---|
| Dependency Policy | Yes | All projects | Approval criteria, pinning, external blocking |
| SBOM Policy | Yes | All builds | CycloneDX/SPDX, versioning, retention |
| CVE Exceptions Policy | Yes | Critical projects | Justification, deadline, compensating mitigation |
| Dependency Policy — Local Libraries | Yes | All repositories | Prohibition of local JS/PHP/DLL/JAR outside a package manager |
| Automatic Dependency Update Policy | Yes | L2–L3 | Active bots, impact analysis, auto‑merge criteria, human handoff |
| Exception Management Policy | ⚠️ Optional | All projects | Formal process for exceptions to supply chain requirements: justification, deadline and approval |
In the printed version, consult the Manual's Policies Annex, where these policies are consolidated across the board.