AI is saving us time. I'm spending mine on security.

AI has been great for feature work. We've largely handed implementation over to it, and we're moving faster. I'd enjoy the saved time more if I weren't spending half my day chasing security findings.

Between Wiz, Checkmarx and Snyk, there is always something to investigate or update. Getting through the findings means figuring out which systems are affected, what needs fixing first and how to get it done alongside the feature work.

The flaws were already sitting in the code, and finding them gives us a chance to fix them. What adds urgency is how much easier AI can make it to connect the dots. A few weaknesses that look less serious on their own can become a much bigger problem when someone works out how to use them together.

That is the fallout my team is already dealing with. We are moving faster on features while trying to absorb the security work. The calendar has been remarkably unhelpful about providing extra days.

We put money on the table before finishing our own homework

For us, the pressure picked up when the company started offering substantial bug bounties before we had completed our own full threat analysis. From where I sit, that sequencing was stupid. We gave people a financial reason to look harder before finishing the internal work to understand where we were exposed.

The reports coming in have the formatting and grammar I associate with AI-generated writing. That tells me something about how they may have been written, not how the bugs were found. If the vulnerability is real, it needs fixing either way. I don't get to close the ticket because the prose annoys me.

My frustration is the order of operations and the workload it creates. Paying for discovery also creates a responsibility to validate reports, handle duplicates, assign owners, test fixes and get them deployed. The bounty payment is only one part of the bill.

Even bounty providers tell companies to prepare for this. HackerOne's preparation guidance asks organizations to consider their ability to handle reports and remediation. External researchers can find things an internal team misses. We need the capacity to act on what they find.

The numbers are ugly enough without making shit up

Google Threat Intelligence Group reported 5,045 disclosed vulnerabilities in January 2026 and 10,740 in August. That is an increase of about 113% between two complete months. Its report also explains that public records do not consistently identify AI-assisted discoveries, so those totals cannot tell us AI's share.

The longer trend predates the latest AI tools. The CVE Program's published-record snapshots total 18,375 for 2020 and 48,244 for 2025. Comparing January through June in each year, published records rose from 23,710 in 2025 to 35,872 in 2026, an increase of about 51%. The CVE Program uses its own snapshot methodology, so these totals should be read separately from Google's figures.

Those are disclosure counts, not a scoreboard of successful attacks. Reporting and coverage affect the totals too, so pinning the whole increase on AI would be getting ahead of the evidence.

There is direct evidence of AI-assisted discovery, though. Mozilla reported in April 2026 that Firefox 150 included fixes for 271 vulnerabilities identified in an initial Claude Mythos Preview evaluation. That is a concrete example of AI helping find real flaws and a win for the people using Firefox. It also represents a pile of engineering work, not 271 attacks.

The combination can be worse than the individual bugs

Exploit chains existed long before AI. What's changing is how much of the work a model can help do. Anthropic reported in its May 2026 exploit research that Mythos Preview could turn vulnerabilities into capabilities useful to an attacker and combine those into complete attack chains in its testing. Those results apply to the model and systems tested. They do not mean every model can break into any application.

Imagine one weakness that exposes information and another that allows an action that should be restricted. The information from the first could supply what is needed to abuse the second. The practical impact depends on whether those steps actually work together in the deployed system.

That is another reason a list of isolated findings is not enough. We need to understand how components interact and what an attacker could do with several weaknesses together. It is also part of why we are changing how we review designs.

Some of these tickets come from code we didn't even write

A CVE record gives a disclosed vulnerability a public identifier. A new advisory can reveal that your application is affected even if nobody changed your code that morning.

Snyk's open-source scanning documentation, for example, describes building a dependency tree and checking it against known vulnerabilities. That includes transitive dependencies: packages brought in by packages you chose. Other scanner products and modes examine different layers, so their findings should not all be treated as identical CVE reports.

Say you install a file-upload library that pulls in a parser. An advisory later identifies a flaw in that parser. Updating your own application code does not necessarily remove it. You need to establish which version is installed, how it got there, whether your application is affected and which supported update removes it.

We've got a tiger team. We still need time to do the work.

Keeping up with findings is only part of the work. We've also formed a tiger team to start bringing STRIDE into our development process. It's a pretty disruptive change from how the team operated before, and we're still working through it.

Microsoft describes STRIDE as six categories for examining threats during design: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. It gives people a structured way to ask how a system could be abused.

For a hypothetical customer portal, that means asking concrete questions:

• Spoofing: Can someone impersonate another customer or a trusted service?
• Tampering: Can a request be changed to alter an order or someone else's data?
• Repudiation: Can we establish who performed a sensitive action if they deny it?
• Information disclosure: Can a response, log or export expose another customer's information?
• Denial of service: Can an expensive operation exhaust shared capacity?
• Elevation of privilege: Can an ordinary account perform an administrator's action?

Adopting this means making room for those discussions before implementation. Teams need to map data flows and trust boundaries, challenge assumptions and assign someone to follow through on the mitigations.

That takes time and changes development habits. Putting "threat modeling" on the calendar does not make the rest of the sprint politely get out of the way. Nor does STRIDE replace dependency updates. A design review can identify a missing authorization check; a package update can remove a known flaw in a library. We need both.

"Patch regularly" means getting the fix into the running system

A dashboard is very good at telling you something is red. It is less helpful at rearranging the release schedule. Here is the work I want teams to have actual time for:

1. Know what is running. Track direct and transitive packages, frameworks, runtimes and container base images. Include the deployed version, not just what is on a developer's laptop.
2. Triage with context. Validate affected versions and advisory conditions. Look at exposure, reachable functionality, business impact and evidence of exploitation. A severity score helps, but it is not the whole decision.
3. Keep a regular update rhythm and an urgent path. Routine maintenance should not wait for a crisis. An actively exploited issue may need action before the next scheduled patch window.
4. Review, test, deploy and verify. Inspect the update, run relevant checks, rebuild affected artifacts, deploy them, and confirm the running software has the fix. A merged lockfile change alone does not establish that production is patched.
5. Assign owners and review dates to exceptions. If an update cannot ship, record why, the exposure, any mitigation and the next decision. "Accepted risk" should mean someone actually accepted it.

GitHub's dependency guidance supports recurring scans, advisory monitoring, reviewed updates, lockfile maintenance and automated testing. The NCSC also recommends a rapid response pathway when vulnerabilities are being exploited. The cadence and urgency need to reflect the system and the threat.

Updates themselves deserve scrutiny. "Latest" is not a security guarantee. Automation can prepare a change and run checks, while people retain responsibility for what gets shipped.

Budget for the work after discovery

I want researchers to find vulnerabilities. I want AI to help us find them before attackers do. I also want the people making decisions about bounties, tooling and delivery dates to account for the engineering work that follows.

The part that pisses me off is creating more pressure to find problems while treating the work to understand and fix them like it will somehow fit between everything else. Put the work on the plan, give someone responsibility for it and make room to ship the fix safely. Otherwise, congratulations on the improved visibility. The team can now see exactly how far behind it is.