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.
Secure CI/CD
Continuous integration and delivery (CI/CD) pipelines are today the backbone of software engineering.
Through them code flows, artefacts are built, validations are applied and versions are finally promoted to production.
If a pipeline is compromised, the impact is devastating: all the applications and services that depend on it inherit that risk.
This chapter starts from an unequivocal observation: the security of the pipeline is the security of the product.
Protecting the source code or the application runtime is not enough - it is the pipeline that guarantees that everything else reaches production in an intact, auditable and trustworthy form.
For this reason, SbD-ToE establishes here a prescriptive body for pipelines: how they must be designed, governed and audited to resist attacks, prevent failures and sustain organisational trust.
Canonical note (modern process).
A pipeline may automate execution and produce signals (results, scores, recommendations), but it does not replace human decision in irreversible actions (promotion, deploy, gate bypass).
Likewise, plausible outputs do not replace empirical evidence: evidence means observable execution (logs, run ids, exit codes, artefacts) and verifiable traceability.
🧭 What it covers technically
CI/CD security spans a broad set of technical and organisational domains:
- Definition and versioning of pipelines (YAML, scripts, templates)
- Execution environments: runners, agents and build containers
- Management of secrets and credentials used in jobs
- Integration of security scanners (SAST, IaC, secrets, containers, SBOM)
- Artefact signing and provenance to guarantee integrity
- Promotion policies and gates proportional to risk
- End-to-end traceability commit → pipeline → release
- Reproducibility and operational determinism sufficient for audit and incident investigation (including recording of the effective configuration used in the execution, without exposing sensitive data)
📌 What must be done
For CI/CD pipelines to be trustworthy and auditable, the organisation must:
- Harden and isolate runners per project, application or risk level.
- Integrate automatic scanners in phases proportional to the expected impact, ensuring that the results correspond to real and observable execution.
- Prohibit static secrets and replace them with OIDC, short-lived tokens and masked logs.
- Sign and record provenance of all artefacts and releases, with mandatory validation before promotion.
- Enforce promotion gates configured by risk classification (L1, L2, L3), keeping an explicit separation between automatic signal and promotion decision.
- Record exceptions in a formal, temporary and auditable way, with a defined owner, deadline and compensations.
- Guarantee complete traceability to support audits and incident response (commit → pipeline execution → artefact → release).
- Minimise context exposure in logs, intermediate artefacts and external integrations, treating any system outside the organisation's direct control as a dependency and a potential exfiltration channel.
⚙️ How it must be done
The technical mechanisms that make it possible to implement these practices include:
- Versioning of pipelines in Git repositories with review through PR
- Use of ephemeral, unprivileged and segregated runners
- Integration of tools such as
semgrep,trivy,cosign,scorecardand IaC/container scanners - Configuration of OIDC and short TTL for secrets, eliminating long-lived keys
- Automatic signing of artefacts and provenance in accordance with SLSA
- Structured retention of logs, metadata and commit→pipeline→release correlations
- Controlled recording of the effective execution configuration (without sensitive data), supporting reproducibility and audit
- Control of logging and debug (temporary and auditable activation), preventing exposure of secrets, sensitive data or intellectual property
📆 When to apply
The discipline of Secure CI/CD is not switched on occasionally: it accompanies the whole life of the project.
It must be applied:
- From the start of a new pipeline, even in MVPs
- Whenever releases are promoted to higher environments (in particular when the action is irreversible)
- When runners, tooling, gates or secrets are changed
- When any external dependency is integrated into the pipeline (scanners, services, repos, registries, etc.)
- In regular audits, to ensure traceability, reproducibility and compliance
👥 Who is involved
CI/CD security depends on distinct but complementary roles:
| Role/Function | Main contribution |
|---|---|
| Developer | Develop pipelines, react to findings and maintain code quality |
| DevOps / SRE | Harden runners, manage automation and apply operational controls |
| AppSec Engineer | Define policies, scanner thresholds and gates by risk |
| GRC / Compliance + Auditors | Verify traceability, exceptions and organisational compliance |
🎯 What for
- Prevent supply chain attacks exploiting insecure pipelines or runners
- Protect critical artefacts, ensuring that only trustworthy code is promoted
- Provide organisational trust, demonstrating traceability to managers, auditors and regulators
- Enable fast and secure releases, without compromising integrity or compliance
📜 Relevant Organisational Policies
| Organisational policy | Mandatory | Application | Minimum content |
|---|---|---|---|
| Secure CI/CD Policy | Yes | All projects | Review through PR, secure runners, mandatory scanners, secrets management, signing/provenance |
| Secrets Management Policy | Yes | DevOps / SRE, AppSec Engineer | OIDC/short TTL, prohibition of static secrets, periodic rotation |
| Traceability Policy | Recommended | GRC / Compliance, Auditors | Correlated commit→pipeline→release logs, minimum retention, immutable export |
| CI/CD Exception Management Policy | Yes | AppSec Engineer, GRC / Compliance | Formal record, approvals, deadline and compensations |
| Risk-Proportional Application Policy | ⚠️ Optional | Organisations with formal classification | Mapping between risk level and minimum controls required in the pipeline |
The relevant organisational policies are described in the Manual's Policies Annex, including: Secure CI/CD, Secrets Management, Traceability and Exceptions.