I joined GitLab at a moment when the way teams build and secure software has been changing rapidly. GitLab CEO Bill Staples recently framed that shift in When Code Is Abundant. When code is no longer the bottleneck, trust becomes scarce, and that constraint shows up first in what reaches production.

As a CISO accountable for the same decisions as my peers, my operating thesis is simple: Detection is not defense. Agentic software development stays trustworthy only when security, governance, and guardrails sit in the path from plan to production. Leaders must continuously know the attack surface, constrain execution, and close the loop from finding to verified fix at machine speed. The metric that matters is time from detection to verified remediation, not the count of scans run, tickets opened, or reviews completed.

That metric becomes more relevant as the economics of an attack change. The risks themselves are familiar: an open server, an over-scoped credential, or an exposed deployment path. AI models make these conditions faster and cheaper to discover, connect, and exploit. I find that more unsettling than a novel zero-day because the exposure was already in our environment; the difficulty of uncovering it was part of what protected us.

Anthropic and OpenAI have both described this shift publicly, and so has every security team I've talked to this year regardless of industry: advanced models and agentic systems are compressing the time and cost required to find and exploit weaknesses. Open weight models are catching up quickly with the most capable security systems available today, which means capabilities that recently lived inside a small set of labs will become available to a much wider set of threat actors.

I can see that acceleration inside GitLab. We have published 317 CVEs so far in 2026, compared with 181 in all of 2025 and 170 in 2024. Our bug bounty program received just over 3,600 reports in the last 90 days, compared with 1,440 in all of 2024.

The same shift, industry-wide

We are not an outlier. In April, the National Institute of Standards and Technology (NIST) stopped enriching most CVEs, conceding that a record year of output still wasn't enough. This year's Verizon Data Breach Investigations Report put exploitation of vulnerabilities ahead of credential abuse as the leading initial access vector for the first time in 19 editions, with median time to resolution slipping from 32 days to 43.

The Forum of Incident Response and Security Teams (FIRST) made the same point this summer. Published advisories and incoming reports measure different things, but they create the same operating pressure: Discovery volume is rising faster than teams can verify, prioritize, and remediate what matters.

Severity models still assume a finding stands alone, but agents can chain a low-severity flaw, an overly broad permission, and an exposed path into a material attack. A queue sorted by CVSS increasingly misses that context while the backlog grows faster than teams can clear it using their traditional tools and processes.

The operating model must change with the economics of attack. Security controls must sit in the execution path, with a closed remediation loop behind every material finding. That governed path across your software development lifecycle (SDLC), under your guardrails, context, and workflows, is the foundation for an enterprise software factory.

Agentic capability gives defenders an advantage

The risk is real but I wouldn't trade this moment for the one before it. Security teams have always been outnumbered, and our own intake is running about six times the 2025 rate. But capable models change the math in the defender's favor first.

An attacker needs one path in. Defenders have access to the code, infrastructure, deployment paths, configuration, identity systems, and operating context. Point the same capability at the same target and we can see much more, if we use it against our own surface first. Models can turn that broader context into machine-speed discovery, prioritization, and remediation. This has never been true before.

The build process is also becoming observable. For years, much of the work on an issue was not captured in systems that security teams could inspect. Security teams reviewed what remained: the diff, the build, and the running application.

When an agent builds software, construction can become an event stream: file reads, tool calls, commands, credentials issued, systems accessed, and approvals granted. The how becomes a record rather than a recollection, as we govern the act of building software.

This architectural advantage exists when agents run somewhere their actions can be identified, constrained, and recorded. Once the necessary infrastructure is in place, every improvement in model capability strengthens the defensive system.

I believe machine-speed defense requires three layers that strengthen as model capability and commit volume rise across the SDLC.

Layer 1. Find out where you stand

This is the discovery pass for everything that follows. With the assumption that a capable attacker already has the same models you do, you should use those models on your own surface proactively across code, infrastructure, and deployment paths. The goal is a verified picture of where you stand today.

Frontier labs sit closest to the capability curve, which is where new AI model capacity first shows up in both offense and defense. Their contribution raises the defensive posture the rest of the industry can build on: model-assisted discovery pointed at real systems, and remediations drafted by agents with your team approving the change. We are running that with Anthropic on Project Glasswing, using their models across our critical systems and products, and repeating the pass when a stronger model arrives.

We then use GitLab Duo Agent Platform to continuously triage and remediate those findings, reduce the introduction of new issues, and ship software that has already been verified before production. We are customer zero for the bar we hold the software industry to, as we aim to translate that into trust in what you build on our platform.

Layer 2. Strengthen your foundation

A baseline tells you where you are. The harder problem is maintaining it while code volume, agent capability, and attacker capability continue to increase.

That foundation must satisfy six requirements.

  1. Know and continuously scan the entire attack surface. Static application security testing (SAST), dependency, container, secret, API, and dynamic application security testing (DAST) must run as one coverage model. Third-party scanners must feed a common vulnerability management system. An organization cannot reason about risk from partial inventories with different identities, severities, attack paths, owners, and remediation states.
  2. Eliminate exposed and long-lived secrets. Centralized secrets management, least privilege, rotation, revocation, and secret detection must be defaults in the paths that create and deploy software. Every credential must have a defined identity, scope, lifetime, and revocation path.
  3. Turn vulnerability discovery into continuous remediation. Eliminate false positives, prioritize real vulnerabilities in context, and use agents to generate, test, and validate fixes. A finding stays open until the proposed change is proven against the relevant code, configuration, and deployment path. Discovery without verified remediation is inventory growth, not security progress.
  4. Put policy in the execution path. Scans, approvals, separation of duties, and deployment controls must be centrally enforced where work executes. Developers and agents cannot be responsible for remembering which policy applies or navigating the correct handoff.
  5. Treat agents as privileged actors. Every agent needs an explicit identity, minimum permissions, constrained tools and credentials, sanctioned access paths, and auditable actions. High-risk operations need an attributable approval boundary, especially as agents move from suggesting code to acting across repositories, CI/CD systems, cloud infrastructure, and production.
  6. Measure time from detection to verified remediation. Track how long a real vulnerability remains exposed from detection through a fix proven in the relevant environment. Segment it by severity and attack path, then drive it down continuously. For machine-speed attacks, this becomes the primary operating metric.

These requirements work together: continuous coverage so findings have somewhere to go, fixes tested on the path they ship on, policy where the work runs, and agents with their own identity instead of a developer’s access token.

Layer 3. Protect what already shipped

Software and its environment keep changing after production. The artifact you shipped last month can become vulnerable because of a disclosure next month, with exploitation following within days and sometimes preceding an available patch.

As a result, catching up once is not enough: keep scanning after the merge, reassess production as stronger models arrive, and land fixes in the same developer workflow that produced the change. Finding more issues without governing merges and closing fixes only accelerates the backlog.

The operating model is to enforce the security you already have, measure time from detection to verified remediation, and keep customer experience checks in the same build path as security.

WHAT MY PEERS ARE SAYING

Cybersecurity experts and peer CISOs are describing a similar operating approach in an effort to enable governance and remediation at the speed of development.

“Machine scale discovery without an equally fast path to governed remediation is not progress. It is an inventory problem dressed up as security. The organizations that will hold up under agentic development are the ones that treat detection as the start of a closed loop: policy on every change, remediation in the build path, and a baseline they can re-verify as models improve.” Gadi Evron, CISO-in-Residence for AI, Cloud Security Alliance

“A durable security program for agentic software development keeps every agent on lawful rails: an explicit identity, constrained permissions, and a sanctioned path from plan to production. An agent working outside those rails is lawless: no identity, no record, no way to govern what it touched. That discipline has to hold as models improve and agent volume rises.” Bill Shields, CISO, Workday

“Trust in what you ship depends on continuous hardening of the models and development platforms you build on and governance of every change in your software lifecycle. Those layers reinforce each other, and neither substitutes for the other.” Sam Curry, Chief Security Officer, Zscaler

The shadow software factory is an architectural problem

As agents produce a larger share of the code, your SDLC is splitting in two. One path runs through governed repositories, CI/CD systems, identity controls, approvals, and security tooling. The shadow path runs through personal laptops, local credentials, unmanaged tools, and agent sessions outside those controls. It may produce valid code, but without a reliable record of how that code and its related infrastructure changes were made.

A commit shows whose credential was used, but it reveals little about the agent, tools, permissions, commands, and external systems behind the change. Capturing that evidence requires a governed execution environment that connects identity, permissions, tools, policy, and approvals. Without it, security teams inspect artifacts after the important actions have already occurred.

Capturing events is only the beginning. At agentic volume, a complete transcript becomes another backlog. Security systems must turn those events into enforceable policy, attributable decisions, and verified outcomes. Tool calls are evidence, and an agent's explanation of its own reasoning is secondary.

What this looks like in practice

On GitLab, that architecture is becoming concrete. Policy sits in the execution path. Scanning runs where developers and agents already work, early enough that the fix is cheap. Third-party findings converge in one vulnerability system, and agents turn validated findings into tested merge requests carrying the application context needed to fix them. Secrets are short-lived, scoped, and revocable by default. High-risk agent actions stop at an attributable approval boundary. If the pipeline cannot prove it, the pipeline does not ship it.

Authorship capacity is becoming elastic while human review capacity remains constrained. Before we automated, human application security review reached roughly 1% of our merge requests. On a recent release, we ran agentic security review across 969 of 997 eligible merge requests, or 97%. A year ago, that level of coverage was inconceivable. Today I treat it as the expectation.

GitLab brings these controls together across the platform. GitLab Duo Agent Platform closes agentic triage and remediation loops on the same governed path as source, security, CI/CD, and merge. If you are a GitLab customer, the opportunity is to put those controls in the execution path and measure whether they shorten your exposure time from detection to verified remediation.

The deeper architectural question is whether agentic work runs through the same governed foundation for your software factory. When it does, teams and agents share a common control plane. When it does not, the shadow software factory persists regardless of how much security tooling surrounds the downstream pipeline.

Making the operating model concrete

A credible program can answer these questions from its operating data:

  • What is the complete attack surface, and when was each surface last scanned?
  • Which findings are real, which are false positives, and who or what made that determination?
  • How long did each real finding remain exposed before a fix was verified in the relevant environment?
  • Which secrets were issued, to whom or what, with what scope, for how long, and how were they revoked?
  • Which agent performed each action, through which sanctioned path, with which tools and permissions?
  • Which policy, approval, separation of duties check, or deployment control stopped or permitted the action?
  • Can an independent reviewer replay the evidence and reach the same conclusion?

Those answers should become increasingly automatic. A program that is working keeps coverage continuous across the full attack surface, puts an attributable owner and a tested remediation path behind every material finding, and either eliminates exposed and long-lived secrets or time-boxes them with compensating controls you can defend. Agents run through sanctioned identities and constrained permissions, with a recorded approval on high-risk operations, and you measure detection to verified remediation continuously, by severity and by attack path, driving that time toward machine speed.

We are learning what that takes by running the model ourselves. In the coming months, GitLab will publish a blueprint that turns these principles into operational guidance: the controls, architecture, metrics, and practices to establish a baseline. The blueprint will aim to help you keep agentic software development on a governed path, eliminate shadow production work, and continuously move findings through verified remediation.

The goal is practical: Give security and engineering leaders something they can implement and measure, regardless of where they are starting.

The standard has changed

I'm writing this as a peer accountable for the same class of decisions you are. When code generation is abundant and trust is scarce, your agentic software development demands machine-speed verification and remediation. Security, governance, and guardrails have to be part of your foundation, not a set of gates around it.

The opportunity right now is unusual. The same models increasing offensive capacity can also expand defensive capacity. As cybersecurity professionals, we have more context than the attacker, greater access to our own systems, and a chance to make the construction of software itself observable and governable. We have to use that advantage.

Expect continuous hardening from the platforms you build on. Ask for evidence of what they find, how quickly they remediate it, and whether the controls survive the next increase in model capability. Apply the same standard to your own software development. GitLab customers can use Duo Agent Platform to bring agentic triage and remediation into the same governed path as source code management, CI/CD, and the rest of the SDLC.

The new standard now is to move “detection to verified remediation” at machine speed.

Join us at Transcend, our livestreamed event on October 6, where we will dive deeper on the topic and share our latest innovations to help you secure your agentic software development.