Part 3: Who Closes the Second Loop?”

Series: Part 3 of 3

Parts 1 and 2 of this series made two arguments.

First: CTEM’s mobilization stage closes the loop on findings. It doesn’t close the loop on fixes. AI-proposed remediations re-enter your codebase as unverified code, and most vulnerability management workflows have no process for that.

Second: fix verification isn’t a single control. It’s a tiered risk decision — automated rescan gates for bounded, well-understood fixes; senior practitioner review for complex logic, critical assets, and AI-generated code where no human holds a complete mental model.

This part asks the operational question both of those arguments were building toward: who actually runs this, and what does it take to do it reliably?

What the Model Requires

Be honest about what Tier 1 and Tier 2 verification demand before you decide how to staff them.

Tier 1 is an engineering problem.

Running MDASH as a post-fix pipeline gate requires integration work. The CLI needs to be embedded in your GitHub Actions or equivalent pipeline. The rescan needs to run against the fix branch before merge. Pass/fail criteria need to be defined and enforced. Results need to feed back to the same initiative dashboard your security team is already using.

None of this is technically complex. All of it requires someone to own it, build it, and maintain it as the toolchain evolves. In most organizations, that work sits in a gap between the security team and the platform engineering team, which means it either doesn’t get built or it gets built once and quietly degrades.

Tier 2 is a people problem.

Senior practitioner review against defined criteria requires practitioners who can sit at the intersection of security depth and code comprehension. They need to understand what MDASH found, why Copilot proposed the fix it did, whether the fix scope is appropriate, and whether any net-new risk was introduced.

That is not a common skill profile. It is not produced by a security certification path or a development career path alone. It requires deliberate development, and it requires enough volume of Tier 2 reviews to keep the skill sharp.

Most organizations have two or three people who can do this well. That is not enough to run Tier 2 verification at the velocity AI-assisted development produces.

Where Most Organizations Actually Are

Across AppSec programs right now, the gap between where teams are and where this model requires them to be shows up in three places consistently:

No post-fix scan gate exists. The pipeline runs SAST on the original code. It does not rescan after remediation. The fix merges through code review alone. This is the default state of most AI-assisted remediation workflows today.

Tier criteria aren’t defined. Teams know that complex changes need more scrutiny. They don’t have a written threshold for what “complex” means in the context of AI-generated code, or what “sufficient comprehension” means as a reviewer qualification. The norm exists. The decision rule doesn’t.

Mobilization metrics measure closure, not verification. Dashboards show findings closed and mean time to remediate. They don’t show whether Tier 2 criteria were met, whether the post-fix rescan was clean, or whether the practitioner who signed off had the right skill profile. The metric looks good. The control is invisible.

None of this is negligence. It’s the natural state of a program that was well-designed for the problem it was built to solve, encountering a problem it wasn’t built for.

The Build vs. Partner Decision

If you’re running an AppSec program and you’ve read this far, you’re probably doing the math on what it would take to close these gaps internally.

Here’s the honest version of that math.

The Tier 1 integration is buildable internally for most organizations with a mature platform engineering function. It requires a few weeks of work, a defined owner, and a commitment to treat it as infrastructure rather than a one-time project. If you have the engineering capacity, build it. The tooling — MDASH, GitHub Advanced Security, Defender for Cloud — is already there. The pipeline integration is the gap.

The Tier 2 staffing problem is harder to solve internally at scale. You can build the criteria. You can identify two or three practitioners who can run the reviews. You cannot easily scale that capacity to match AI-assisted development velocity without either hiring specifically for this profile — which the market does not have in abundance — or accepting that Tier 2 reviews will become a bottleneck that slows down the remediation cycle this toolchain was designed to accelerate.

That bottleneck is worth taking seriously. A Tier 2 review that takes a week defeats a significant part of the value of AI-assisted remediation. Speed matters. So does verification. The operating model needs to deliver both.

What a Mature Second Loop Looks Like

Whether you build it internally or bring in external capacity for the Tier 2 layer, the operating model has the same shape.

Discovery stays in your pipeline. MDASH runs on every scan surface — CLI for developer-local, GitHub Actions for the pipeline gate, agentless for running workloads. Findings roll up to the Defender for Cloud initiative view with runtime context and attack path correlation. Nothing changes here from current best practice.

Mobilization has two explicit exits, not one. Tier 1 findings close when the post-fix rescan is clean. Tier 2 findings close when the rescan is clean AND practitioner sign-off is recorded against defined criteria. Both exits are documented in the pipeline. Neither is optional.

Metrics reflect verification, not just closure. Mean time to remediate is still a useful metric. It is not sufficient on its own. Add: percentage of fixes with post-fix rescan completed, Tier 2 review cycle time, and practitioner qualification rate for Tier 2 reviewers. These metrics make the second loop visible in a way that finding-closure metrics don’t.

The skill baseline is maintained deliberately. Tier 2 reviewers need regular exposure to AI-generated vulnerability classes to stay current. This is not a one-time training investment. The attack surface is evolving. The reviewer skill baseline needs to evolve with it.

Three Things to Implement This Week

Regardless of how you resolve the build vs. partner question, these three changes are available to any team right now:

1. Add a post-fix rescan step to one pipeline. Pick your highest-criticality repository. Add MDASH as a gate after Copilot-proposed fixes, before merge. Run it for four weeks. Look at what it catches. That data will tell you more about your second loop gap than any assessment will.

2. Write down your Tier 2 criteria. It doesn’t need to be perfect. It needs to exist. Define what triggers senior practitioner review — at minimum: auth/authz code, internet-exposed assets with sensitive data paths, AI-generated code above a complexity threshold. Get it into your CTEM mobilization process documentation.

3. Change one metric. Add “post-fix rescan completed” as a condition on your finding-closure definition. Even informally, as a team norm. Closing a finding without a clean rescan becomes an exception that requires documentation, not a default that goes unnoticed.

None of these close the entire gap. All of them make the gap visible — which is the prerequisite for closing it.

The Actual Stakes

CTEM works. The framework is sound and the toolchain supporting it — MDASH, Security Copilot, GitHub Advanced Security, Defender for Cloud — is the most capable it has ever been.

The risk isn’t that the tools fail. The risk is that the operating model around the tools doesn’t keep pace with what the tools are now doing. AI-assisted remediation is faster, more contextual, and more scalable than anything that came before it. It also introduces a class of unverified code into your environment that your existing mobilization process wasn’t designed to catch.

The second loop is closable. It requires deliberate design, defined criteria, the right skill profile at the Tier 2 layer, and metrics that make verification visible rather than assumed.

Most programs haven’t built it yet. The ones that build it now will be ahead of a problem that is only going to get harder to retrofit later.

The Second Loop is a three-part series on what CTEM’s mobilization stage gets wrong in an AI-assisted development environment, and what to build instead.

Part 1: AI proposed your last fix. Did anyone scan it?
Part 2: Fix Verification Isn’t a Code Review. It’s a Risk Decision.