Security & Compliance in CI/CD

Security in CI/CD is not just about scanning code - it’s about controlling who can act on pipeline resources, what those actions can produce, and proving the integrity of every artifact that reaches production. This matters especially in regulated industries, but these controls are good engineering practice for any team.

---

Pipeline Telemetry

Telemetry is what makes advanced deployment strategies - Canary rollouts, A/B tests, drift detection - actually work. Without measurable signals, you can’t know if a deployment is succeeding or failing.

Telemetry spans five phases of the pipeline:

Phase	What to measure
Code	PR review time, branching frequency, code coverage, merge conflicts
Build	Artifact build time, dependency download duration, SBOM generation, vulnerability count
Test	Test suite size, failure rate, flaky test rate, test duration
Deploy	Pipeline execution time, deployment duration, environment provisioning time, rollback frequency
Post-deploy	Error rates, incident frequency, user behavior signals, live performance metrics

Two open standards normalize this data across heterogeneous toolchains:

• CDEvents - A specification for event categories emitted across all pipeline phases (Source Code Control, CI, CD events). SDKs integrate with common build and deployment systems, ensuring signals are collected uniformly regardless of the underlying tool.
• SLSA (Supply-chain Levels for Software Artifacts) - A security-focused standard for build-phase telemetry. Covers artifact provenance and SBOM generation, allowing teams to answer “where did this artifact come from and what’s in it?”

Note

CDEvents and SLSA are complementary, not competing. CDEvents handles operational telemetry across the full pipeline; SLSA handles security provenance specifically at the build phase. Both together give a complete picture.

Access and Policy Management

CI/CD pipelines touch production systems. Without strict access controls, a misconfigured permission or a well-meaning shortcut can bypass the safeguards your deployment strategies were designed to provide.

Segregation of Duties (SoD)

SoD divides critical tasks across different individuals or systems so that no single person has end-to-end control over the pipeline. A typical SoD model:

Role	What they can do
Developer	Commit code, open pull requests
QA Team	Approve builds, run test sign-off
Release Manager	Tag versions, approve production deployments
Operations Team	Monitor live environment, trigger rollbacks

No single role crosses into another. A developer cannot approve their own PR to production; a release manager cannot modify test results.

Role-Based Access Control (RBAC)

RBAC enforces SoD programmatically by answering: “Who can perform what actions on which resource?” Rather than managing permissions per individual, RBAC assigns permissions to roles - groups of related responsibilities - and attaches users to those roles.

A typical CI/CD RBAC hierarchy:

Role	Their project	Other projects
Platform / SRE Team	Full admin - manage runners, secrets, platform config	Read access across all projects for visibility
Team Lead	Manage pipelines, approve deployments, configure environments	Read access to observe other teams’ pipelines
Developer	Trigger pipelines, update pipeline config, read logs	Read access only - cannot modify other teams’ pipelines

Tip

The cost of implementing a granular RBAC model is upfront design complexity. The payoff at scale is enormous: onboarding a new team means assigning them a role, not auditing a list of individual permissions. Access drift - when people accumulate permissions over time - is also eliminated.

Examples in practice:

• The QA team has pipeline run permissions on staging - but not production.
• Only Release Managers can approve deployment to the main branch.
• Developers can read pipeline logs but cannot modify environment configurations.

RBAC prevents the most common pipeline accidents: accidental production deploys and untested code bypassing staging.

Approval Flows

For high-risk actions that automated checks alone cannot validate, approval flows act as explicit human gates. Common use cases:

• Merging to a protected branch (e.g., release/)
• Emergency hotfixes to live production
• Infrastructure changes above a defined cost threshold

Approval flows integrate directly into pipeline definitions and block execution until a designated reviewer signs off.

Open Policy Agent (OPA)

Where RBAC controls who can act, OPA controls what those actions can produce. OPA is an open-source policy engine that evaluates declarative rules tied to pipeline events.

OPA can be hooked into any pipeline phase:

• Build phase: Deny a build if it violates semantic versioning schema or lacks required metadata tags.
• Deploy phase: Reject a deployment if the artifact was not signed or doesn’t have an SBOM attached.
• Infrastructure phase: Block a Terraform plan if it would expose a security group to 0.0.0.0/0.

Tip

OPA is used natively by Kubernetes (admission controllers), Terraform, and Envoy - making it a natural fit for pipeline policy enforcement in cloud-native stacks. A single OPA policy definition can span multiple tools in the same delivery chain.

---

Domain-Driven CI/CD

Domain-Driven Design (DDD) is a software design approach that organizes code around the actual complexity of the problem it is solving - not around technical layers. It enforces a shared vocabulary (ubiquitous language) across developers, domain experts, and stakeholders, and divides large problem spaces into clearly bounded independent areas (bounded contexts).

In a CI/CD context, DDD maps perfectly: each bounded context becomes a deployable microservice with its own pipeline, tests, and deployment lifecycle. The organizational boundary and the deployment boundary match.

The Three Layers of a Domain-Driven Pipeline

Layer	What it covers
Domain	Core DDD concepts - ubiquitous language, bounded contexts, shared kernels, aggregates, domain events
CI	Static analysis, automated unit and integration tests, artifact creation
CD	Environment provisioning, configuration management, system testing, controlled production release

Why DDD Improves CI/CD Outcomes

Benefit	What it means in practice
Improved communication	Shared ubiquitous language bridges the gap between developers and domain experts - requirements are less likely to be misunderstood in code
Reduced coupling	Bounded contexts prevent logic from bleeding across domains, reducing the blast radius of any single change
Targeted scalability	CI/CD processes align with domain boundaries, so individual services scale independently without touching the broader system
Faster and safer delivery	CI/CD pipelines per bounded context support feature toggles, canary releases, and blue-green deployments per service, not per monolith
Simplified troubleshooting	When an issue occurs, the bounded context that owns it is immediately clear

Caution

DDD adds architectural complexity upfront. Only apply it when the business logic is genuinely complex - multiple interacting rules, regulated data, intricate domain workflows. For simple CRUD services, standard patterns are the right tool.

---

Regulation Actions in Pipelines

Regulation actions - code reviews, security scans, compliance audits, mandatory approvals - are required in regulated sectors but create natural friction in CI/CD. They involve manual intervention or external verification, which conflicts with the CI/CD goal of fast, frequent delivery.

DDD offers a structured way to integrate compliance without destroying pipeline velocity, by applying five core principles:

DDD Principle	Role in compliance
Ubiquitous Language	Regulatory requirements are named and documented in the same terms used in code and pipeline configuration - making automation of compliance checks unambiguous
Bounded Contexts	Regulation actions are scoped to specific contexts, avoiding system-wide compliance bottlenecks. Rigor is calibrated to the context’s actual regulatory exposure
Strategic Design	Categorizes the domain into core, supporting, and generic subdomains. Ensures compliance effort is proportional to business risk - avoiding over-engineering in low-risk areas
Context Mapping	Visualizes how compliance controls in one context interact with - or depend on - adjacent contexts. Identifies and resolves cross-boundary compliance risks
Domain Events	Compliance-relevant actions emit domain events that automatically trigger downstream regulatory checks. The event log becomes the audit trail

These principles form a feedback chain: ubiquitous language shapes bounded contexts → bounded contexts inform strategic design → strategic design drives context mapping → context mapping identifies gaps that refine bounded contexts.

---

Access Control in Regulated Domains

In regulated sectors, access control is not a bolt-on feature - it is woven into the domain model itself. The domain layer owns business logic; the application layer acts as a policy enforcement point that decides what each actor is allowed to do.

RBAC vs ABAC

Pattern	How it works	Best for
RBAC	Permissions are tied to organizational roles (Developer, Compliance Officer, Release Manager). Role changes update permissions automatically.	Large organizations with defined role hierarchies
ABAC	Permissions are evaluated dynamically against a set of attributes - user characteristics, resource type, action, and environment context (e.g., time of day, data classification).	Highly regulated domains requiring fine-grained, context-sensitive access

Embedding Access Control into DDD Components

DDD Component	How it enforces access
Entities and Value Objects	Access rules are part of the model itself - a PatientRecord entity knows which roles can read or modify it
Aggregate Roots	Act as transaction boundaries and security boundaries. All operations on an aggregate are checked before they are committed
Repositories	Return only the objects the caller is authorized to interact with - unauthorized data never enters memory
Bounded Contexts	Each context defines its own access policy, preventing unauthorized access from propagating across domain boundaries

Note

In a healthcare implementation, this looks like a Policy Evaluation Engine that evaluates access rules at runtime using the caller’s roles + permissions

• the sensitivity classification of the requested resource. Denied accesses are logged to a Secure Audit Trail for HIPAA compliance review.

---

Building Compliant Artifacts

Compliance belongs in the pipeline configuration, not in a spreadsheet reviewed the week before an audit. Building compliant artifacts means embedding regulatory requirements into every stage of the CI/CD process.

Step	What to do
1. Compliance requirements analysis	Identify the applicable regulations - GDPR, HIPAA, PCI DSS, FedRAMP. Document exactly what each mandates regarding encryption, access, logging, and data residency.
2. Compliance-aware domain modeling	Design entities and aggregates with data encryption, access control, and audit logging as first-class properties - not added afterward.
3. Pipeline configuration	Integrate compliance checks into the pipeline as non-negotiable gates: SAST (SonarQube), DAST (OWASP ZAP), dependency scanning, ComplianceAsCode.
4. Compliance-specific automated tests	Write tests that validate encryption behavior, access control logic, and data protection rules - not just functional behavior.
5. Continuous monitoring and reporting	Auto-generate audit logs and compliance reports on every pipeline run. Violations surface immediately, not at audit time.
6. Deployment access controls	Enforce RBAC and mandatory approval workflows for environment promotions. No manual intervention bypasses the policy engine.
7. Documentation and traceability	Maintain a clear chain from regulatory requirement → implemented feature → automated test → deployed artifact.
8. Continuous adaptation	Regulations change. Build review cycles into the team’s calendar and update pipeline gates when requirements shift.

---

DDD in Regulated Industries

DDD is particularly valuable in industries where software failures have legal, financial, or safety consequences:

Industry	DDD application
Financial services	A payment processing bounded context is completely isolated from account management and fraud detection. Domain services, aggregates, and value objects encode complex financial rules within that boundary.
Healthcare	Context mapping separates patient records from treatment protocols - each with its own ubiquitous language and domain events. HIPAA controls are enforced at the bounded context boundary, not scattered across the system.
Government / Public sector	Domain-driven structure separates license application processing from compliance checking. Strategic and tactical DDD patterns produce architectures that meet current regulatory requirements while remaining adaptable to future legislation.

---

Performance Considerations

DDD adds modeling depth. CI/CD demands delivery speed. This tension is real and must be managed deliberately.

Common pitfalls:

Pitfall	What it looks like
Overly complex domain models	Models become so granular that each integration test run takes minutes instead of seconds; the pipeline slows to a crawl
Underestimated learning curve	Teams struggling with DDD concepts slow down delivery and introduce inconsistencies in the bounded context boundaries
Communication gaps	The pace of CI/CD outstrips the pace of domain workshops; the code diverges from the current business reality

Mitigation strategies:

• Design for modular, independently testable components - each bounded context should be testable in isolation without running the entire system
• Promote the same artifacts at every stage - no rebuilding between environments; what was tested in staging is exactly what ships to production
• Commit frequently and in small units - the feedback loop only works if the feedback arrives fast; large commits delay diagnosis

---

Practical Implementation Guide

Implementing DDD in a CI/CD pipeline requires deliberate alignment between software design and business requirements:

Step	Action
1. Understand the domain	Work with domain experts to map business processes. Define a ubiquitous language that is reflected in variable names, event names, and test descriptions.
2. Define bounded contexts	Partition the domain model into logically independent segments. Each context becomes its own deployable microservice with its own database.
3. Automate domain-specific testing	Every commit triggers builds and tests. Include tests that validate business behavior - not just that the code compiles and the API returns 200.
4. Use feature toggles for continuous deployment	Deploy every successfully tested artifact to staging or production. Feature toggles decouple deployment from release - new behavior ships dark until the business is ready to expose it.
5. Implement observability	Track domain event flow in production. When observed behavior diverges from expected behavior, feed that back into domain model refinement.
6. Build a continuous learning culture	Schedule regular domain workshops and retrospectives. The domain model is a living document - it evolves as the business evolves.
7. Version control the domain model	Track changes to bounded context definitions and interface contracts alongside code. The main branch always reflects the current canonical domain model.