Last month, an AI system identified twelve zero-day vulnerabilities in OpenSSL—ten assigned CVE-2025 identifiers and two CVE-2026 identifiers. Five of those findings came with AI-proposed patches that made it into the official release. One vulnerability, CVE-2025-15467, scored 9.8 out of 10 on the CVSS v3 scale.
This isn't a proof-of-concept or research experiment. It's production security work, and it's raising questions from security teams trying to figure out what this means for their programs. Here are the questions we're hearing most often.
Should You Use AI Tools to Scan Dependencies?
The OpenSSL discoveries show that AI can find real vulnerabilities in production code that traditional static analysis missed. However, the AI didn't replace the entire security workflow. It found candidates, proposed fixes, and those fixes still went through human review before reaching the official release.
Start by adding AI-assisted scanning to your existing dependency analysis—don't replace your current tools. If you're already running software composition analysis (SCA) for PCI DSS v4.0.1 Requirement 6.3.2 (managing vulnerabilities in bespoke and custom software), layer AI scanning on top of it. Treat AI findings as additional signals, not ground truth. You'll still need to validate, prioritize based on exploitability in your environment, and test patches before deployment.
The practical move: pilot an AI vulnerability scanner on a non-critical codebase first. Measure false positive rates against your existing tools. If it finds issues your current stack missed, expand the scope.
Does AI Make Vulnerability Management Easier?
In the short term, adding more findings to your backlog can make things worse. However, in the medium term, AI can improve your process if used strategically.
The twelve OpenSSL vulnerabilities weren't found because AI magically sees what humans can't. They were found because AI can exhaustively test edge cases and input combinations at scale. Your team can't manually test millions of code paths. AI can.
The risk: you'll get more findings without more context. A 9.8 CVSS score like CVE-2025-15467 demands immediate attention, but not every AI-discovered vulnerability will be that clear-cut. You need triage criteria before you deploy AI scanning, or you'll drown in unactionable alerts.
Build a decision framework first:
- Does the vulnerability affect code paths exposed to untrusted input?
- Can you reproduce the issue in your specific configuration?
- What's the exploitability timeline—is this theoretical or actively exploited?
- Does remediation require dependency updates that could break other systems?
If you're working toward SOC 2 Type II compliance, document this triage process. Your auditors will want to see how you determine risk severity and response timelines, especially for AI-discovered findings that may not have established threat intelligence yet.
Should You Auto-Apply AI-Proposed Patches?
No. The five accepted patches for OpenSSL went through maintainer review. You should do the same.
AI-proposed patches solve a specific problem: they can suggest syntactically correct code that addresses the vulnerability. What they can't guarantee is that the fix doesn't introduce new issues, break backward compatibility, or conflict with your specific implementation.
Here's a workable approach: use AI-proposed patches as a starting point for your remediation work, not the end point. If your security team is struggling to write fixes for complex vulnerabilities, an AI-generated patch gives you a reference implementation. Your developers still need to review it, test it against your integration test suite, and validate it doesn't break functionality.
For PCI DSS v4.0.1 Requirement 6.3.3 compliance (reviewing custom code prior to release), AI-proposed patches count as custom code. They go through the same review process as any other code change: peer review, security testing, and validation against security requirements.
Explaining AI-Discovered Vulnerabilities to Auditors
Lead with the control, not the tool. Your auditors care about whether you have a process for identifying and remediating vulnerabilities, not whether you use AI to do it.
When you document AI-discovered findings:
- Treat them like any other vulnerability source (security researcher disclosure, internal testing, vendor advisory)
- Show the same risk assessment and remediation workflow
- Include evidence that findings were validated—don't just cite "AI found this"
- Document why you chose to remediate or accept the risk
For ISO 27001 Annex A 8.8 (management of technical vulnerabilities), you'll need to show that AI tools are part of your technical vulnerability identification process. That means documenting which tools you use, how often they run, and how findings feed into your vulnerability management system.
The OpenSSL case helps here. You can point to a real-world example where AI discovered critical vulnerabilities (including one rated 9.8 CVSS) that traditional methods missed. That's evidence that your expanded detection approach has measurable value.
Handling AI-Discovered Zero-Days in Your Code
Follow your existing vulnerability disclosure policy. AI doesn't change your disclosure obligations—it just accelerates discovery.
If the AI finding affects your product and could impact customers, you're in coordinated disclosure territory. That means:
- Validate the vulnerability is real and exploitable
- Assess impact and develop a patch
- Notify affected customers according to your SLA
- Coordinate with CERT or similar organizations if it's a widespread issue
- Request a CVE identifier if appropriate
The timeline compression is real. Traditional security research might give you weeks or months before public disclosure. AI-discovered vulnerabilities could become public much faster, especially if multiple organizations are running similar AI scans. Build your incident response plan with this in mind.
Should You Worry About Offensive AI?
Yes, but not because of OpenSSL. The same AI capabilities that found twelve zero-days defensively can be used offensively. The difference is speed and scale.
Your defense: assume adversaries have the same AI capabilities you do, possibly better. That means:
- Reduce your attack surface faster than before—every exposed service is a potential AI target
- Prioritize patching for internet-facing systems
- Implement defense in depth so a single vulnerability doesn't mean full compromise
- Monitor for exploitation patterns, not just known CVEs
For NIST Cybersecurity Framework compliance, this fits under the Detect function. You need logging and monitoring that can identify exploitation attempts even when you don't have a specific CVE to watch for.
Skills Needed to Work with AI Security Tools
Your security engineers don't need to become AI researchers. They need to:
- Understand how to interpret AI confidence scores and findings
- Validate vulnerabilities through manual testing and code review
- Assess whether AI-proposed fixes actually solve the problem
- Recognize when AI is pattern-matching versus finding genuine logic flaws
The bigger skill gap is organizational: you need processes for handling the increased volume and velocity of findings. If your team is already struggling with vulnerability backlog, adding AI tools without adding triage capacity will make things worse.
Where to Go from Here
Start with your dependency management program. If you're scanning open-source dependencies for known CVEs, add AI-assisted scanning for unknown vulnerabilities. Measure the signal-to-noise ratio for three months before expanding.
Document your AI tool usage in your security program documentation. Your next audit will include questions about AI in your security stack—get ahead of it by showing you've thought through validation, testing, and integration with existing controls.
The OpenSSL case proves AI can find critical vulnerabilities and contribute to fixes. What it doesn't prove is that AI can replace your security team's judgment. Use it to extend your reach, not to automate decisions that still require human context.
