Table of Content
Context and Scope
This article extends the argument from “A Pragmatic Guide to Being Mythos-Ready.” That article focused on compression of time. Discovery, testing, refinement, weaponization, and the fact that action are getting faster. This article applies the same cost-model shift to application security and vulnerability management. (If you have not read the guide I would highly recommend reading it first then going through this article)
The current defensive response to AI is still centered on better vulnerability queues. Teams want better scanner output. They want better reachability analysis. They want better exploitability scoring, faster CVE enrichment, and improved prioritization.
These improvements have value. They help in large environments with many assets and many findings. Their limitation is that they still assume the older operating model.
The older model was built around scarcity of time and effort. Defenders had limited engineers, patch windows, tests, ownership clarity, and confidence to change production systems quickly. Attackers also needed time, skill, target understanding, infrastructure, exploit development effort, testing effort, and persistence.
AI changes part of that equation. The attacker still needs context, access, infrastructure, and operational competence. At the same time, more work can move from human effort to automation, compute, and token spend. This changes the economics of exploitation. It also changes the economics of defense.
A useful reference point is Stephanie Domas’ LinkedIn post on Mythos-assisted vulnerability work at Mozilla. The post describes Mythos helping surface 271 security fixes in Firefox 150. These included long-lived parsing, XSLT, JIT, IPC, and process boundary issues. The post also describes the supporting pipeline: agentic harnessing, dynamic test case generation, deduplication, triage, patch validation, release integration, and distributed execution. It also notes that prior defense-in-depth and attack surface reduction work constrained some attempted paths.
That example is useful because it frames AI as part of a larger engineering system. The value comes from AI-assisted discovery, validation infrastructure, release discipline, and previous hardening work acting together.
Where we were: The older AppSec cost model
Application security has spent years improving prioritization.
When vulnerability volume increased, the industry built mechanisms to rank issues. When severity alone produced too much noise, teams added reachability. When reachability still produced too much work, teams added exploitability analysis. When internal context was missing, teams added asset criticality, internet exposure, known exploitation signals, and business impact.
That evolution made sense under the earlier cost model. Vulnerability volume exceeded remediation capacity. Prioritization helped decide what to fix first because most teams could not fix everything quickly or safely.
The older model depended on a few practical assumptions:
- Exploit development required meaningful human effort.
- Attackers had to choose targets carefully.
- Defenders could buy time through ranking and staged remediation.
- CVE enrichment and exploitation signals helped allocate scarce engineering capacity.
- Known lower-priority issues could often remain in the backlog without immediate consequence.
These assumptions were never perfect. They were still useful enough for many security programs. They created the foundation for vulnerability management workflows based on severity, reachability, exploitability, exposure, and business context.
The cost structure around those assumptions is changing.
The newer security cost model
AI reduces parts of the cost of attacker iteration. Code comprehension becomes cheaper. Exploit scaffolding becomes cheaper. Patch diff analysis becomes cheaper. Variant generation and test case generation also become cheaper.
The limiting factors shift toward access, context quality, automation quality, compute, tokens, and operational execution.
For defenders, finding issues and drafting possible fixes also becomes easier. The limiting factor shifts toward verification. The hard question is whether an organization can safely validate, review, deploy, and monitor changes at the required pace.
This changes the core AppSec question.
The older question was: which vulnerability should we fix first?
The newer question is: how much verified remediation can we safely produce?
Verification takes time and effort. Every application, dependency, SaaS integration, internal tool, exposed API, authentication path, and data flow consumes verification capacity. A larger stack creates more things to understand, test, patch, observe, and recover.
The answer cannot be limited to better prioritization. The stack itself has to be reduced to what is needed. Buying more tools, enabling more features, adding more dependencies, and integrating more systems increases the amount of software that must be verified.
In the older model, teams often accepted this growth and tried to prioritize the resulting risk. In the newer model, uncontrolled stack growth directly competes with remediation capacity.
Security programs need to treat stack size as a cost driver. Every new component should justify the verification burden it introduces.
Verification capacity is the constraint
Goldratt’s Theory of Constraints gives a useful way to frame this problem. The Five Focusing Steps are commonly described as
- identifying the constraint,
- exploiting the constraint,
- subordinating everything else to the constraint,
- elevating the constraint, and
- repeating the process as the system changes.
For AppSec in the AI era, verification capacity is becoming the constraint.
Discovery can become faster. Candidate fixes can become faster. Test generation can become faster. Report generation can become faster. These improvements help only when they increase the flow of verified safe change.
If verification remains the bottleneck, faster activity before verification creates a larger queue. Faster activity after verification also has limited value if verified change is still scarce.
This changes how AppSec programs should be designed. Let us map this to the steps from theory of constraints
First, identify the constraint. The constraint is the organization’s ability to verify that a change is safe, correct, and deployable. This includes
- unit tests,
- review capacity,
- staging confidence,
- rollback ability,
- runtime observability,
- and ownership clarity.
Second, exploit the constraint. Verification capacity should be protected from low-quality inputs. Findings should include reproduction steps where possible. AI-generated patches should include tests. Changes should be small enough to review. Ownership should be clear before the issue reaches review.
The verification function should not be forced to process vague findings, oversized diffs, unowned services, or unclear business behavior.
Third, subordinate other activity to the constraint. Scanner volume, AI-generated findings, patch generation, backlog creation, and reporting should be shaped around what can be verified.
Producing more unverified work does not improve security throughput. It increases work-in-progress and hides the real bottleneck.
Fourth, elevate the constraint. Increase verification capacity through meaningful tests, security regression suites, better CI, safer staging, reproducible environments, clearer service ownership, smaller changes, better rollback, and skilled reviewers who can use AI effectively.
Automation helps when it improves verification quality or reduces verification effort.
Fifth, repeat the process. Once verification improves, the next constraint may move to ownership, deployment safety, architecture, product decision-making, or operational monitoring. The system has to be reviewed repeatedly because constraints move as capability improves.
This does not mean every verification activity must move to the start. It means verification requirements should be visible early. Teams should avoid creating work that cannot be safely reviewed, tested, deployed, or operated.
Every component in the stack creates verification demand. This includes first-party code, third-party libraries, SaaS products, plugins, CI/CD integrations, identity providers, cloud services, APIs, agents, monitoring tools, and internal automation. Each item may require configuration review, access review, test coverage, update tracking, incident response planning, and operational ownership. This makes stack reduction a security control.
A smaller stack is easier to understand, test, patch, monitor, and recover.
Organizations should ask direct questions before adding or retaining components:
- What business function does this component support?
- Who owns it operationally?
- What data and privileges does it receive?
- How will it be tested and updated?
- How will failure or compromise be detected?
- How will it be removed if the need disappears?
- Does it replace existing complexity or add another layer?
The same logic applies to product features. Unused features, broad integrations, optional modules, and default-enabled capabilities increase the amount of behavior that must be understood and defended. Reducing the stack to what is needed is more sustainable than accumulating capability and prioritizing risk later.
Prioritization has a narrower role
CVSS, KEV, EPSS, SSVC, exploit intelligence, asset context, exposure context, and business criticality remain useful. They help teams sequence work and allocate limited attention. They also help create defensible decisions when everything cannot be fixed at once.
Prioritization manages the queue. It does not reduce the number of vulnerable components by itself. It does not remove unnecessary exposure. It does not simplify architecture. It does not make a codebase easier to change. It does not increase test coverage. It does not create rollback capability. It does not improve ownership.
Reachability analysis should also be treated with caution. It is useful as an engineering signal, but it should not become a permanent justification for carrying unnecessary code. If a vulnerable dependency or function is declared unreachable, the next question should be whether it is needed at all. In many cases, “not reachable” should lead to removal, isolation, or scope reduction rather than long-term acceptance. Current reachability analysis is also limited by dynamic behavior, framework magic, feature flags, generated code, deployment differences, and incomplete test coverage. A safer posture is to use reachability to decide the next action, not to end the conversation. If the path is reachable, fix or mitigate it. If it is unreachable and unnecessary, remove it. If it is unreachable but still needed, document what keeps it unreachable and what could invalidate that assumption.
A team can have a mature prioritization process and still carry many known weaknesses. In an environment where attacker iteration is cheaper, long-lived known weaknesses become more expensive to carry.
Vulnerability management must measure more than ranking quality. It must measure remediation throughput. It must also measure the confidence with which changes can be shipped.
Prioritization should remain an input to the remediation system. It should not become the mechanism that normalizes indefinite delay.
CVE enrichment cannot be the only trigger
The CVE ecosystem remains essential. Identifiers, advisories, references, vendor patches, exploitation signals, and public databases are important parts of coordinated vulnerability management. Mature programs should continue using them.
The operational risk is over-dependence on clean CVE lifecycle sequencing. Defenders often prefer a neat order: disclosure, CVE assignment, advisory, enrichment, exploitation signal, prioritization, remediation. Real incidents do not always follow that order.
Public proof-of-concept material, exploit discussion, mitigation guidance, vendor patches, and CVE assignment may arrive in a different sequence. In some cases, exploitation signals may appear before internal impact analysis is complete.
This matters more when AI reduces the cost of analysis and variant generation. Enriched CVE data may arrive after useful attacker material already exists or may never arrive at all.
The security program therefore needs additional triggers for action. These include exposure, affected component presence, exploit class, local access assumptions, privilege boundaries, workload isolation, compensating control quality, and the ability to deploy a safe mitigation quickly.
The lesson for AppSec and vulnerability management teams is direct. Treat CVE enrichment as important input. Also maintain the ability to act before every external signal is complete.
Inventory, exposure mapping, dependency visibility, and service ownership become decisive. They allow teams to answer whether they are affected while external information is still incomplete.
Remediation throughput becomes the primary metric
The central defensive question should become: how quickly can the organization safely remove weaknesses?
That requires more than scanner output. A team needs a way to reproduce issues, generate fixes, test expected behavior, review security impact, deploy safely, observe production behavior, and recover if the change causes unintended effects.
AI can help in that loop. The confidence still comes from the surrounding engineering system.
A useful remediation loop looks like this:
- Identify the weakness and affected paths.
- Reproduce the behavior where possible.
- Generate or draft a fix.
- Add a regression test or behavioral test.
- Run relevant unit, integration, security, and deployment tests.
- Review the change with a human who understands the security and business context.
- Deploy with rollback and monitoring.
- Feed the lesson back into tests, patterns, and architecture.
AI can assist each step. It can explain code paths, generate candidate tests, draft patches, compare implementation options, summarize diffs for review, and search for similar patterns.
The organization still needs deterministic verification, ownership, and review discipline. Without that machinery, AI-generated fixes can become another source of unverified change.
The key measure is safe remediation throughput. Security programs should know how much verified change they can produce per week. They should also know where the bottlenecks are and which parts of the stack cannot be changed safely.
Verification improves adoption of security fixes
A purely ideal security model would assume that important fixes are accepted quickly because they reduce risk. Real organizations do not work that way.
Security is an enabling function. The primary purpose of most systems is to deliver business functionality, support users, process transactions, enable operations, or provide a product capability.
When a security fix threatens functionality, release timelines, revenue paths, customer experience, or operational stability, security work can lose priority. This is not always negligence. It is often a rational response to uncertainty. Teams resist changes when they cannot predict what will break.
This is why verification is central to adoption. A security team that can prove exploitability may create urgency. A security team that can prove safe remediation creates a better decision path.
The fix should have a regression test. It should preserve the critical workflow. It should pass integration checks. It should have a rollback path. This evidence makes the fix easier for engineering and product teams to accept.
The goal is to reduce the perceived and actual cost of accepting security fixes. Meaningful tests, small patches, clear blast-radius analysis, staged rollout, rollback paths, and runtime observation all help.
Security teams should communicate confidence along with risk. A fix request should explain what was tested, what behavior remains unchanged, what monitoring exists, and what rollback path is available. Higher confidence increases adoption.
Bug-class elimination should be preferred over instance-by-instance fixing
Instance-level remediation is necessary but it should not be the only goal. When the same kind of vulnerability appears repeatedly, the better target is to remove the source of that bug class.
A single SQL injection fix closes one issue. A safe query abstraction, enforced ORM pattern, or CI rule can reduce the chance of that class returning.
A single XSS fix may patch one output path. A consistent templating model, output encoding strategy, CSP policy, and regression tests can reduce the class across the application.
One authorization bug can be fixed locally. A centralized authorization decision layer, consistent policy model, and role-context test suite can reduce repeated access-control failures.
This is a better use of limited verification capacity. Every repeated instance consumes discovery, triage, review, testing, deployment, and monitoring effort. If the root pattern remains, the team keeps paying the same cost.
Bug-class elimination reduces future workload. It also improves remediation throughput.
AI can help here, but it needs direction. It can search for similar code patterns. It can propose framework-level changes. It can generate regression tests. It can write static analysis rules. It can identify places where the same flawed assumption appears.
The human role is to decide why the repeated issue exists. The cause may be a missing abstraction, unsafe default, weak framework pattern, unclear ownership, poor developer guidance, or an architectural decision that needs correction.
Security programs should track whether a vulnerability was fixed as an isolated instance or whether the underlying bug class was reduced. The second outcome is usually more valuable because it changes the future cost model.
Compensating controls need expiry and replacement plans
Monitoring, detection, WAF rules, virtual patching, rate limits, traffic filtering, egress controls, anomaly detection, and EDR alerts are useful controls. They reduce immediate exposure. They buy remediation time. They help observe attacker behavior. They are often necessary during active risk windows.
Their role should be explicit. They are point-in-time controls for risk reduction while the safer long-term state is prepared. Each compensating control should have an owner, a reason, a review date, and a replacement plan.
The target state should be a structural fix wherever feasible.
Long-term dependency on temporary controls creates operational risk. A WAF rule can miss variants. A detection rule can fail to fire. A rate limit can be tuned around. An alert can be ignored. A virtual patch can create a false sense of completion while the vulnerable code remains present.
These compensating controls are valuable when they shorten the time to remediation. They become dangerous when they replace remediation without an explicit decision.
This should be part of vulnerability governance. If a weakness is mitigated through monitoring or filtering, the record should show the intended long-term path. The team may intend to remove the vulnerable path, fix the code, isolate the component, retire the feature, or accept the residual risk. “Mitigated” should not automatically mean “done.”
Attack surface reduction is the practical control layer
Attack surface reduction becomes more important as attacker iteration becomes cheaper and verification capacity becomes scarce.
Reducing exposed functionality reduces the number of paths that can be explored. Reducing dependency count reduces the number of components that must be tracked and tested. Reducing privilege reduces blast radius. Reducing data access reduces impact. Reducing integration complexity makes the system easier to verify.
The principle is simple: build less, expose less, and trust less.
In application security, this means removing unused endpoints, deleting unused features, reducing dependency trees, narrowing API exposure, restricting administrative paths, lowering default privileges, limiting egress, reducing data retention, and retiring systems that no longer have clear ownership.
This is where the “fix everything” posture needs precision. The objective is to fix every weakness that can be safely fixed. For weaknesses that cannot be safely fixed immediately, reduce exposure while building the ability to fix them.
That may mean disabling a feature, moving a path behind stronger access control, isolating a service, removing an integration, adding a temporary compensating control, or retiring the component entirely.
Attack surface reduction also reduces future workload. A removed dependency no longer needs vulnerability monitoring. A removed endpoint no longer needs authorization testing. A retired feature no longer needs security review.
This is especially important for small and medium-sized businesses. They cannot sustain unlimited vulnerability management overhead.
Test coverage is a security capability
AI-assisted repair depends on verification. Test coverage therefore becomes a security capability when it captures meaningful behavior.
Line coverage is not enough. A codebase can have high line coverage and still miss authorization failures, tenant isolation problems, parser edge cases, unsafe deserialization, race conditions, payment workflow abuse, and business logic flaws.
Security-relevant tests need to encode expected behavior. They should not only execute lines.
Useful test coverage for this model includes:
- Unit tests for core logic.
- Integration tests for critical workflows.
- Authorization tests for role and context boundaries.
- Regression tests for past vulnerability classes.
- Property-based tests for invariants.
- Fuzzing for parsers and boundary-heavy components.
- Contract tests between services.
- Deployment checks for configuration drift.
- Observability checks for unexpected runtime behavior.
The value of these tests is operational. They allow AI-assisted fixes to be evaluated against expected behavior. They give reviewers a concrete signal. They reduce the fear of changing old code. They also expose where the system lacks executable knowledge.
A missing test around a critical workflow is a security gap. It limits safe remediation and reduces the likelihood that teams will accept security changes quickly.
This changes the human role. Security experts should spend less time arguing over every item in the queue. They should spend more time improving the verification system, identifying missing invariants, reviewing high-risk changes, and deciding where automated output is misleading.
Capacity includes operators, AI, and verification
Capacity is usually discussed as headcount. Headcount still matters, but it is no longer the full equation.
A more useful capacity model has six parts.
- Human judgment.
- AI-assisted execution.
- Deterministic verification.
- Deployment discipline.
- Rollback capability.
- Clear ownership.
A small team can produce safe change when the system is simple. It needs strong tests, clean ownership, good deployment hygiene, and operators who know how to steer AI. A larger team can still struggle if it has unclear ownership, weak tests, large exception registers, and too many systems nobody understands.
This is particularly relevant for SMBs. Most SMBs will not build a large AppSec function with separate teams for vulnerability analysis, threat intelligence, remediation governance, detection engineering, and secure architecture.
They need a smaller set of repeatable rules.
- Know what you expose.
- Reduce what you expose.
- Reduce what you own.
- Fix what you can verify.
- Add temporary controls with expiry dates.
- Outsource what you cannot safely operate.
- Own only the slices that you can maintain.
The operator role matters in this model. AI does not remove the need for skilled people. It increases the value of people who can frame the task, constrain the output, evaluate the change, and understand the system-level implications.
The scarce skill is steering the repair system toward safe outcomes.
SaaS and in-house ownership need explicit selection criteria
SaaS is useful when it reduces operational burden. A vendor may be better placed to manage infrastructure, patching, scaling, availability, compliance workflows, and security operations. For an SMB without the ability to operate a system safely, SaaS may reduce risk.
The selection criterion should be operational capacity. A team should use SaaS when it cannot patch, test, monitor, back up, recover, manage access, review changes, and respond to incidents for that function with reasonable confidence.
In-house ownership is also valid when the owned scope is narrow and maintainable. The “vendors sell suites, teams need slices” argument applies here. Many organizations use a small portion of a large product.
If AI reduces the cost of building narrow internal workflows, teams can sometimes own the slice they actually need. This can avoid adopting a full suite with unnecessary feature surface, data exposure, dependency, and cost.
This decision requires operational honesty. Cheap code generation does not automatically create long-term maintainability. An internal tool should be small enough to understand, test, patch, monitor, and recover.
A SaaS product should reduce real operational burden. It should not simply move complexity into a vendor contract.
The practical rule is straightforward. Use SaaS when operating the system is the larger risk. Own a narrow slice when dependency, unnecessary scope, data exposure, vendor lock-in, or cost is the larger risk and the team can operate the slice safely.
Organizations should also avoid buying or enabling broad platforms without clear need. A suite with many unused capabilities still creates integration, configuration, access, monitoring, and incident response burden.
Each unused capability becomes part of the security stack without necessarily becoming part of the business value.
What AppSec should optimize for
The defensive AppSec response to AI should optimize for remediation throughput with confidence. It should also optimize for stack reduction with discipline.
Useful questions include:
- How quickly can a finding be converted into a reproducible case?
- How quickly can the team create a safe patch candidate?
- How much of the relevant behavior is covered by meaningful tests?
- How quickly can a human reviewer evaluate the security-relevant change?
- How safely can the change be deployed and rolled back?
- How clearly can the team demonstrate that critical functionality remains intact?
- Which bug classes can be removed structurally instead of fixing individual instances repeatedly?
- Which exposed paths can be deleted or narrowed?
- Which dependencies can be removed?
- Which components are too risky because nobody can safely change them?
- Which temporary controls are overdue for replacement with structural fixes?
- Which SaaS dependencies reduce operational risk, and which ones add unnecessary scope?
- Which internal slices can be maintained safely by the team?
- Which parts of the stack exist because they were easy to buy or enable, rather than because they are needed?
- Which components consume more verification capacity than the value they provide?
These questions move the program from queue management toward system improvement. Vulnerability prioritization still has a place. The main improvement comes from reducing exposure, reducing stack size, and increasing the organization’s ability to safely change software.
A practical operating model
A practical operating model can be organized around eight activities.
First, maintain current inventory. Know applications, services, dependencies, APIs, exposed routes, authentication boundaries, privileged workflows, build systems, deployment paths, third-party integrations, and data flows.
Second, reduce the stack to what is needed. Remove products, plugins, modules, integrations, agents, features, and internal tools that do not have a clear business function and operational owner.
Third, reduce attack surface continuously. Remove unused endpoints, features, dependencies, privileges, abandoned services, dead integrations, old environments, and standing access that is no longer required.
Fourth, improve verification. Add tests around security-sensitive workflows, authorization decisions, tenant boundaries, parser behavior, data transformations, and deployment configuration. Convert past incidents and vulnerabilities into regression tests.
Fifth, eliminate recurring bug classes. When the same weakness pattern appears repeatedly, fix the source pattern. Use safer abstractions, framework defaults, static analysis rules, reusable libraries, developer guidance, and regression suites.
Sixth, use AI to accelerate controlled repair. Use AI to explain code paths, generate reproduction cases, draft patches, create regression tests, compare dependency changes, identify similar patterns, and summarize reviewer-relevant risk. Keep the final decision with people who understand the system.
Seventh, deploy with discipline. Use branches, review, CI, staged rollout where appropriate, monitoring, post-deployment checks, and rollback paths. Deployment safety is part of security because it determines how quickly fixes can be shipped.
Eighth, review temporary controls. Every compensating control should be checked for owner, purpose, review date, and replacement path. A control that remains necessary for a long period should trigger an architecture or ownership discussion.
This model is operational. It uses AI to reduce neglected work and increase safe change capacity. It also keeps the outcome tied to deterministic systems rather than relying on model output alone.
Leadership implications
Leadership should treat long vulnerability queues as an operational capacity problem. A better prioritization dashboard may help. It will not solve the underlying issue if teams cannot safely change software.
Funding should focus on systems that increase safe remediation throughput and reduce unnecessary stack burden. This includes inventory, attack surface reduction, engineering time to remove old code and unused systems, meaningful tests, security regression tests, developer workflow improvements, patch automation, deployment safety, rollback capability, identity and privilege reduction, and monitoring on high-value paths.
Leadership should also fund the judgment layer. AI-assisted remediation depends on people who can steer the tools, constrain the output, verify the change, and reject unsafe suggestions. Experienced engineers and security practitioners become more important when the organization tries to increase the volume of changes safely.
This investment also improves adoption. Product and engineering teams are more likely to accept security changes when the security function can demonstrate minimal functional risk. Test evidence, staged rollout plans, and rollback options reduce friction.
A useful leadership metric is safe change capacity per week. A second useful metric is verification burden created or removed. These are more actionable than asking only how many findings exist or how many are marked critical.
The important question is how much verified remediation the organization can produce without adding more unmanaged complexity.
Closing
Application security has spent years improving vulnerability prioritization because the number of findings exceeded available remediation capacity. That history explains the current model. The next model needs a different center.
AI changes the cost of exploration and iteration. Attackers can analyze code, generate variants, study diffs, and test hypotheses faster.
Defenders should respond by reducing the amount of software that must be defended. They should increase verification capacity, use AI to accelerate controlled repair, and make explicit choices about what to own and what to outsource.
The strongest defensive posture is a smaller and better-understood stack. It needs faster verified remediation, temporary controls with clear replacement plans, and human operators who can direct AI-assisted repair without surrendering judgment.
<self-promotion>
At Cyfinoid Research we extensively focus on Software Supply Chain risks, All of our research work is available either in the form of open source tools or trainings.
Below is the list of trainings we are right now offering
</self-promotion>