Building an enterprise AppSec program with Claude

Claude Security, in public beta for Enterprise customers since April and updated on 21 October, now offers continuous scanning of repositories, fix tracking, a threat model per project, and an API. Claude Code already sits in the developer's editor. Mythos 5.1, the configuration of Anthropic's frontier model with cyber safeguards relaxed for vetted defenders, finds vulnerabilities at a scale no team can fix. A security leader now has to answer a reasonable question from the CIO: can we build the application security program on Claude?

Claude changes four of the six things a program does: it takes time out of design, triage and remediation, and it widens what static testing can find, at a metered cost per scan. The other two, inventory and measurement, depend on reproducible evidence, the same state giving the same answer, and Claude does not produce it. This post lays out the six, places each Claude product against them, describes how the work splits between security and development, lists what the CISO is measured on in 2026, and ends with the step that turns findings into a number the board can act on.

1. What an application security program is, before any tool

Every mature program runs the same six functions. BSIMM16, which measured 111 firms and 91,200 applications this year, and OWASP SAMM describe them in different words with the same shape.

• Inventory and ownership. What applications exist, what they expose, who owns each one.
• Secure design. Threat modelling, standards, and the architecture decisions that remove whole classes of defects.
• Testing. Static analysis, dependency analysis, dynamic testing, penetration tests.
• Triage and risk ranking. Deciding which findings matter in this application.
• Remediation. Getting fixes made, within agreed timelines, by people who have other work.
• Measurement and governance. The numbers that go to the board, and the policies that gate releases.

Figure 1. The six functions of an application security program, before any tool. Most of the cost sits in the last three, and three 2026 trends push more work into them.

Most of the cost sits in the last three. The scanners are a small share of the budget; the hours go into deciding what matters, getting it fixed, and proving that it was. That ratio was set by licensed scanners. Metered model scanning on every commit can change it. Three 2026 numbers explain why the cost of the last three is rising. Veracode's test of more than 150 models puts the security pass rate of AI-written code at 55 percent, where it has sat for two years. Georgia Tech has traced 74 published CVEs to AI-authored commits, 35 of them in one month. The Verizon DBIR reports that 31 percent of breaches now begin with an exploited software vulnerability, ahead of stolen credentials. More code, written faster, with the same defect rate, and attackers using the same models to find the defects.

2. Three different things called Claude

The question "can we build on Claude" has three answers, and each reaches a program in a different form.

Product	What it does	Program functions it touches	What it does not do
Claude Security Enterprise, public beta	Runs on Mythos 5.1. Deep baseline scan, then continuous scanning of changes. Verifies its own findings against the code before surfacing them. Generates a threat model per project that the team edits. Tracks whether open findings were fixed. Up to eight repositories per project. API and MCP connectors.	Testing, triage, remediation tracking	Produces no inventory of its own. Two scans of the same code can return different results; Anthropic's documentation says scans are "stochastic by design." Verifies against the code, not the deployed application.
Claude Code Developer session	Reviews code on request, writes fixes, runs hooks after every edit. Open source checks such as ai-surface, APIsec's free tool that maps the agents, tools, MCP servers and LLM calls in a repository and flags high-risk actions, run inside it and report before the commit.	Testing, remediation	Acts only on what it is pointed at. Has no view across the estate. Its fixes need a reviewer.

Mythos is the third, and the line between it and the rest is the useful part. Fable 5.1, the generally available configuration of the same model, finds vulnerabilities in source code. Claude Security users get Mythos findings without direct access to the model. Anthropic's safeguards route exploit generation, penetration testing and binary scanning to its Opus models. Finding is now generally available. Proof is a separate step: a test of the customer's own deployed application, run with their authorization from inside their environment, with the request and response logged.

3. Where Claude fits, function by function

Figure 2. The six functions and where Claude does the work. Security owns every function; this figure shows the tooling. Claude does the work in four. Inventory and the board number need reproducible evidence from another source.

Inventory is not Claude's job. A model reads what it is pointed at. It does not enumerate what exists across two thousand repositories, which routes they expose, or which service calls which. That needs deterministic extraction, run on every commit, producing the same answer each time. Programs that start with a model and no inventory end up with findings they cannot place.

Secure design gets better. Claude Security's generated threat model is the most useful artefact in the product, provided the program owns it. Severity ratings inherit its assumptions. If the threat model says an internal API is unreachable and it is not, every finding on that API is rated wrong.

Testing needs both kinds of tool. Rules find what is repeated and complete: every by-id handler without an ownership check, every query built from a request parameter. A model finds what rules cannot express: an ownership check that covers one branch and not the other, a filter that is a language mistake. In our own comparisons, each found defects the other missed, on the same code. Run both. Treat a stochastic result as a candidate, not a verdict. Model-based scanning is billed by token usage (Anthropic's documentation describes Claude Security as charged at direct token cost, with a separate spend limit), so it widens coverage rather than lowering the cost of this function, and the bill scales with code volume and change rate. Dynamic testing, the runtime half, is covered in section 6.

Triage is the best use of a model today. Given the facts from the inventory (this finding sits on a route with no authentication, reachable from the internet, with request data flowing to the line), Claude writes the explanation a developer will read, collapses duplicates, and answers the "does this apply here" question faster than a person. Given no facts, it guesses.

Remediation shrinks. The finding arrives in the developer's session with a proposed fix. A reviewer approves it. Fix tracking marks it closed. Closed is not confirmed: validation re-runs the same test against the running application and shows whether the path is gone. Who is allowed to approve an AI-written security fix is a policy decision, and it should be made before the first one lands.

Measurement gets remediation time, not validated exposure. Fix tracking produces a useful number: how long findings stay open. It does not produce the number the board asks for, because nothing above tests the running system. That number comes from section 6.

4. Program dynamics: security and development

Security owns the outcome. Developers own the code and the context: how the application is deployed, what is reachable, what the data means. Every program succeeds or fails on the handoff between those two groups, and Claude's largest effect falls on that handoff.

What improves: the finding arrives where the developer works, with the lines, the reason and a proposed fix, instead of as a ticket from a dashboard. The hook model goes further: a check runs after every edit and speaks up before the commit, then confirms when a later edit removes the risk. Developers use tools that live in the session and forget tools that need a separate command.

What gets worse if nobody manages it: a wrong finding delivered with confidence inside the session costs more trust than a wrong finding in a dashboard, because the developer acted on it. Stochastic results make this harder. A finding that appears in one run and not the next looks like noise to the person asked to fix it.

Four operating rules hold the handoff together.

• A finding carries its evidence (route, auth state, data path, line) or it does not go to a developer.
• Fixes are proposed by the model and approved by a person. The confirmation step shows whether the fix removed the path; it does not replace the review.
• Security owns the rule catalog and the threat model. Development owns the fix and the deployment facts.
• One place shows what was found, what was fixed, and what was proven, for both teams.

5. What the CISO is measured on

CISOs set the priorities. Gartner's community of 1,600 CISOs ranks enabling and protecting AI, managing cyber risk, and optimising the tool estate as the top three. Boards set the measures: exposure quantified in business terms, time to remediate, and regulatory position under SEC disclosure rules and the EU Cyber Resilience Act. Praetorian puts the shift in one line: "The metric that matters is not how many vulnerabilities you found but how many validated attack paths you closed."

None of those measures are findings counts. Claude raises the findings count. Without a validation layer, an AI-assisted program makes the board number worse before it makes it better: more candidates, the same number of people, and no way to say which candidates an attacker could use.

Five questions a CISO should ask of any program built on a model

• Which of these findings were proven against the running application, and how?
• Which fixes were confirmed to have removed the path, by re-running the same test?
• If we scan the same commit three times, how much does the list change?
• Where does our code go, which model reads it, and who approved that?
• What does a full scan of the estate cost per month, and what happens to that number as commit volume grows?

6. Runtime validation: the step that turns findings into a number

Finding is now generally available. Proof is an execution problem, not a model problem: it needs requests sent to the deployed application, with authorization, and the responses logged. A code scanner does not do that, whichever model powers it. Validation is the runtime half of Testing, and the only part of the program that runs against the deployed application rather than the code.

APIsec does this through Application Exploit Validation (AEV). The term collides with Gartner's "adversarial exposure validation," a category of infrastructure and attack-simulation tools; here it means something narrower. Four parts:

• Application-bounded scope. The target is one application and its runtime, not an estate-wide attack simulation.
• A validation harness. Each candidate becomes a test derived from the code facts (the route, the parameter, the identities involved) and runs against the live API through a hosted agent in the customer's environment.
• Replayable evidence. Every verdict is a logged request and response that a reviewer can run again.
• Remediation outputs. Confirmed findings go to developers with the proof; after the fix, the same test re-runs and the verdict flips to cleared.

A worked example. FastLedger is a benchmark we built: a FastAPI service with 62 record types and 373 endpoints, no ownership checks of its own, behind a gateway that enforces ownership, with one route left open on purpose. The shape is common in large estates: by our estimate, about half of object-level authorization there is enforced outside the application code, in a gateway, a policy engine, the database or the token, so a static reader of the service sees the control as missing when it is not. Static analysis predicts 248 object-level authorization defects: each of the 62 record types has four by-id handlers (read, history, update, delete). A model reading both components could say only that exploitability depends on whether the API is reachable past the gateway. The runtime scan ran 62 scenarios, one per record type, in which one user creates an object and a second user attempts all four handlers on it. It cleared 247 and confirmed 1, on the open route, in three minutes. That is the number: 248 reported, 1 proven, 247 cleared. After the fix, the test re-runs and the 1 becomes 0.

Figure 3. FastLedger, 23 October 2026. 248 static predictions, 1 proven exploitable, 247 cleared in three minutes. After the fix, the same test returns 0.

The 247 cleared because of the gateway's configuration, not because the code changed. A new service binding, a debug route or a policy edit can flip them back. Validation therefore re-runs on infrastructure and configuration changes as well as on commits, so it has to be a runtime step rather than a one-time check.

7. The program as a loop, and where APIsec sits

Claude Security and Claude Code produce the candidates and the fixes. APIsec Surface, our family of extraction tools, reads the application code and the systems it runs through and produces the inventory: routes, parameters, authentication on each route, data flows and libraries. Surface places each candidate on that inventory. AEV proves which candidates are exploitable and confirms which fixes removed the path. The platform also carries the policy model and the CISO reporting, so the last two steps of the loop run on it as well. The CISO reports "P of N proven exploitable, M now cleared," measured the same way on every commit and every configuration change.

Figure 4. The same six functions with the full tooling: Claude, APIsec Surface and the APIsec platform. Solid: does the work. Hollow: supplies input but does not finish the job. Compare with Figure 2.

Figure 4 shows who covers each function. Figure 5 shows the order they run in.

Figure 5. The program as a loop. The eight steps are the six functions in running order; Testing, and Measurement and governance, each take two steps. Steps 1 to 4 build the list, 5 to 8 close it, and the loop re-enters at 1 on the next commit. What each step produces: facts (1), written assumptions (2), candidates (3), an ordered list (4), a reviewed change (5), a logged request and response (6), the board number (7), policy (8). Dashed rings mark the two steps whose evidence is reproducible.

APIsec does not compete with Claude on model-based finding. It supplies what a model cannot: an inventory that comes out the same way twice, rules that catch every instance of a repeated pattern, and requests sent to the running system with the response recorded.

Closing

The program is the same six functions it was before Claude. Claude takes time out of three of them: design, triage and remediation. It widens the static half of testing, at a cost per scan. Both effects will grow as the models improve. Inventory and measurement still depend on reproducible evidence. The board will keep funding the program that reports validated and confirmed rather than found. Surface's CLI and the first validation run are free to start on one application: read about Surface and the platform, or run the first test on your own application.

---

Sources: Anthropic, Introducing Claude Fable 5.1 and Claude Mythos 5.1, 1 September 2026 (same model, different safeguards; source-code vulnerability discovery generally available; exploit generation, penetration testing and binary scanning routed to Opus models); Anthropic, Claude Security product page (continuous scanning, fix tracking, editable threat model, API); Anthropic, Claude Security is now in public beta, 30 April 2026; Anthropic, Use Claude Security, help documentation (findings verified against code; up to eight repositories per project; powered by Mythos; no direct model access; "scans are stochastic by design"; charged at direct token cost; a separate spend limit for Claude Security; 21 October 2026 update per the launch offer terms); BSIMM16, Black Duck, February 2026 (111 firms, 91,200 applications; AI the top force for the first time); Veracode GenAI Code Security, March 2026 (55 percent pass rate across more than 150 models); Georgia Tech Vibe Security Radar via CSA, 2026 (74 CVEs traced to AI-authored commits); Verizon DBIR 2026 (31 percent of breaches begin with an exploited vulnerability, ahead of stolen credentials); Gartner C-level Communities CISO survey 2026 (1,600 CISOs); Praetorian, CISO priorities 2026. The worked example is from APIsec Labs' FastLedger run, 23 October 2026.