DevSecOps for the Masses

Every wave of decentralised building has been a rational response to a constrained IT function, and every wave has been treated by IT as a problem to be contained rather than a demand to be served.

The spreadsheet moved logic out of the application and into a file. Nobody reviewed the formulas, nobody traced the decisions, and for thirty years the enterprise absorbed the cost because the alternative was a two-year queue. SaaS and low-code moved it further: real applications, real users, real integrations, and the first API keys pointed at the systems of record. We named that Shadow IT, spent a decade building discovery tooling to find it, and mostly made our peace with it.

Vibe coding is the third wave, and the difference is not that more people can build. It is that the build now happens at machine speed, writes directly to production, and no longer produces the one thing every downstream control was designed around: a human author who can be asked why.

This is not an argument that AI writes bad code. That argument ages badly and loses as models improve. It is an argument about where the pipeline lives, who it answers to, and what happens when the thing writing the code is also the thing writing the pipeline that gates it.

What actually changed

Start with the evidence, because the discourse on both sides of this has been running ahead of it.

The most decision-relevant result available comes from the SusVibes benchmark. According to the authors, 200 feature-request tasks were drawn from 108 real open-source projects across 10 security domains, covering 77 Common Weakness Enumeration (CWE) types, with an average context of 162,000 lines of code and an average patch of 172 lines across 1.8 files. The tasks involved were not synthetic: each was chosen because human programmers had produced a vulnerable implementation of it. The headline: SWE-Agent with Claude 4 Sonnet produced 61% functionally correct solutions but only 10.5% secure ones, and the authors state outright that over 80% of its functionally correct solutions have vulnerabilities. OpenHands, with the same model, did not do much better, with only 12.5% of its solutions secure. Claude Code implementations managed around 6%.

There are two details that make this hard to wave away. First, security is scored conditional on functional correctness: the authors say they “care only about the security of those functionally correct solutions,” so this is not two unrelated rates being compared. Among the code that actually worked, four in five carried a vulnerability. Second, prompting did not fix it: augmenting the feature request with explicit vulnerability hints “cannot mitigate these security issues.”

That is the result that matters, because it measures the actual deployment mode. An agent making multi-file edits in a large real codebase, rather than a toy task. And what it shows is that functional correctness and security have decoupled. Agents are getting very good at making the tests pass. They are not getting correspondingly good at being safe.

Veracode’s longitudinal benchmark series reaches the same place by a different route. Their study used the same tasks across four programming languages and four CWE categories, which makes the comparison to SusVibes relevant. According to the authors, the average security pass rate was 55% in the first report. In July 2026, across more than 150 models, it was 56%. Veracode’s own word for the difference is “barely.” One point in just three years. Syntax correctness over the same period climbed to nearly 100%, which tells you where the progress went. Better quality code, but less secure.

The best performer, GPT-5.5, reached 68% security pass rates. Specialised coding models averaged 51% pass rates against 52% for general-purpose ones, so the specialisation bought nothing, and neither did size. The average, however, conceals a split worth noting. SQL injection passes 83% of the time and cryptographic algorithm choice 87%, while cross-site scripting passes 15% and log injection 12%.

The most instructive shape comes from Apiiro's field data across Fortune 50 enterprises (December 2024 – June 2025). AI-assisted developers produced 3–4× more code — and the defect profile inverted:

Read that carefully, because it is the single most important thing in this article. AI assistance improves precisely the classes of defect that compilers and scanners already catch, and worsens precisely the classes that require architectural judgement. Which means the reflex response, an AI-integrated SAST tool, addresses the problem that was already getting better.

The proposal: DevSecOps for the masses

Bolt-on DevSecOps was designed for a scarce population. A platform team built the pipeline. A smaller number of engineers wrote the code that flowed through it. The ratio worked because the number of people who could produce a deployable application was bounded by the number of people who could write software.

That bound is gone. When building an application is as easy as building a slide deck, the pipeline cannot remain a separate act performed later by a different and scarcer person. It will simply not happen at the new volume. Every hour of "we'll wire up CI after the demo" compounds, and the demo is already in production.

So the proposal is straightforward: the pipeline and the repository must be generated by the same act that generates the application. Not offered as a template. Not documented in a golden-path wiki. Generated, at the same moment, by the same tool, as a first-class output.

Concretely, that means a single act producing:

• a real Git repository, with branch protection or rulesets configured, required status checks, required reviews, Codeowners and signed commits;
• working CI/CD config with secrets scanning, SAST, SCA, IaC scanning wired in;
• an SBOM and build provenance;
• tests sourced independently of the implementation;
• and a deployment path gated on all of the above.

That is DevSecOps for the masses. Not "everybody learns DevSecOps" because nobody has time for that, and it was never the point.

The pipeline arrives with the code.

So who is actually doing it?

I went looking, across prompt-to-app platforms, coding agents, and the enterprise DevSecOps and platform-engineering vendors. The answer, as of August 2026, is uncomfortable: nobody. Not one product does the whole thing. And the specific joint where every product fails is the same one.

Repository creation is solved. Lovable creates a private-by-default GitHub repo with two-way sync. Vercel's v0 creates a dedicated branch per chat and auto-commits. Replit runs real Git underneath every project. Base44 does two-way sync. Even aider, the minimalist of the group, offers to create a repo and marks its own authorship on every commit.

Repository configuration is done by nobody. Zero products emit branch protection rules, rulesets, required status checks, Codeowners files or signed-commit enforcement. This is the most striking finding of the entire survey, because it is also the cheapest gap to close. It is a handful of API calls at repo-creation time. The only vendor whose documentation engages with rulesets at all is GitHub, and it engages in the wrong direction. If your ruleset is incompatible with a Copilot coding agent, GitHub's documented resolution is to add Copilot as a bypass actor. As a result, the governance interaction that exists is one that weakens governance.

Pipeline generation exists, barely, in two places. Harness's AI DevOps Agent will build and update pipelines across CI, CD, IaCM and Security Testing Orchestration, generate infrastructure pipelines, and even generate OPA Rego policies for compliance, with the sensible refusal that it "creates the secret object structure but cannot and will not generate actual secret values." It is the most complete pipeline generation on the market. However, as of the date of this article, its documented gap is serious. The docs describe no approval gate or review workflow around the agent's own pipeline edits. An agent that can silently rewrite the pipeline that gates it is not a control. This is the fox in the hen house.

GitLab's CI Expert agent is on by default and will inspect your repository, identify the language and framework, and propose a working build and test pipeline, explaining every decision. But per its own documentation it does not commit, does not open a merge request, and adds no security-scanning templates. It is a very good assistant handing you YAML.

Claude Code will generate and open a pull request for CI workflow files, but only its own agent workflow, not your delivery pipeline.

Security scanning by default is genuinely improving. Replit runs Semgrep and HoundDog against agent-written code with no setup, and re-runs dependency scans when new CVEs land. Lovable runs a basic scan automatically when you open the publish dialog. Devin gives every pull request in Devin Review a security review with no manual routing. Base44 runs a pre-publish scan. This is real progress and worth crediting.

Blocking, however, is off by default almost everywhere. Replit's "block publishing of critical vulnerabilities" is optional and off. Lovable's equivalent is admin opt-in. Vercel's Agent Code Review validates its suggestions by running them in sandboxes against your real builds and tests, and then comments rather than blocking. Sonar's "Sonar way for agentic AI" quality gate is the best-articulated gate in the market (no new vulnerabilities ≥ Minor, no new dependency risks ≥ Low, ≥80% coverage on new code) and it requires a human to manually mark the project as containing AI code first. However, its AI Code Assurance documentation does not state that gate failure blocks merges. The pattern is consistent enough to be a design philosophy: scanners on, enforcement off. Every vendor has chosen velocity at the default.

Deployment gates are absent where the volume is. Lovable, Replit, Base44, Bolt and Windsurf's Cascade App Deploys all default to publish-with-no-review. Cascade deploys go live at a public URL with no Git repository involved at all. Meanwhile the coding agents: Copilot, Claude Code, Devin, Jules, Q Developer are gated by accident, because their output is a pull request. And whatever governance already exists on the repository applies to them. That inheritance is the single most valuable architectural property in the whole survey, and it is why coding agents categorically outperform prompt-to-app platforms on this question.

Test circularity is unsolved. Replit's documentation says the agent "tests its own work on a regular basis." Sonar's 80%-coverage-on-new-code condition is the only quantified answer in the market, and coverage is trivially satisfied by an agent writing its own tests. It measures the wrong thing for this failure mode. The only serious attempt is Amazon Kiro's property-based testing, which derives properties from the specification and tests them against randomly generated inputs, an "executable specification," in their words. Kiro's own caveat is honest. Property testing "can't guarantee your program is absent of bugs," and where implementation and specification disagree a human must adjudicate. It narrows the circle. It does not close it.

And one vendor has the answer to the hardest question. GitLab's scan execution policies state, in the documentation: "Local project YAML files cannot override scan execution policies. Scan execution policies take precedence over any configurations defined for a pipeline, even if you use the same job name in your project's CI/CD configuration." For projects with no .gitlab-ci.yml, the policy creates one implicitly.

That is the only documented mechanism I found during my research that makes a security gate survive the thing writing the pipeline. It is exactly the property you need when a model is authoring the YAML. It is not AI, and it is not on by default. A human platform team must author the policy.

Why advisory controls fail specifically here

There is a temptation to say fine, put a scanner in the agent loop and let it self-correct. The tooling exists. Semgrep Guardian scans every file an agent generates and prompts the agent to regenerate until clean. Snyk, Checkmarx and Aikido all ship MCP servers exposing their scanners to Claude Code, Cursor, Copilot and others. However, there are two problems, and they are both structural.

First, of roughly ten vendors in this space, only Snyk's Agent Guard and Endor Labs' Coding Agent Governance are documented as able to actually deny an agent action mid-loop — and both do it through runtime hooks and policy, not through MCP. Socket Firewall blocks unconditionally, but only at the package-install boundary, because it sits below the agent as a registry proxy. GitHub's secret-scanning push protection blocks, but only secrets, and it is bypassable by anyone with write access. Everything else is advisory: the agent, or the developer, can proceed anyway. None of them is on by default. The MCP pattern has a weakness worth stating plainly: an agent that is not inclined to call the scanner simply doesn't, and an agent under prompt injection certainly won't.

Second, and more seriously: the guardrails themselves are in scope for attack. Mitre's CVE-2025-53773 (reported June 2025, patched August 2025): prompt injection delivered through source code, a web page, a GitHub issue or a tool response causes GitHub Copilot to write "chat.tools.autoApprove": true into the workspace settings file — enabling a mode that disables all user confirmations, yielding remote code execution. The injection did not need to do the damage. It only needed to turn the guardrail off.

The Nx "s1ngularity" compromise (August 2025) inverted the threat model completely. Malicious npm packages ran a postinstall script that invoked the developer's own Claude, Gemini and Amazon Q command-line agents in permission-bypass mode and used them as reconnaissance tooling to enumerate and exfiltrate the filesystem. Over a thousand valid GitHub tokens were stolen; in a second phase, 5,500+ private repositories across 400+ accounts were made public. The permission-bypass flags are not merely a footgun for the developer who types them, they are an API that malware calls.

And the "Comment and Control" research chain demonstrated prompt injection into CI itself: attacker-controlled pull request titles and issue comments hijacking agents running in GitHub Actions, where runners inherit repository secrets automatically, with exfiltrated credentials posted back as PR comments — base64-encoded, which defeated secret scanning, the one genuinely blocking control in the stack. The design lesson generalizes cleanly, and it is the whole thesis of this article in one line:

The agent must not be able to write the thing that governs the agent.

Which is why GitLab's unoverridable scan policy is the right shape, and why "we'll put the security config in the repo the agent is editing" is not.

The accountability layer that does not exist

There is a gap here that nobody is filling, and it is a standards gap rather than a product gap.

The supply-chain provenance stack itself is mature. OpenSSF's SLSA reached v1.2 in November 2025 and, importantly, added a Source Track, whose Level 4 requires that "changes in protected branches MUST be agreed to by two or more trusted persons prior to submission." In-toto's attestation framework reached v1.2.0 in March 2026. Sigstore, cosign, GitHub Artifact Attestations, and npm provenance all work today. CycloneDX 1.7 is now ECMA-424 and carries extensive ML-BOM support. CISA published new SBOM minimum elements in July 2026, and the G7 published an "SBOM for AI" in May.

None of it answers a simple question. Was this commit written by an AI agent, which one, and who reviewed it?

There is no in-toto predicate for AI authorship, no SLSA track, and no SBOM field. CycloneDX's ML-BOM and SPDX's AI Profile both treat AI as the subject of the record, describing models, datasets, and training. Neither treats AI as the author. SLSA's Source Track counts human trusted persons and explicitly carves out an exception for "trusted robots."

NIST does not fill the gap either, and it says so plainly. SP 800-218A, the generative-AI companion to the Secure Software Development Framework, states that its practices "do not distinguish between human-written and AI-generated source code, because it is assumed that all source code should be evaluated for vulnerabilities and other issues before use." That is a defensible position about scanning. It is not a position about accountability.

Regulation does not fill it either, and is moving away from the question rather than towards it. The EU AI Act's high-risk regime, widely reported as landing on 2 August 2026, was deferred a week earlier by the Digital Omnibus on AI: Annex III stand-alone systems now apply from 2 December 2027 and Annex I embedded systems from 2 August 2028. Nothing in the regime, on either date, asks who wrote the commit.

The one binding requirement that already reaches AI-built internal software asks a different question. Article 16 of the DORA ICT risk-management standard requires "the performance of source code reviews covering both static and dynamic testing", plus testing and approval of all ICT systems before use, explicitly covering software developed in house. That is a scanning obligation, and the same one NIST states. NIS2 Article 20 comes closest to the authorship question by making management bodies approve cybersecurity risk-management measures and holding them liable for failures, but it says nothing about how that responsibility survives contact with an agent that writes the code and the pipeline.

The only working mechanism in existence today comes from open-source project governance, and it is the sharpest statement of the WEKID principle I have seen anywhere:

The Linux kernel's coding-assistants policy requires AI contributions to carry an Assisted-by: AGENT:MODEL trailer. And then it says this:

"AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO)."

The human submitter is responsible for reviewing all AI-generated code, ensuring licence compliance, adding their own sign-off, and taking full responsibility for the contribution. Assisted-by: was chosen deliberately over the existing Co-developed-by: — because that trailer requires a matching sign-off from the co-developer, and an AI cannot give one. The design point is explicit: AI is a tool, not an author.

LLVM's AI Tool Policy says the same thing in its own words: "The contributor is always the author and is fully accountable for their contributions." Fedora, Rocky, OpenInfra and OpenTelemetry have converged on the same trailer.

The largest collaborative software project in the world has already worked out that capability is separable from authority, and has encoded it as a merge requirement. It has done so with a git trailer and a norm, because no standards body has given it anything better.

What WEKID adds

Everything above describes a set of controls that exist, that mostly work, and are almost never turned on. However, there is one accountability question that no standard answers. WEKID's contribution is not another scanner. It is the two judgements that sit above the scanners and decide what their output means.

Model One — Artefact Maturity. Score the evidence in five layers: Data (are the sources and requirements real), Information (is it complete and in context), Knowledge (does the implementation follow from the requirement), Experience (has it actually been operated, with attributable outcomes), Wisdom (should it hold authority at all). Lower layers gate higher ones — and gate in the strict sense: no layer may sit more than one rung above the layer beneath it, and the weakest layer binds the result. Polished documentation cannot rescue unsound code, and sound code cannot rescue fabricated requirements. Gates cap rather than average: a fabricated API, dependency or test result ends delegation outright, whatever the rest of the picture looks like.

Model Two — Release Authority. Maturity earns a ceiling: the most delegation this evidence has justified. Consequence imposes a floor: the minimum human authority these stakes demand. The assignment is always the more conservative of the two. Strong evidence never overrides high stakes; low stakes never excuse weak evidence. And an artefact that fails a hard gate never reaches authority evaluation at all — the Trust Bridge halts before that question is asked.

The Authority Levels run:

• AL-0 — informational only, nothing downstream may rely on it — through
• AL-1, whitelisted, reversible, impact-capped actions;
• AL-2, the agent proposes and stages while a human releases each consequential change; to
• AL-3, autonomous execution within an assigned scope, with logging, sampling review and rollback. AL-3 is the maximum delegation the framework admits.
• AL-4 is not more autonomy — it is the reservation of the decision itself to accountable human judgement, with the agent's full analysis and audit trail attached.

That reservation is a governance choice about who bears consequence, not a prediction about what AI will never be able to do. It is also, note, exactly what the Linux kernel decided independently, and for the same reason.

Two properties matter more than the taxonomy. The first is that the evidence must not come from the party being judged. A maturity layer scored by the team that built the artefact is an assertion, not evidence, and the framework treats it that way: self-attested inputs cannot reach AL-3 no matter how high they are scored. That constraint exists because the argument this article makes about AI-generated tests applies with equal force to AI-assisted governance — a framework that accepted self-report would be committing the error it was built to catch. The evidence has to come from the pipeline: dependency and symbol resolution for fabrication, requirement-to-source traceability for data integrity, deployment history and rollback rate for experience.

The second is that capability alone does not purchase autonomy. AL-3 is additionally conditional on demonstrated overseer engagement, precisely because an agent good enough to stop watching closely is an agent whose supervision has quietly hollowed out. That is Bainbridge's Ironies of Automation, forty years old and still the most under-priced result in this field.

The framework is specified in the WEKID™ Master Whitepaper, which defines the Authority Levels, the Trust Bridge and the two-determinant resolution; the WEKID™ Ontology Supplement sets out why Experience — not Knowledge — is the pivot between capability and the right to act, which is exactly the distinction an AI coding agent collapses. WEKID Governed Delivery walks the whole sequence as a working tool: define the product, declare the AI build and its safeguards, instrument the pipeline, score the artefact, assign the authority — and export a governed PRD together with GitHub Actions and GitLab CI templates carrying the authority gate.

What to do on Monday

Six things, in the order of how cheap they are relative to what they buy:

1. Make repository governance a generated artifact. Branch protection, required status checks, required reviews, Codeowners and signed commits at repo creation, from a template, by API. It is the cheapest gap in this entire article to close and no vendor is closing it for you.
2. Put the security policy where the agent cannot edit it. GitLab scan execution policies do this natively. On GitHub, own the required-check definitions outside the repository being edited. If the gate lives in a file the agent is authoring, it is not a gate.
3. Turn blocking on. Every platform you already use ships the scanner enabled and the block disabled. Replit, Lovable and Sonar all have the switch. Flip it.
4. Source the tests differently from the implementation. Property-based testing derived from the specification, or tests written by a different model with no sight of the implementation, or human-authored acceptance criteria. Coverage percentage is not evidence when the agent wrote both sides.
5. Record the human. Adopt Assisted-by: for agent involvement and require a named human sign-off on the merge. You do not need to wait for a standard; the kernel didn't.
6. Score, then bound. Compute maturity from pipeline evidence, set the floor from consequence, and let the more conservative of the two decide what ships without a person. Then publish the decision, so that when something goes wrong the record shows who held the authority — which is the only question that will actually be asked.

The close

The market has assembled every component of the answer and shipped none of them together. GitLab has the unoverridable gate. Harness has the pipeline generation. Endor and Snyk have runtime enforcement. Socket has enforcement below the agent. Kiro has the honest attempt at the test problem. Cortex has the right target shape. The Linux kernel has the accountability model. Nobody has combined them, and every default across every vendor is set to velocity.

Meanwhile the volume of AI-built enterprise software keeps rising, and the failure profile keeps shifting away from the defects our tools catch and towards the defects that require judgement.

DevSecOps for the masses does not mean everyone learns DevSecOps. It means the pipeline arrives with the code, generated by the same act, on by default, and not editable by the thing it governs.

And the authority to release arrives separately, attached to a human.

Sources

Framework documents Judge, J. M., WEKID™ Master Whitepaper v1.3 — the Epistemic Maturity Model, the AI Decision Authority Model (AL-0…AL-4), the Trust Bridge, the maturity ceiling and stakes floor, hard gating rules and sector calibration profiles. WEKID LLC, 2026. Judge, J. M., Supplementing the WKID Ontology with an Experience Layer (Ontology Supplement v1.0) — Experience as a first-class epistemic category and the pivot between knowledge and the right to act; extends Ackoff's Understanding rung for governed human and machine action. WEKID LLC, August 2026.

Empirical record Zhao, S., Wang, D., Zhang, K., Luo, J., Li, Z. & Li, L. — Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks (SusVibes). arXiv:2512.03262 v2, February 2026 (v1 December 2025). 200 feature-request tasks from 108 open-source projects, 10 security domains, 77 CWE types, 162,000-LoC average context. Security is scored conditional on functional correctness.

Veracode 2026 GenAI Code Security Report (28 Jul 2026) and Spring 2026 Update (24 Mar 2026) · Apiiro, "4x Velocity, 10x Vulnerabilities" (Sep 2025), figures as reported by The Register · Perry et al., "Do Users Write More Insecure Code with AI Assistants?", ACM CCS '23 · "Security Weaknesses of Copilot-Generated Code in GitHub Projects", ACM TOSEM (2025) · Spracklen et al., "We Have a Package for You!", USENIX Security '25

Vendor documentation (all claims above are from the vendors' own docs) docs.lovable.dev · docs.replit.com · v0.app/docs · docs.base44.com · support.bolt.new · docs.github.com/copilot · code.claude.com/docs · docs.devin.ai · cursor.com/docs · kiro.dev/docs · docs.gitlab.com · developer.harness.io · docs.sonarsource.com · vercel.com/docs/agent · docs.endorlabs.com/agent-governance · docs.socket.dev · docs.semgrep.dev/guardian · snyk.io

Incidents CVE-2025-53773 (embracethered.com) · Nx s1ngularity (Wiz, StepSecurity, The Hacker News) · "Comment and Control" credential theft from CI runners · CVE-2025-48757 (NVD, disputed by vendor) · AWS security bulletin AWS-2025-019 · Replit production database deletion, July 2025 (AI Incident Database #1152)

Standards and regulation SLSA v1.2 Source Track · in-toto Attestation Framework v1.2.0 · CycloneDX 1.7 / ECMA-424 · CISA 2026 SBOM Minimum Elements · NIST SP 800-218A · Linux kernel Documentation/process/coding-assistants.rst · LLVM AI Tool Policy · Regulation (EU) 2026/1744 (Digital Omnibus on AI), amending the application dates for EU AI Act Annexes I and III · Commission Delegated Regulation (EU) 2024/1774 Art. 16 · NIS2 Art. 20

© 2026 WEKID LLC. WEKID™ is a trademark of WEKID LLC.