Notifications
Clear all
Topic starter
20/08/2026 5:39 pm
TL;DR: DevSecOps automation has shifted from pipeline scanning to an orchestrated control layer where AI agents triage, prioritise, and remediate findings across code, pipelines, and runtime context, while 81% of organisations still lack visibility into AI use across the SDLC and ADLC, according to Cycode. The governance challenge is no longer how to scan faster, but how to make code-to-cloud decisions with enough identity and context to close risk rather than create alert churn.
NHIMG editorial — based on content published by Cycode: What Is a DevSecOps Automation Platform? The 2026 Guide for AppSec Teams
By the numbers:
- Cycode's 2026 State of Product Security report found that 81% of organizations lack full visibility into how and where AI is used across the SDLC or ADLC.
- Cycode says DevSecOps platforms can reduce false positives by 80% to 94% when they use exploitability analysis and code-to-runtime context.
Questions worth separating out
Q: How should security teams govern AI-generated code in production environments?
A: Security teams should treat AI-generated code as normal production code with extra provenance risk.
Q: Why do point tools fail to reduce risk in modern DevSecOps programmes?
A: Point tools usually produce isolated findings without enough context to decide which issues are exploitable, reachable, or business-critical.
Q: What breaks when secrets are protected but not lifecycle-managed?
A: Protection without lifecycle management leaves standing access in place.
Practitioner guidance
- Map every automation principal Inventory CI/CD service accounts, deployment tokens, AI coding agents, and MCP-connected tools as governed non-human identities with named owners and expiry rules.
- Correlate findings to runtime exposure Prioritise only findings that are reachable in the current application and deployment context, then feed that scoring into ASPM or equivalent triage workflows.
- Reduce secrets persistence windows Eliminate hardcoded secrets from repositories and pipeline definitions, then enforce rotation and revocation workflows that match release cadence, not audit cadence.
What's in the full article
Cycode's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step breakdown of how its DevSecOps automation platform correlates SAST, SCA, secrets detection, IaC, pipeline security, and ASPM findings.
- Detailed explanation of the Context Intelligence Graph and how code-to-cloud traceability supports risk prioritisation.
- Examples of AI Guardrails across prompts, file reads, and MCP tool calls in agentic development workflows.
- Vendor walkthrough of how the Maestro orchestration layer sequences multi-agent remediation across the ADLC.
👉 Read Cycode's guide to DevSecOps automation for AppSec teams →
AI-generated code and DevSecOps automation: are your controls keeping up?
Explore further
20/08/2026 6:23 pm
DevSecOps automation is now an identity governance problem as much as an AppSec problem. Once security actions are delegated to AI agents, the key control question becomes who or what is allowed to inspect, triage, and remediate code risk. That brings NHI governance into the centre of application security because agents, service accounts, and pipeline tokens all need scoped authority and traceable lifecycle control. Practitioners should treat automation as governed delegation, not just faster scanning.
A question worth separating out:
Q: Who is accountable when automated security decisions are made in CI/CD?
A: Accountability should sit with the teams that own the workflow and the identities used to run it, not with the automation itself. Security, development, and platform teams need clear control boundaries, logging, and escalation rules so machine-assisted remediation remains explainable and governed.
👉 Read our full editorial: DevSecOps automation is becoming an agentic risk control layer
