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, measurable and auditable execution.
The operational chapters explicitly assume the extensive use of automation in the modern SSDLC and address the risks introduced by the execution process itself, not only by the technology used.
Containers and Isolated Execution
Execution in containers has become the norm in CI/CD pipelines and in production.
This ubiquity has brought significant gains in agility and portability, but it has introduced new process risks when the building, validation and promotion of images come to be heavily mediated by automated pipelines.
Today, images are frequently derived, generated, recombined or promoted automatically, often without direct human intervention.
In this context, governance failures - and not only technical failures - become the dominant vector of compromise.
Real cases illustrate this risk: typosquatting attacks on public registries, secrets embedded in images exploited in Kubernetes environments (as in the Tesla Kubernetes breach, 2018), and supply chain incidents such as SolarWinds demonstrate that apparently valid artefacts can be operationally insecure.
This chapter therefore establishes the foundations for trustworthy, traceable and auditable execution, treating containers as complete software artefacts, subject to explicit human decision, independent validation and verifiable evidence throughout the entire cycle.
👉 The objective is not only to ensure that “the container runs”, but to ensure that it runs by conscious decision, with known risk and sufficient evidence.
The requirements prescribed here apply both to:
- pipeline images (builders, runners, technical jobs),
- and to application images executed at runtime (services, workloads, batch jobs).
In both cases, automation produces signals, not decisions.
Risk acceptance, promotion between environments and the authorisation of execution are non-delegable human responsibilities.
This chapter is directly linked with:
- Ch. 05 - Dependencies, SBOM and SCA, treating images as supply chain artefacts with verifiable provenance;
- Ch. 07 - Secure CI/CD, where the pipeline is recognised as a critical risk actor;
- Ch. 12 - Monitoring and Operations, which ensures detection and response at runtime.
🧭 What it covers technically
Container security depends on a continuous chain of controls, from the design of the pipeline to execution in production.
Any break in this chain compromises overall trust.
This chapter covers, in an integrated way:
- Selection, validation and deterministic pinning of base images.
- Execution in controlled environments (builders, runners, clusters).
- Signing and verification of provenance (e.g. SLSA, Sigstore).
- Runtime hardening (non-root, minimal capabilities, read-only FS).
- Execution and admission policies (OPA, Kyverno).
- Secure integration with Kubernetes (RBAC, dedicated ServiceAccounts, NetworkPolicy).
- Generation of SBOM and commit → pipeline → image → execution traceability.
These practices do not replace human decision; they provide technical evidence that supports that decision.
🧪 Governance pillars
Without explicit governance, automation quickly degrades into implicit trust.
This chapter defines minimum pillars that guarantee continuous operational discipline:
- Registry allowlist and execution by digest, preventing silent substitutions.
- Secrets management outside the image, with ephemeral and auditable credentials.
- Minimal RBAC and dedicated ServiceAccounts, never the default SA at L2/L3.
- NetworkPolicies with controlled egress, limiting the blast radius.
- Golden Base Images per stack, with a patching and discontinuation SLA.
- Ephemeral, minimal and signed builders and runners, protecting the build chain.
🔬 In L3 contexts, reinforced controls also apply, such as advanced isolation (gVisor, Kata, Firecracker), drift detection and staged promotion with explicit approval.
⚙️ How it must be done
Secure practice requires formal, repeatable and auditable mechanisms.
“Plausible” or “green” results do not replace empirical validation.
In a non-exhaustive way:
- Use minimalist, maintained and verified base images.
- Sign images and verify provenance before execution.
- Integrate scanners into CI/CD as a signal, with gates defined by policy.
- Run containers with minimum privileges.
- Apply admission policies on origin, digest, identity and context.
- Generate an SBOM at every build and link the results to the pipeline.
- Keep auditable records of the acceptance and promotion decision.
These steps are mandatory because they reduce uncertainty, not because they eliminate risk.
📆 When to apply
The controls must exist from the design of the pipeline and be maintained throughout the cycle:
- Design and evolution of CI/CD.
- Selection and maintenance of base images.
- Every build and release.
- Before any promotion or deploy.
- After critical CVEs or structural changes.
Continuous application avoids the silent accumulation of risk.
👥 Who is involved
Container security is cross-cutting:
| Role | Main responsibility |
|---|---|
| DevOps / SRE | Define approved images, secure runners and enforcement |
| Developer | Use validated images and integrate controls into manifests |
| AppSec Engineer | Validate the chain of trust and analyse technical signals |
| DevOps / SRE | Guarantee isolation and policies in the cluster |
| GRC / Compliance | Maintain evidence, traceability and policies |
The absence of any one of these roles compromises the entire chain.
🎯 What for
Insecure containers directly compromise organisational integrity.
This chapter makes it possible to:
- Prevent the execution of tampered code.
- Reduce the attack surface in the pipeline and in production.
- Support audits with verifiable evidence.
- Meet requirements such as NIS2, SSDF and SLSA.
- Respond quickly to incidents at runtime.
Agility is only an advantage when accompanied by operational trust.
🧮 Proportional application L1–L3
Not all applications need the same level of control, but all of them need some.
Proportionality makes it possible to balance cost, risk and complexity:
| Practice | L1 (low) | L2 (medium) | L3 (high/crit.) |
|---|---|---|---|
| Image scanner | Warning | Blocking High/Critical | Blocking Medium+ |
| Signing + SLSA | Recommended | Recommended | Mandatory |
| Digest-only / allowlist | Warning | Blocking by origin | Blocking + digest-only |
| Secrets outside the image | Recommended | Mandatory | Mandatory + automatic rotation |
| Dedicated RBAC/SA | Recommended | Mandatory | Mandatory + periodic review |
| NetworkPolicy egress | Basic ingress | Ingress + critical egress | Ingress + full egress + audit |
| Golden base + patch SLA | Recommended | Mandatory | Mandatory + accelerated rollout |
| Ephemeral builders | Recommended | Mandatory | Mandatory + network segmentation |
| Sandboxes (gVisor/Kata) | - | - | Recommended for sensitive data |
| Drift & staged promotion | - | - | Mandatory in regulated environments |
📜 Relevant Organisational Policies
Formal policies give these practices sustainability.
They ensure that the practices do not depend solely on individual discipline, but on collective and auditable rules.
| Organisational policy | Mandatory | Application | Minimum content |
|---|---|---|---|
| Secure Containers Policy | Yes | All projects | Allowlist + digest-only, scanners, signing/provenance, RBAC/SA, NetworkPolicy |
| Secrets Management Policy | Yes | DevOps / SRE, AppSec Engineer | OIDC/short TTL, prohibition of secrets in the image, rotation |
| Traceability Policy | Recommended | GRC / Compliance | commit→pipeline→deploy logs, retention, immutable export |
| Golden Base Images Policy | Yes | DevOps / SRE, AppSec Engineer | Catalogue, patching SLA, deprecation |
| Secure CI/CD Policy — Builders/Runners | Recommended | DevOps / SRE | Ephemeral, minimal, signed, controlled cache |