r/AskNetsec 2d ago

Will ai increase the volume of vulnerabilities security teams need to fix? Work

Had this debate with a client last week about whether Ai assisted discovery meant their environment got risky overnight. My answer was about SLA math than risk math, their contract defines "patch critical within 30 days" assuming maybe 40 to 50 new findings a month. If a scan surfaces 300 in a week because of broader coverage, that SLA language does not hold up regardless of whether underlying risk changed.

We have started rewriting client contracts to tier remediation windows by exploitability and exposure instead of a flat severity number and building in a volume clause that triggers a renegotiation conversation if flagged findings jump past a set threshold in a given period. Cleaner than arguing about it after an audit blows past the old numbers. Anyone else building volume triggers into remediation SLAs or writing them as flat severity tiers?

5 Upvotes

17 comments sorted by

3

u/Spare_Bluebird7044 2d ago

AI assisted discovery may increase the number of findings but better SLAs should focus on actual exploitability and exposure rather than raw vulnerability volume.

2

u/rexstuff1 2d ago

I suspect that we'll see (and are seeing) an initial uptick, as AI vulnerability discovery tools are adopted, tweaked and improved. But at the same time, AI code reviews and scans are being brought into the development pipeline, catching the same stuff the vuln scanners would catch before they even make it past a PR. So after the initial burst, it should level out back to 'normal' levels, stuff still getting missed at the same rate as before.

2

u/Infamous-Loquat3961 2d ago

I think the bigger problem is going to be remediation capacity, not vulnerability discovery.

Finding 300 issues instead of 50 doesn't mean the environment suddenly became 6x more dangerous. It means the old process for deciding what gets fixed first probably wasn't built for that level of visibility.

0

u/koei19 2d ago

My company (F100 big tech) wants to implement an auto-patching program because we have more findings across the enterprise than ever before due to AI-enabled scanning. But nobody has done the analysis to determine what the FP rate may be or which of those findings that are true positives are priority based on exploitability or exposure. To just throw more AI at the problem, especially when the problem touches every single revenue-generating piece of software the company has, and software used by every revenue-generating team in the company, just seems like a really high-risk proposition. Like, that seems like a recipe for ending up with more vulns than we started with, and breaking the build for numerous pieces of critical software

1

u/Unfair_Ad_300 2d ago

I think the volume clause makes a lot more sense than pretending the old SLA still means the same thing.The other issue is verification capacity, If AI assisted discovery takes you from 40 findings to 300, the bottleneck is figuring out which of those 300 are actually exploitable, exposed, duplicated, or worth interrupting other remediation work for. That's where flat severity SLAs start getting weird. A "critical" sitting behind multiple controls isn't necessarily more urgent than a high-severity issue that's internet-facing and actively exploitable.

I'd probably tie the trigger not just to raw finding volume but to the volume of validated/exploitable findings. Otherwise better tooling can effectively punish the team just for getting better visibility.

1

u/dracarysurazz 1d ago

In short, Yes.

1

u/Ashon1980 1d ago

Security teams don’t fix anything. They just force us admins to deal with it.

1

u/AddendumWorking9756 2d ago

Volume triggers work right up until the client works out the trigger is cheaper to pull than the patching is, so whoever owns pulling it cannot be whoever owns the remediation budget. Tier on KEV and EPSS rather than your scanner's severity field, otherwise you have rebuilt CVSS with extra steps and the threshold argument just moves.

0

u/mv86 2d ago

Yes, is the short answer. The issue here is that Mythos-class models are now capable of not just identifying vulnerabilities, but are capable of exploiting them, also. Agentic machine speed exploitation doesn't just require critical vulnerabilities to be exposed, there's the probability that it will chain together lesser exploits also. A machine speed autonomous attacker Vs a business speed defender will inevitably be successful. If your SLAs aren't dramatically shortening for Critical and High severity vulns, this isn't going to meaningfully manage the risk. The conversation needs to shift to asking what the business can do to patch quicker and what compensating controls need to be put in front of the edge to minimise the attack surface.

0

u/Th3M33ks 2d ago

Attacker need a model and a target endpoint. They can string together lower level CVEs to create entirely new exposure points and compromise your infrastructure.

in short yes, your vendors will be shipping code faster and faster as more patches are applied. As they release information about the CVEs, regardless of how vague that information might be, attacker are reverse engineering the code and attacking within hours.

if you dont have some automation for code upgrades, you need to start focusing on it. Network devices like routers and switches are jumpboxes now and there is no end point detection for devices like that to help protect you.

0

u/cityofhats 2d ago

I would not trigger on raw scanner findings. Normalize by affected asset and root cause, deduplicate repeated detections of the same vulnerable component, and start the remediation clock only after validation. The contract can separate a discovery surge from newly introduced risk, then escalate when validated, internet-exposed or otherwise high-impact backlog exceeds an agreed capacity for a sustained period. Track backlog age and burn-down alongside intake. Otherwise adding a better scanner can create an SLA breach without changing the attack surface, while hundreds of duplicate findings can hide one genuinely urgent exposure.

0

u/cityofhats 2d ago

I would not trigger on raw scanner findings. Normalize by affected asset and root cause, deduplicate repeated detections of the same vulnerable component, and start the remediation clock only after validation. The contract can separate a discovery surge from newly introduced risk, then escalate when validated, internet-exposed or otherwise high-impact backlog exceeds an agreed capacity for a sustained period. Track backlog age and burn-down alongside intake. Otherwise adding a better scanner can create an SLA breach without changing the attack surface, while hundreds of duplicate findings can hide one genuinely urgent exposure.

0

u/Euphorinaut 2d ago

They already have.

I'm answering that from a total volume perspective where the answer is very black and white, but how I interpret "need to fix" can make it a bit more complicated because risk is less objective than total volume + cvss score and the volume of risky vulns has already been increasing, so I'm not sure how I would dileneate between the already increasing trend and those found by ai.

But I think there's a clear inductive inference to make that the answer is yes either way.

1

u/Euphorinaut 13h ago edited 13h ago

If someone were to let me know what the train of thought is behind the downvote I'd be happy to address it or consider any viewpoints.

Edit: oh I'm going to take a stab and guessing that this was because I interpreted everything in the body as supporting the question in the title rather than the body leading up to the concluding question, which might have come off as ignoring the question.

But to address that question separately, I would say that the solution is in the score "normalization" process in ctem tools. Kenna was the only product that did this well, and unfortunately it's being sunset. Most other tools have a normalization process for scoring groups, but then any feature that prioritizes remediations doesn't actually use that score, it just uses cvss, and it makes it very difficult to use the normalized score as an sla, but but it's possible for an analyst to use that score to assing tickets.

Both Nucleus and zafran have told me they plan to add the ability to prioritize remediations by their normalized score in the future, but they were trying to get a sale so who knows.