Editor’s Note: The following is an article written for and published in DZone’s 2026 Trend Report, Security by Design: AI Defense, Supply Chain Security, and Security-First Architecture in Practice.

DevSecOps means security is part of software delivery from the beginning, where security is built into planning, coding, building, testing, releasing, and operations. As pipelines become faster and more automated, security checks should run inside the CI/CD pipeline and be enforceable across delivery.

This hands-on, pattern-driven guide shows how a security-first CI/CD pipeline works in practice — from early scanning to Policy-as-Code enforcement, SBOM-based supply chain visibility, securing identities and access, zero trust, and safe remediation with evidence.

Pipeline Baseline: Define the Path and Risk Tiers

CI/CD pipelines automate code integration, testing, packaging, and deployment, helping teams move faster. But a single weak point can affect the whole process. Common risks include secrets in code or config files, weak access control, vulnerable dependencies or third-party tools, supply chain threats, sensitive data in non-production environments, and poor monitoring or visibility. When security is built into the CI/CD flow, we can identify risks earlier, improve control, and increase trust in the software we release. See NIST guidance on DevSecOps CI/CD pipelines for more information.

The base of a secure CI/CD pipeline is simple: scan early, protect access, secure secrets, check infrastructure, reduce supply chain risk, and enforce controls before release. A common path moves from development (fast feedback) → staging (broader validation and release checks) → production (strongest gates).

Figure 1. Secure CI/CD pipeline

Stronger gates should be reserved for higher-risk changes, such as production deployments, privileged infrastructure changes, dependency updates, access control changes, and shared platform changes. This keeps routine work moving quickly while adding tighter control where risk is higher.

To assess pipeline effectiveness, we can track practical key performance indicators (KPIs) for speed, quality, security, and pipeline health.

Stage 1: Shift-Left Scanning That Doesn’t Become Noise

We should scan the main objects early in the pipeline, including source code, third-party dependencies, secrets and credentials, container images, IaC templates, running applications, and pipeline configuration files. Early scanning helps detect common security issues before they move further into the delivery process.

We use different scans for pull requests (PRs) and the main branch. In PRs, the goal is quick feedback, so we focus on core checks such as secrets, code, dependency, and basic IaC scanning to catch problems before code is merged. In the main branch, we add broader coverage, including full dependency scans, container image scans, pipeline file checks, and sometimes DAST in a test environment. This keeps PR validation fast, while still strengthening security before release.

We also need to reduce noise. If the pipeline reports too many findings, teams may start ignoring them. A common way is to block only the clearest and most serious issues, while leaving lower-risk findings for later review. Approved exceptions and simple review rules can also prevent repeated failures for the same known issues.

Keep records including summary outputs, detailed failed-check findings, dependency and container scan reports, approved exceptions, and logs showing when scans ran, which commit or build they were linked to, and which findings blocked or passed the pipeline.

Stage 2: Policy-as-Code Gates and Open Policy Agent

Open Policy Agent (OPA) acts as a central policy engine in secure pipelines, checking configurations (e.g., Terraform plans, Kubernetes manifests) before deployment so that only compliant, secure changes move forward. These policies usually fall into four categories:

• Dependency risk: block packages with known critical vulnerabilities or from untrusted sources
• License rules: identify dependencies with licenses that aren’t allowed in the project or company
• Secrets protection: prevent tokens, passwords, keys, or certificates from moving through the pipeline
• Deploy and environment rules: control where the app can be deployed, which base images are allowed, which security settings are required, and which changes must be stopped before they reach higher environments

Key functions include:

• IaC scanning checks Terraform or CloudFormation before deployment and blocks insecure settings.
• Kubernetes validation reviews manifests and ensures key security rules are met before changes reach the cluster.
• Supply chain checks verify image sources and enforce security rules for container usage.
• Automated compliance gates apply internal standards automatically instead of relying only on manual reviews.

Here is a simple Policy as Code example using a Rego policy file (policy.rego) that blocks any Terraform plan that tries to create an AWS S3 bucket with public access enabled:

rego
package terraform.security

# Deny if any S3 bucket has 'public' set to true
deny[msg] {
    # Look through all resource changes in the Terraform plan
    resource := input.resource_changes[_]
    resource.type == "aws_s3_bucket"

    # Check if the public access setting is enabled
    resource.change.after.public == true

    msg = sprintf("Security Violation: S3 bucket %s must not be public.", [resource.address])
}

To use this policy in a pipeline, convert the infrastructure plan into JSON and evaluate it with OPA:

# 1. Generate the Terraform plan
terraform plan -out=tfplan

# 2. Convert the plan to JSON for OPA
terraform show -json tfplan > tfplan.json

# 3. Evaluate the plan against the Rego policy
# This command will fail (return a non-zero exit code) if 'deny' is not empty
opa eval --input tfplan.json --data policy.rego "data.terraform.security.deny" --fail-defined

The pipeline will fail automatically when a policy violation is detected.

Policies also need governance over time. Keep them in version control, review changes in PRs, and record who approved them. If an exception is allowed, it should include a clear reason and an end date so it does not remain in place forever.

Stage 3: SBOMs in Secure CI/CD Pipelines

Adding a software bill of materials (SBOM) is a core DevSecOps practice that improves visibility into direct and transitive dependencies, improves supply chain traceability, supports faster response to critical vulnerabilities, and strengthens compliance and audit readiness.

How to Generate an SBOM in the Pipeline

We usually generate SBOMs during the build stage, send them to security platforms for continuous checks, and keep them with the build artifact for traceability. This helps us see what was built, which source code it came from, which pipeline produced it, and when it was created. We should also keep building evidence showing that the artifact came from a trusted process and was not changed afterward.

The following example shows the type of data that policy checks evaluate during the pipeline:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "component": { "name": "MyProject", "version": "1.0" },
  "components": [
    {
      "name": "requests",
      "version": "2.31.0",
      "purl": "pkg:pypi/[email protected]",
      "hashes": [
        { "alg": "SHA-256", "content": "e3b0c442..." }
      ],
      "licenses": [
        { "license": { "id": "Apache-2.0" } }
      ]
    }
  ]
}

Add security gates to stop the pipeline if the SBOM contains blocked licenses or components with high-severity vulnerabilities. Enforce supply chain controls, blocking unknown or unsigned artifacts and anything that does not match the expected build rules. Also check for drift, where an artifact, image, or dependency changed from what was originally approved or built.

Stage 4: Zero Trust for Secure CI/CD

Applying zero trust to CI/CD means we do not trust any part of the pipeline by default, whether it is code, a user, or a build agent. Instead of relying only on network boundaries, we continuously verify access and actions to reduce the attack surface. This starts with replacing long-lived secrets with short-lived identity-based access (e.g., OpenID Connect). Each pipeline stage should have only the access it needs, enforcing least privilege across the delivery flow, and runners should be separated from the rest of the environment, with short-lived runners used where possible.

Secrets and deployment access also need ongoing management. Rotate secrets regularly, replace them when needed, and remove access that is no longer required. Review deployment permissions when people change roles, leave the team, or when pipeline stages and environments change. This keeps access limited, current, and easier to control.

Only trusted images and build outputs should be allowed to move forward, with risky builds, insecure configurations, and unapproved components blocked by policy. Clear audit records are necessary for every deployment. Keep logs showing who or what started the deployment, when it happened, and which commit, artifact, or configuration change was included.

Stage 5: Safe AI-Automated Remediation

Implementing agentic AI in DevSecOps pipelines shifts remediation from a manual, reactive task into a more automated and proactive process. Instead of only following fixed rules, AI agents can use context, make decisions, and take corrective actions inside the CI/CD pipeline, such as fixing vulnerabilities or updating insecure code.

AI agents can scan code changes, detect risky patterns, prioritize issues, and suggest or apply fixes in code, scripts, or configuration files. They can also help detect failures in code or data pipelines, collect error details, and support faster response during incidents.

A safety framework is critical when using agentic AI in DevSecOps pipelines. The OWASP Agentic Security Initiative (ASI) provides guidance for using AI agents in a safer and more controlled way. At the same time, AI-driven remediation introduces new risks, such as goal hijacking, poisoned memory, or manipulated context.

Some issues are safe for automatic remediation, particularly low-risk changes with clear scope and limited impact, such as small dependency updates, version bumps, simple configuration fixes, or straightforward code fixes that follow known patterns. More sensitive changes, especially those affecting access control, security policies, production deployment logic, shared infrastructure, or important business code, should still require human review.

OWASP guidance, including the OWASP AI Security Verification Standard (AISVS), also helps define guardrails for tool calls, automated actions, and decision-making. Another important concept is Least Agency, which means the agent should only have the minimum autonomy needed for the task. In practice, this often means the agent prepares a fix and sends it through the normal review process before merge.

Rollback and containment are also important. If an agent makes a bad fix, we should be able to stop the rollout, revert the change, and return quickly to the last good state. Keep rollback steps ready, track which agent action caused the change, and limit how far an automated change can go before checks are complete.

Practical Quantum-Safe Encryption Touchpoints

Quantum-safe encryption means cryptography is designed to remain secure even when quantum computers become capable of breaking some of today’s methods. Right now, this matters most for long-term data protection, key exchange, digital signatures, and future compliance requirements.

In a CI/CD pipeline, start by finding where cryptography is used in code, libraries, containers, and platform settings. Then track which algorithms are approved, block weak or unapproved ones with policy checks, and maintain a list of systems that will need updates later. This does not mean changing everything now, but starting early and preparing step by step.

Make Observability and Governance Measurable

Pipeline security should be measurable so we can see if our controls are working. Useful metrics include how often policy checks fail, how many critical vulnerabilities are blocked before production, how long fixes take, how many exceptions we allow, and how often secrets or insecure settings are found early.

Ensure you save the right records automatically, including logs, SBOM records, build and artifact details, policy approvals, exception records, and proof of who or what started important pipeline actions. Collecting this in the pipeline makes governance easier to manage and review, and more useful during audits or incident response.

Conclusion

DevSecOps has brought security into the full SDLC, from code and dependencies to pipeline controls, SBOMs, zero trust, and remediation. The focus is no longer only on detection but also on policy enforcement, pipeline protection, and faster response with better context. In 2026, DevSecOps is becoming more continuous and automated, with agentic AI, zero trust, Policy as Code, and SBOM-driven visibility working together more closely.

Over the next year, we will likely see more AI-driven remediation inside pipelines, broader use of short-lived identities instead of static secrets, and stronger policy gates around software supply chain risk. We can also expect more attention on securing the pipeline itself, with better protection for runners, artifacts, and agent actions. AI safety, auditability, and human approval are also likely to become standard requirements as agentic AI takes on a larger role in DevSecOps.

This is an excerpt from DZone’s 2026 Trend Report, Security by Design: AI Defense, Supply Chain Security, and Security-First Architecture in Practice.

Read the Free Report