The Problem
Orca Security recently found that 99.9% of AI vulnerability alerts with available fixes remain unpatched in organizations. Eighty-one percent of companies using AI have at least one known vulnerability in their production environments. This isn't about complex attacks or zero-day exploits. It's about organizations deploying AI systems with known vulnerabilities and failing to apply available patches.
Ongoing Industry-Wide Issue
This isn't a single incident. It's a recurring issue across the industry. Organizations are:
- Deploying AI packages and models into production.
- Receiving vulnerability alerts for those systems.
- Seeing patches become available.
- Leaving those patches unapplied indefinitely.
The gap between "patch available" and "patch applied" is becoming a permanent state.
Missing Controls
Asset Inventory and Discovery: You can't patch what you don't know exists. Rapid AI deployment, often by data science teams outside traditional IT governance, creates shadow AI deployments. Your CMDB likely doesn't track which teams are running which models, on what infrastructure, with what dependencies.
Vulnerability Management Program: Standard vulnerability management assumes regular scanning of known assets. AI systems disrupt this model. A data scientist might deploy a model using untracked components that don't get scanned because they're not in your asset inventory.
Change Management: AI deployments often bypass change control. "It's just a model update" becomes the excuse for skipping standard approval workflows. Yet, these updates include dependencies, runtime environments, and API endpoints, all of which are potential attack surfaces.
Patch Management SLAs: Your policy likely defines patching timelines for critical vulnerabilities in operating systems and applications. Does it include ML frameworks or Python package dependencies? If not, these systems fall into a compliance gap with no clear patching responsibility.
Relevant Standards
ISO/IEC 27001:2022 Control 8.8 requires timely information on vulnerabilities and appropriate measures. For a known vulnerability with an available patch, this means applying it within your defined risk window. The standard applies equally to all components, whether a web server or a PyTorch dependency.
NIST Cybersecurity Framework v2.0 under the Identify function (ID.AM-2) requires maintaining an inventory of software platforms and applications, including AI systems. Under the Protect function (PR.IP-12), you need a vulnerability management plan covering the entire technology stack. If your plan doesn't include ML frameworks, you're not meeting the control objective.
PCI DSS v4.0.1 Requirement 6.3.3 mandates installing security patches within one month of release for systems in scope. If your AI system processes, stores, or transmits cardholder data, this requirement applies. "We didn't know it was in scope" isn't a valid defense during your QSA assessment.
SOC 2 Type II under Common Criteria CC7.1 requires identifying, reporting, and acting upon system security vulnerabilities in a timely manner. Your auditor will ask for evidence of your vulnerability scanning coverage and remediation timelines. If AI systems are excluded, you'll need to document the business justification and compensating controls.
Action Items for Your Team
Extend Your CMDB to Cover AI Deployments: Create a registration process for any team deploying ML models or AI systems. Include model/system name, owner, infrastructure location, framework and version, dependencies, data sources, and API endpoints. Make this part of your onboarding checklist for data science teams.
Scan AI-Specific Components: Your existing vulnerability scanner might not catch Python package vulnerabilities or outdated ML frameworks. Add tools that understand these ecosystems, like pip-audit for Python dependencies or safety for known security issues in packages.
Define Patching SLAs for AI Systems: Revise your vulnerability management policy to explicitly cover ML frameworks, model serving infrastructure, and AI package dependencies. Use the same severity-based timelines as other systems: critical within 15 days, high within 30 days, medium within 90 days.
Integrate AI Deployments into Change Management: Require that model deployments go through the same approval gates as application releases. The approval should verify that the deployment meets security baselines: current framework versions, scanned dependencies, documented data flows.
Create a Dependency Lockfile Requirement: Mandate that every AI project maintain a requirements.txt or equivalent that pins exact versions. When a vulnerability is announced, you need to know which projects are affected.
Assign Ownership: Designate a team responsible for AI security posture. This might be your existing appsec team with expanded scope or a new AI security function. The key is accountability for reducing that 99.9% unpatched rate.
The 99.9% statistic isn't about sophisticated adversaries. It's about basic security hygiene failures. You have alerts. You have patches. Close the gap.
