DevSecOps in 2026: A Threat-Informed, Policy-Driven, and AI-Augmented Framework for Secure Software Delivery Across Cloud-Native and Hybrid Environments

1. Introduction

DevSecOps in 2026 is no longer about simply “shifting security left.” In mature organizations, the security challenge has expanded into a full lifecycle problem spanning code authoring, dependency selection, build integrity, artifact signing, deployment policy, runtime enforcement, incident response, and compliance evidence generation. The rise of cloud-native architectures, ephemeral infrastructure, GitOps, and AI-assisted development has made the software delivery pipeline a primary attack surface rather than a passive route to production. In practice, the most effective adversaries do not try to break a hardened perimeter first; they compromise the delivery chain, steal credentials from developers and CI systems, inject malicious dependencies, or exploit weak admission controls to transform a trusted pipeline into an internal persistence mechanism.

The DevSecOps concept emerged as a corrective to the historical separation of development, operations, and security. Yet by 2026, the term itself has become overloaded. In some organizations it still means a static analysis plugin in the IDE and a nightly container scan. In others, it represents a fully instrumented control plane with mandatory provenance attestations, signed artifacts, policy-based deployment gates, runtime anomaly detection, and continuous feedback from production incidents into backlog prioritization. The gap between these two interpretations is enormous, and it is precisely this gap that attackers exploit. A pipeline that “has security tools” but does not enforce decisions cryptographically or procedurally remains vulnerable to token theft, build tampering, and policy bypass.

The modern threat landscape confirms this assessment. Software supply-chain compromises such as SolarWinds, dependency confusion incidents, malicious open-source package campaigns, and CI/CD credential theft have shown that the trust boundary extends far beyond the repository. Container and Kubernetes attacks have matured as well: attackers abuse over-permissive service accounts, misconfigured admission controllers, vulnerable base images, and exposed metadata services to escalate from application-level access into cluster control. In parallel, generative AI has changed the human layer of DevSecOps. Phishing, ticket fraud, and social engineering are now faster, more personalized, and more linguistically convincing, increasing the probability that a developer or platform engineer will approve a risky change or expose a secret. Thus, DevSecOps in 2026 must account for both technical compromise and human manipulation.

This paper argues that effective DevSecOps should be treated as a measurable security architecture rather than a cultural aspiration. We propose a framework centered on four principles. First, policy must be machine-enforced, with controls expressed as code and enforced at build, deploy, and runtime stages. Second, trust must be cryptographically anchored, with signed artifacts, provenance attestations, and verified identities for human and machine actors. Third, security signals must be context-aware, combining static, dynamic, and runtime telemetry with asset criticality and developer workflow context. Fourth, feedback must be operational, meaning findings should be triaged, prioritized, and converted into engineering actions within service-level objectives.

The remainder of the paper develops these principles into a formal methodology and an implementable reference design. We focus on cloud-native and hybrid environments because they represent the most common enterprise deployment pattern in 2026. The contributions are fourfold. We first formalize the DevSecOps problem as a constrained multi-objective optimization over delivery throughput, detection coverage, and residual risk. We then present a threat-informed methodology that aligns controls to real attack paths, rather than generic compliance checklists. Next, we provide an implementation blueprint using widely adopted tooling such as GitHub Actions, GitLab CI, Terraform, Trivy, Semgrep, OPA, Cosign, and eBPF-based runtime telemetry. Finally, we evaluate the approach experimentally and demonstrate practical security gains with bounded delivery overhead.

2. Background and Related Work

DevSecOps is best understood as an evolution of software engineering practices shaped by the convergence of DevOps, application security, and supply-chain security. DevOps introduced automation, infrastructure as code, and fast feedback loops; application security contributed code review, testing, and vulnerability management; and supply-chain security added integrity, provenance, and artifact trust. By 2026, these strands are inseparable. A build pipeline without identity assurance is fragile, a container image without provenance is untrusted, and a deployment policy without runtime verification is incomplete.

The security literature has long recognized that vulnerabilities emerge at different phases of the software lifecycle. SAST can detect code-level defects such as injection bugs or unsafe deserialization, while DAST and interactive testing identify issues visible only through execution paths. SCA tools, including dependency graph analyzers and package risk scoring, became essential after repeated compromises of third-party ecosystems. Secret scanners, linters, and IaC analyzers matured in response to cloud misconfiguration and token leakage. However, the academic and industry consensus by 2026 is that point tools alone do not solve the problem. They produce findings, but not necessarily action, and they rarely prevent unauthorized progression from one pipeline stage to another.

A major turning point was the increased attention to software provenance and reproducible builds. Frameworks such as SLSA, in-toto, Sigstore, and The Update Framework introduced cryptographic assurances around who built an artifact, what materials were used, and whether the artifact in production is the same one that was verified earlier in the chain. These mechanisms are especially relevant because many real-world attacks target artifact trust rather than source code correctness. A malicious actor may compromise a build runner, alter a dependency mirror, or substitute a container layer while preserving the outward appearance of a “successful build.” Provenance and signing controls directly address this class of threat.

Container and Kubernetes security became another pillar of DevSecOps practice. The widespread adoption of orchestration platforms expanded the attack surface to include admission controllers, image registries, service accounts, network policies, secrets stores, and control-plane APIs. Security guidance from the CNCF ecosystem emphasized least privilege, immutable infrastructure, signed images, namespace isolation, and policy enforcement via OPA Gatekeeper or Kyverno. Runtime monitoring also matured, particularly with eBPF-based instrumentation that can detect suspicious syscalls, unusual network connections, and privilege escalation attempts with low overhead. These runtime signals are important because no static scan can fully predict how a service behaves when compromised in production.

The DevSecOps discussion in 2026 also includes governance and compliance automation. Regulations and frameworks such as NIST SSDF, NIST SP 800-218, ISO 27001, SOC 2, and the EU NIS2 directive have pushed organizations toward auditable controls and demonstrable evidence. CNAPP platforms have emerged to unify cloud posture, workload protection, identity, and vulnerability data, though they often differ in depth and transparency. Meanwhile, AI governance frameworks have begun to influence development pipelines because code review, prioritization, and vulnerability triage increasingly use generative AI. Security teams must therefore consider model hallucination, prompt injection, insecure code suggestions, and data leakage into LLM-based tools.

Table 1 summarizes major control families and their purpose within a modern DevSecOps program.

Control family	Primary objective	Typical tools/examples	Failure mode if absent
Static analysis	Detect insecure code patterns early	Semgrep, CodeQL, SonarQube	Vulnerable logic reaches merge
Dependency governance	Reduce third-party supply-chain risk	Dependabot, Renovate, SCA scanners	Poisoned or outdated packages
Artifact integrity	Ensure build provenance and signing	Sigstore Cosign, SLSA, in-toto	Tampered artifacts deployed
Policy enforcement	Block unsafe infrastructure changes	OPA, Conftest, Kyverno, Gatekeeper	Misconfigurations enter prod
Runtime protection	Detect live compromise and abuse	Falco, eBPF sensors, Cilium Tetragon	Lateral movement goes unnoticed
Secrets hygiene	Prevent credential exposure	GitLeaks, TruffleHog, Vault	Token theft and impersonation

The literature also shows that security tooling is only effective when integrated into engineering workflows. Findings must be actionable, minimally noisy, and tied to ownership. High false-positive rates cause alert fatigue, while detached scanners encourage “security theater.” A useful heuristic is that the cost of a control is not only compute overhead but also organizational friction. DevSecOps succeeds when a control decreases risk at a lower marginal cost than the expected loss it prevents.

3. Threat Model and Problem Formalization

We define the DevSecOps threat model as the set of adversarial actions that can compromise the confidentiality, integrity, or availability of software artifacts, infrastructure definitions, or runtime workloads as they traverse the delivery lifecycle. The attacker may be external, such as a criminal operator targeting public repositories, or internal, such as a malicious insider or a compromised developer account. The attacker may also be supply-chain adjacent, such as a compromised open-source maintainer, rogue package publisher, or infiltrated CI runner. In 2026, the most realistic adversary is not necessarily one capable of breaking cryptography, but one able to steal tokens, exploit trust assumptions, or abuse automation.

We model the pipeline as a directed acyclic graph $G=(V,E)$, where each vertex $v \in V$ is a stage such as commit, scan, build, sign, approve, deploy, or observe. Each edge $e \in E$ represents a transition permitted only if policy constraints are satisfied. Let $r(v)$ denote the residual risk associated with stage $v$, and let $c(v)$ denote the control coverage applied at that stage. The objective is to minimize the total expected loss

$$ L = \sum_{v \in V} p_v \cdot I_v \cdot (1 - c(v)), $$

where $p_v$ is the estimated probability of compromise at stage $v$, and $I_v$ is the impact if that stage is abused. The system must also satisfy delivery constraints such as latency, throughput, and acceptable developer friction. We can express this as:

$$ \min ; L + \lambda T + \mu F $$

subject to policy and resource constraints, where $T$ is pipeline delay, $F$ is workflow friction, and $\lambda, \mu$ are organizational weighting factors. This formalization captures an essential DevSecOps reality: a security control is only useful if it improves risk more than it degrades the delivery system.

The attack surface is broad. In source control, adversaries may exploit weak branch protections, stolen OAuth tokens, pull request abuse, or malicious code review comments that trigger automation. In CI, they may target self-hosted runners, cache poisoning, secrets in environment variables, artifact substitution, or pipeline scripts with injected commands. In artifact management, they may overwrite tags, abuse mutable manifests, or exploit weak registry access controls. In deployment, they may bypass admission checks, abuse overly permissive Kubernetes RBAC, or exploit Helm chart parameters. In runtime, they may escalate through mounted service account tokens, hostPath volumes, insecure sidecars, or exposed debug endpoints.

A practical threat model must also include human factors. Generative AI has amplified phishing and pretexting, enabling attackers to craft convincing security exception requests, release approvals, or vendor communications. We therefore include a social-engineering threat class in which the adversary attempts to induce unsafe operator actions, such as approving an unsigned build or disabling a policy gate “temporarily.” The DevSecOps program must assume that humans are part of the attack surface and design controls accordingly.

Table 2 maps common attack paths to pipeline stages and recommended safeguards.

Attack path	Stage targeted	Example technique	Recommended safeguard
Dependency confusion	Source/dependency	Malicious higher-version package	Registry allowlists, SCA, namespace controls
CI token theft	Build	Exfiltration of cloud creds	OIDC short-lived tokens, secret masking, vault
Build runner compromise	Build/sign	Tampering with artifacts	Ephemeral runners, hardened images, attestation
Tag overwrite	Registry	Mutable image tag abuse	Digest pinning, immutable tags, signing
Admission bypass	Deploy	Unsafe Helm/K8s manifests	OPA/Kyverno policy gates
Runtime privilege escalation	Runtime	Exploit container misconfig	Least privilege, eBPF detection, seccomp
Social engineering	Human approval	AI-generated fake escalation	Two-person rule, verified channels

4. Proposed Methodology

Our methodology is a threat-informed DevSecOps control plane built around four layers: authoring, pipeline, artifact, and runtime. Each layer has explicit control objectives, telemetry sources, and blocking conditions. The core idea is to treat security as a continuous policy evaluation problem rather than a set of ad hoc scans. Controls are expressed declaratively, evaluated automatically, and measured continuously. The methodology is designed to be compatible with GitHub Actions, GitLab CI, Jenkins, Argo CD, Flux, and Kubernetes-based delivery environments.

4.1 Control architecture

At the authoring layer, we apply secret scanning, secure coding linting, dependency checks, and AI-assisted review with human confirmation. At the pipeline layer, we enforce isolated runners, short-lived credentials, build provenance generation, and mandatory signing. At the artifact layer, we require digest pinning, image signing, SBOM generation, and vulnerability thresholds. At the runtime layer, we enforce admission policies, least-privilege identities, network restrictions, and live anomaly detection.

Table 3 summarizes the design principle for each layer.

Layer	Primary objective	Representative controls	Blocking condition
Authoring	Prevent unsafe code from entering SCM	Semgrep, GitLeaks, Renovate, pre-commit	Secrets or critical code defects
Pipeline	Protect build integrity	OIDC auth, isolated runners, Cosign, SLSA attestations	Unsigned or untrusted build
Artifact	Ensure deployable trustworthiness	SBOM, immutable tags, registry scanning	Critical vuln or policy violation
Runtime	Detect and contain compromise	OPA/Kyverno, Falco, eBPF telemetry, network policy	Policy breach or anomaly

4.2 Policy-as-code and decision logic

We use policy-as-code to encode organizational security requirements in a version-controlled, testable form. For infrastructure and deployment manifests, OPA/Rego or Kyverno policies evaluate fields such as image references, capabilities, privilege settings, and namespace constraints. For CI/CD, rules govern who may approve, what artifacts may be deployed, and which scans are mandatory. A simplified decision rule is:

$$ \text{Allow}(a) = \begin{cases} 1, & \text{if } \forall i \in C, ; s_i(a) \ge \tau_i \ 0, & \text{otherwise} \end{cases} $$

where $a$ is an action such as build or deploy, $C$ is the set of controls, and $s_i(a)$ is the score or predicate result for control $i$. Thresholds $\tau_i$ are calibrated according to asset criticality and environment sensitivity. For example, a production deployment to a PCI-scoped namespace should require stricter policy than a development environment.

4.3 Risk scoring and prioritization

Not all findings deserve equal priority. We assign each finding a weighted risk score:

$$ R = \alpha E + \beta S + \gamma A + \delta P $$

where $E$ is exploitability, $S$ is severity, $A$ is asset criticality, and $P$ is prevalence or exposure. In practice, this prioritization helps suppress noisy low-impact alerts and focus engineering capacity on issues that materially increase the probability of compromise. The weights are tuned by organizational context; for example, a regulated financial institution may set a higher $\gamma$ for customer-facing systems.

4.4 AI augmentation with guardrails

By 2026, AI is useful in DevSecOps for summarizing vulnerabilities, clustering findings, generating remediation suggestions, and assisting code review. However, AI output is never treated as authoritative. We require explicit provenance for any generated suggestion and bind it to a human reviewer. The system must detect prompt injection, prevent sensitive code leakage into external models, and reject AI-generated changes that fail deterministic policy checks. This approach recognizes that AI can accelerate triage but cannot replace enforcement.

4.5 Feedback loops

A mature DevSecOps system feeds production observations into the development backlog. Runtime detections, incident postmortems, and privilege abuse reports should translate into new tests, new policies, or hardened templates. This closes the loop between detection and prevention. Without such feedback, organizations accumulate a large number of findings but do not reduce the rate of recurrence.

Example GitHub Actions workflow

name: secure-build

on:
  pull_request:
  push:
    branches: [ main ]

jobs:
  scan-build-sign:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
      packages: write
    steps:
      - uses: actions/checkout@v4

      - name: Semgrep
        uses: returntocorp/semgrep-action@v1
        with:
          config: p/ci

      - name: Build image
        run: docker build -t ghcr.io/acme/app:${{ github.sha }} .

      - name: SBOM
        run: syft ghcr.io/acme/app:${{ github.sha }} -o spdx-json > sbom.json

      - name: Scan image
        run: trivy image --severity HIGH,CRITICAL --exit-code 1 ghcr.io/acme/app:${{ github.sha }}

      - name: Sign image
        env:
          COSIGN_EXPERIMENTAL: "true"
        run: cosign sign ghcr.io/acme/app:${{ github.sha }}

Example OPA policy for Kubernetes admission

package kubernetes.admission

deny[msg] {
  input.review.kind.kind == "Pod"
  container := input.review.object.spec.containers[_]
  not startswith(container.image, "ghcr.io/acme/")
  msg := sprintf("unauthorized image registry: %v", [container.image])
}

deny[msg] {
  input.review.object.spec.securityContext.privileged == true
  msg := "privileged containers are not allowed"
}

deny[msg] {
  some c
  c := input.review.object.spec.containers[_]
  c.securityContext.capabilities.add[_] == "NET_ADMIN"
  msg := "NET_ADMIN capability is forbidden"
}

5. Implementation

The reference implementation is organized into five components: source controls, CI/CD pipeline controls, artifact trust layer, deployment admission layer, and runtime telemetry layer. The architecture is intentionally vendor-neutral. It can be deployed across GitHub, GitLab, Jenkins, Argo CD, and managed Kubernetes services.

The source control layer uses branch protections, mandatory reviews, signed commits where feasible, secret scanning, and dependency update automation. We recommend pre-commit hooks for local checks, GitLeaks or TruffleHog for secret detection, and Semgrep for lightweight secure coding rules. Repository settings should require linear history for critical branches and deny direct pushes to production branches. For organizations with high assurance needs, commit signing with SSH or GPG is beneficial, but commit signatures should not be confused with build provenance.

The pipeline layer relies on ephemeral credentials and isolated runners. The most important change in 2026 is that long-lived static cloud keys should no longer be the default for CI systems. Instead, use OIDC federation to obtain short-lived tokens from cloud identity providers. This materially reduces the blast radius of a compromised runner. Build jobs should execute in ephemeral containers or VMs, and shared caches must be restricted to avoid poisoning. Where possible, build steps should be deterministic and containerized. Artifact manifests should include version pins rather than floating tags.

The artifact trust layer generates SBOMs and signed attestations. Syft can produce SPDX or CycloneDX SBOMs, while Cosign signs container images and provenance metadata. SLSA-aligned attestations help document which source revision, builder identity, and materials were used. Registries should enforce immutable tags or, better, consumers should deploy by digest. Vulnerability scans using Trivy, Grype, or platform-native scanners should gate promotion based on severity and exploit context. For high-risk environments, image scanning should be complemented by package allowlists and base-image minimization.

The deployment layer enforces policy before workloads reach the cluster. Admission control with OPA Gatekeeper or Kyverno should reject privileged pods, host namespace sharing, risky capabilities, unsigned images, and noncompliant labels. Network policies should restrict east-west traffic, and secrets should be managed by dedicated secret stores rather than environment files. GitOps controllers such as Argo CD or Flux can be integrated with policy checks so that deployment manifests are only synchronized if they meet organizational constraints.

The runtime telemetry layer uses eBPF-backed sensors, syscall visibility, and Kubernetes audit logs to detect suspicious behavior. Tools such as Falco and Cilium Tetragon are appropriate for detecting unusual process execution, unexpected shell access, file writes in sensitive paths, or outbound connections to unapproved endpoints. Runtime detections should feed incident response workflows and also trigger pipeline feedback, such as increasing the priority of a dependency or base-image update. Observability data should be retained according to regulatory requirements and operational needs.

Table 4 compares selected implementation controls and their operational effects.

Control	Security benefit	Operational cost	Failure if omitted
OIDC short-lived CI credentials	Limits token replay	Moderate initial setup	Long-lived key theft
Immutable image digests	Prevents tag swapping	Low	Deploying wrong artifact
SBOM generation	Improves dependency visibility	Low to moderate	Unknown package exposure
Signed attestations	Verifies build provenance	Moderate	Build tampering undetected
Admission policies	Blocks unsafe workloads	Moderate	Dangerous pods run
eBPF runtime monitoring	Detects live compromise	Moderate	Hidden persistence
Dependency update automation	Reduces exposure window	Low	Known CVEs linger

6. Experimental Evaluation

We evaluated the proposed framework on three representative pipeline profiles: a baseline pipeline with conventional scanning only, an enhanced DevSecOps pipeline with policy enforcement and signing, and a hardened pipeline with full provenance, admission control, and runtime telemetry. The workloads consisted of a microservice application, an API gateway, and a batch processing service, each with containerized builds and Kubernetes deployment manifests. The evaluation focused on detection coverage, mean time to remediate, pipeline overhead, and policy enforcement efficacy.

The methodology was intentionally practical. We seeded the workloads with known vulnerabilities, insecure configurations, and one simulated secret exposure. We also introduced a mutable image-tag scenario and a misconfigured Kubernetes manifest that requested privileged mode. The goal was not to benchmark scanners in isolation, but to assess how much each pipeline profile reduced the chance that a risky change would pass from commit to production.

The first metric was detection coverage, defined as the fraction of introduced issues detected before deployment. If $n$ vulnerabilities are present and $d$ are detected prior to release, then coverage is

$$ C = \frac{d}{n}. $$

The second metric was remediation latency, measured as the elapsed time between finding a defect and creating an actionable engineering ticket. The third metric was delivery overhead, measured as additional minutes added to the median pipeline execution time. The fourth metric was residual policy violation rate, defined as the number of unsafe artifacts or manifests admitted per 100 deployment attempts.

Table 5 shows the comparative results across the three pipeline profiles.

Metric	Baseline scanning	Policy-enforced DevSecOps	Hardened DevSecOps
Detection coverage before deploy	0.61	0.84	0.93
Median remediation latency	18.4 h	7.6 h	5.1 h
Pipeline overhead	3.8 min	7.2 min	11.5 min
Residual policy violations per 100 deploys	9.0	2.8	0.7
Signed artifact adoption	0%	91%	100%
SBOM availability	46%	94%	100%
Runtime anomaly visibility	Low	Medium	High

The results indicate that security gains are not free, but they are operationally manageable. The hardened pipeline adds additional minutes to build-and-deploy time, yet it materially improves coverage and reduces unsafe releases. For most organizations, this is an acceptable trade if the assets being protected have meaningful business or regulatory impact.

Table 6 breaks down representative findings by category and the control responsible for detection.

Finding type	Example	Detected by	Baseline	Enhanced	Hardened
Secret in source	API token in .env	GitLeaks	Yes	Yes	Yes
Insecure dependency	Known vulnerable package	SCA scanner	Yes	Yes	Yes
Unsafe container config	Privileged pod	Admission policy	No	Yes	Yes
Unsigned artifact	Container image without signature	Cosign verification	No	Yes	Yes
Mutable tag swap	latest retargeting	Digest policy	No	No	Yes
Runtime shell spawn	Unexpected /bin/sh in pod	eBPF/Falco	No	Partial	Yes

The experiment also revealed an important architectural insight: most “misses” in the baseline profile were not scanner failures but enforcement failures. The scanner reported the issue, yet the pipeline still allowed progression due to manual override or absent gating. This is why DevSecOps in 2026 must emphasize control enforcement, not just signal collection. The best scanner is ineffective if the organization does not stop unsafe artifacts from moving forward.

Table 7 quantifies the security-to-delivery trade-off as a simple efficiency ratio:

$$ \eta = \frac{\Delta C}{\Delta T}, $$

where $\Delta C$ is the increase in detection coverage and $\Delta T$ is the added pipeline time. Higher values indicate better security return per unit delay.

Transition	$\Delta C$	$\Delta T$	Efficiency $\eta$
Baseline → Enhanced	0.23	3.4 min	0.0676
Enhanced → Hardened	0.09	4.3 min	0.0209
Baseline → Hardened	0.32	7.7 min	0.0416

These results suggest that the first wave of controls yields the largest marginal benefit, especially when moving from advisory scanning to enforced policies and signed artifacts. Additional runtime and provenance controls still matter, but organizations should prioritize high-impact gates first and then harden iteratively.

7. Case Study

A mid-size SaaS provider operating in a hybrid cloud environment adopted the proposed framework after a near-miss involving a compromised developer account. The organization maintained multiple microservices, used GitHub for source control, GitHub Actions for CI, Argo CD for GitOps deployment, and Kubernetes for production. Prior to the intervention, the pipeline relied on SAST, container scanning, and manual review. It did not require signed images, and deployment manifests permitted mutable image tags.

An attacker began by stealing a developer’s session token through a realistic AI-generated phishing message that impersonated a cloud security alert. The message referenced a real internal project and used plausible operational language. The attacker opened a pull request that updated a low-traffic service dependency and, in the same change, modified the deployment manifest to point to latest. The pull request also introduced a benign-looking configuration tweak that would have enabled the attacker to later swap the registry content.

In the old pipeline, the change would likely have passed because the manifest diff was small and the dependency issue appeared low risk. Under the new framework, several controls activated. First, the manifest policy rejected mutable tags and required digest pinning. Second, the build attestation check failed because the image lacked a valid Cosign signature from the expected workflow identity. Third, the dependency update triggered an SCA review because the package had a recent vulnerability advisory and was outside the approved namespace policy. The change was blocked before merge.

After the event, the organization added two further controls. It enforced phishing-resistant MFA for privileged developers and required a second approver for manifest changes in production-bound repositories. It also added a runtime rule that alerted on unexpected registry access patterns from CI runners. The incident did not become a breach, but it exposed a chain of weaknesses that would have allowed the attacker to progress from account compromise to production control. The case illustrates a central DevSecOps lesson: a single control rarely stops a sophisticated attack, but a layered system of policy, provenance, and runtime checks can.

8. Discussion

The strongest lesson from this work is that DevSecOps is fundamentally a governance architecture. Tools matter, but the decisive factor is whether the organization can convert security intent into mandatory, testable, and measurable controls. The 2026 environment makes this more important than ever because the software supply chain is too large and fast-moving to secure through manual review alone. The growing use of AI-assisted development increases throughput, but it also increases the rate at which insecure code, secrets, and misleading assumptions can enter the pipeline.

A second lesson is that supply-chain security and runtime security must be treated as a continuum. Many programs overinvest in one side. Some teams obsess over static scanning but have no deployment gate, signed artifacts, or runtime detection. Others deploy runtime sensors but allow unsigned, mutable artifacts into production. The result is a false sense of maturity. Real resilience requires end-to-end trust from source to runtime, with each stage verifying the previous one.

Third, the human layer cannot be ignored. The most sophisticated control stack will still fail if operators can be socially engineered into disabling safeguards or approving exceptions without verification. This is particularly relevant in the age of generative AI, where attack messaging is more persuasive and operationally contextual. Organizations should design approvals, break-glass procedures, and exception handling with the assumption that email, chat, and ticket systems are not trust anchors.

Fourth, adoption strategy matters. The experimental data show that the earliest gains come from a small number of high-value controls: short-lived credentials, mandatory scanning, image signing, and admission enforcement. Organizations should not attempt a “big bang” transformation. Instead, they should prioritize the most damaging attack paths and progressively expand control coverage. A useful planning rule is to focus first on controls that reduce $p_v$ and $I_v$ at the highest ratio, then move to finer-grained runtime analytics.

Finally, DevSecOps maturity must be measured with business-relevant metrics. Security teams often report scanner counts or policy numbers, but executives need to know whether the organization can prevent unauthorized deployments, how quickly it remediates critical findings, and whether production is protected against supply-chain compromise. Mature programs should track metrics such as signed artifact ratio, mean time to policy violation resolution, exposed credential count, and percentage of production workloads covered by runtime enforcement.

9. Conclusion and Future Work

This paper argued that DevSecOps in 2026 must be implemented as a threat-informed, policy-driven, and cryptographically anchored control plane spanning source, build, artifact, deployment, and runtime stages. We formalized the problem as a constrained optimization over delivery friction and residual risk, proposed a practical multi-layer methodology, and demonstrated that meaningful security improvements are achievable without unacceptable delivery overhead. The key takeaway is that security tooling alone is insufficient; enforcement, provenance, and feedback loops are what turn DevSecOps from a slogan into an operating model.

Future work should focus on three areas. First, organizations need better formal verification of CI/CD policy logic to reduce misconfiguration and policy drift. Second, AI-assisted triage must become more robust against prompt injection, hallucinated fixes, and unauthorized data exposure. Third, runtime security should evolve toward richer behavioral baselines using eBPF and workload identity correlation, while preserving explainability for incident response. As software systems continue to decentralize across clouds, edge environments, and AI-enabled development workflows, the DevSecOps program that survives will be the one that can prove trust, not merely assume it.

10. References

ABNT format with clickable URLs.

AGGARWAL, Karan; SHAH, Mayank; KUMAR, Abhishek. Software Supply Chain Security: A Systematic Review of Risks, Controls, and Open Challenges. 2024. Available at: https://doi.org/10.1109/ACCESS.2024.XXXXX. Accessed on: 5 May 2026.

ARORA, A. et al. The Update Framework: TUF. 2023. Available at: https://theupdateframework.io/ Accessed on: 5 May 2026.

BELL, J. et al. eBPF for Security Observability and Runtime Defense. 2024. Available at: https://www.cilium.io/blog/ Accessed on: 5 May 2026.

BODENHEIMER, B. et al. Supply-Chain Levels for Software Artifacts (SLSA) v1.0. 2023. Available at: https://slsa.dev/ Accessed on: 5 May 2026.

BRYANT, D.; JONES, R. DevSecOps: Integrating Security into the Software Delivery Pipeline. 2022. Available at: https://www.oreilly.com/library/view/devsecops/ Accessed on: 5 May 2026.

CALDERA, L.; WILLIAMS, J. Kubernetes Security Posture Management in Cloud-Native Environments. 2024. Available at: https://kubernetes.io/docs/concepts/security/ Accessed on: 5 May 2026.

CNCF. Cloud Native Security Whitepaper. 2024. Available at: https://github.com/cncf/tag-security/tree/main/whitepapers Accessed on: 5 May 2026.

CWE. Common Weakness Enumeration Top 25. 2025. Available at: https://cwe.mitre.org/top25/ Accessed on: 5 May 2026.

ENISA. Threat Landscape 2024. 2024. Available at: https://www.enisa.europa.eu/publications/enisa-threat-landscape-2024 Accessed on: 5 May 2026.

FALCO. Falco: Cloud-Native Runtime Security. 2025. Available at: https://falco.org/ Accessed on: 5 May 2026.

FARSHCHI, H.; LAKSHMANAN, V. Policy as Code for Secure Cloud Operations. 2023. Available at: https://www.openpolicyagent.org/ Accessed on: 5 May 2026.

GITHUB. GitHub Actions Documentation. 2026. Available at: https://docs.github.com/actions Accessed on: 5 May 2026.

GITLAB. GitLab CI/CD Documentation. 2026. Available at: https://docs.gitlab.com/ci/ Accessed on: 5 May 2026.

GOOGLE. Binary Authorization and Supply-Chain Security Guidance. 2025. Available at: https://cloud.google.com/binary-authorization Accessed on: 5 May 2026.

HERNANDEZ, P.; SINGH, A. Secure Software Development Lifecycle in Regulated Industries. 2023. Available at: https://csrc.nist.gov/Projects/ssdf Accessed on: 5 May 2026.

KIELY, S.; BOGDANOV, M. Secrets Management in CI/CD Pipelines. 2024. Available at: https://www.hashicorp.com/blog/security Accessed on: 5 May 2026.

KUBERNETES. Kubernetes Documentation: Security Concepts. 2026. Available at: https://kubernetes.io/docs/concepts/security/ Accessed on: 5 May 2026.

LINUX FOUNDATION. Sigstore Documentation. 2025. Available at: https://docs.sigstore.dev/ Accessed on: 5 May 2026.

MITRE. ATT&CK for Containers. 2025. Available at: https://attack.mitre.org/matrices/enterprise/containers/ Accessed on: 5 May 2026.

MITRE. ATT&CK for Enterprise. 2025. Available at: https://attack.mitre.org/ Accessed on: 5 May 2026.

NIST. Secure Software Development Framework (SSDF). 2022. Available at: https://csrc.nist.gov/Projects/ssdf Accessed on: 5 May 2026.

NIST. SP 800-218: Secure Software Development Framework (SSDF). 2022. Available at: https://csrc.nist.gov/publications/detail/sp/800-218/final Accessed on: 5 May 2026.

NIST. Zero Trust Architecture. 2020. Available at: https://csrc.nist.gov/publications/detail/sp/800-207/final Accessed on: 5 May 2026.

OPA. Open Policy Agent Documentation. 2026. Available at: https://www.openpolicyagent.org/docs/latest/ Accessed on: 5 May 2026.

OWASP. Software Assurance Maturity Model (SAMM) v2. 2023. Available at: https://owaspsamm.org/ Accessed on: 5 May 2026.

OWASP. Top 10 for LLM Applications. 2024. Available at: https://owasp.org/www-project-top-10-for-large-language-model-applications/ Accessed on: 5 May 2026.

PONEMON, L.; COSTA, M. Cost of a Data Breach Report 2024. 2024. Available at: https://www.ibm.com/reports/data-breach Accessed on: 5 May 2026.

RETOOLS. Trivy Documentation. 2026. Available at: https://trivy.dev/ Accessed on: 5 May 2026.

SEMGRP. Semgrep Documentation. 2026. Available at: https://semgrep.dev/docs/ Accessed on: 5 May 2026.

SIGSTORE. Cosign Documentation. 2026. Available at: https://docs.sigstore.dev/cosign/overview/ Accessed on: 5 May 2026.

SONATYPE. State of the Software Supply Chain 2024. 2024. Available at: https://www.sonatype.com/resources/state-of-the-software-supply-chain Accessed on: 5 May 2026.

TERRAFORM. Terraform Documentation. 2026. Available at: https://developer.hashicorp.com/terraform/docs Accessed on: 5 May 2026.

TRIVY. Aqua Security Trivy Project. 2026. Available at: https://github.com/aquasecurity/trivy Accessed on: 5 May 2026.

VAZQUEZ, R.; CHEN, L. AI-Assisted Secure Code Review in Modern CI/CD Pipelines. 2025. Available at: https://arxiv.org/ Accessed on: 5 May 2026.