Vulnerability Is Not a Bug: It’s a State of Being

Additional resources

From Container Security to AI Supply Chains: Applying Shift-Left Principles to ML Pipelines

Container security concepts can be applied to ML DevSecOps pipelines to identify AI supply chain risk considerations.

Step into the New Era of Endpoint Vulnerability Management

Traditional vulnerability scanners run on schedules. Attackers don’t. As CVE volume accelerates, exploitation can begin within hours of disclosure—yet most organizations still rely on periodic scans and manual workflows, creating a dangerous gap between discovery and remediation.

The Case for AI-Powered Vulnerability Management

Recent advancements in artificial intelligence (AI) and machine learning (ML) have paved the way for the transformation of vulnerability management.

ISACA IT Risk Resources

ISACA’s expert guidance gives professionals and enterprises the tools, techniques and understanding to manage IT Risk.

When I opened my talk at the University of Texas at Dallas IIA/ISACA’s chapter this February, I didn’t start with a CVE. I started with a question: what does vulnerability actually mean to you?

In security, we’ve been conditioned to answer that with a Common Vulnerability Scoring System (CVSS) score — and that instinct, while understandable, is where the gap begins.

Vulnerability is not a discrete bug waiting to be fixed. It’s a state — one that every organization exists in, continuously, at varying levels of exposure. The moment we treat it as a checklist item to close rather than a condition to actively manage, we’ve already lost the plot.

That question sat with me long after I left the stage — and it’s what I explore in depth in my article published in Volume 3 of the ISACA Journal (May 2026), From Container Security to AI Supply Chains: Applying Shift-Left Principles to ML Pipelines. The article makes the case that the security disciplines we’ve been slow to apply to containers — risk-based prioritization, asset context, policy-driven governance — are the exact same ones we need to build now for AI and ML pipelines, before the problem compounds. The surface changes; the failure mode doesn’t.

From Patchwork to Policy

This was the central argument of my talk, and it’s the thread running through my Journal article: the difference between a patchwork program and a policy-driven one.

Patchwork programs react. They scan, generate lists, assign tickets and measure closure rates. They speak in CVEs. Leadership hears noise.

Policy-driven programs operate from a risk framework. They classify assets, define remediation SLAs by exposure tier, run campaigns tied to business objectives and translate security posture into language that resonates at the board level: risk and business impact.

The shift isn’t primarily technical. It’s organizational. It requires vulnerability management to stop living in a silo and start integrating with GRC, compliance and asset management as a unified risk function.

Here are three things that move programs in that direction:

1. Stop reporting CVE counts. Start reporting exposure.
   How many of your critical, internet-facing assets carry actively exploited vulnerabilities with no compensating control? That number tells a real story. Raw CVE totals do not.

2. Build asset context before the next incident.
   Internet-facing? Customer data? Regulated workload? This classification needs to exist in advance, not assembled under pressure after a disclosure. Risk-based prioritization only works if your asset inventory is current and contextualized.

3. Let compliance frameworks do some of the heavy lifting.
   NIST 800-53, FedRAMP, SOC 2 — when positioned correctly, these aren’t separate tracks from vulnerability management; they create accountability structures that security teams alone can’t enforce. Audit and security speaking the same language is a genuine force multiplier. That alignment is what turns a reactive patching culture into a governed risk program.

Why Does this Extend to AI Pipelines?

The reason I extended this thinking into AI supply chain security in my Journal article is straightforward: the same failure mode is already in motion. Organizations are pulling pretrained models from public repositories, training on uncontrolled data and deploying AI components with no inventory and no behavioral baseline.

No context. No classification. No policy.

That’s the patchwork pattern, repeating at the AI layer. So, here’s a practical place to start: ask your team one question this week: do you know every pretrained model your organization has used in the last 90 days? Where did it come from, who approved it, and whether it’s version-pinned or pulled fresh at runtime? If that answer isn’t readily available, you don’t have an AI security problem yet. You have an inventory problem. And inventory is always where governance begins.

Practitioners who build that inventory now — before the incident that forces the conversation — will be the ones defining what good looks like in this space.

Vulnerability is a state. Managing it well, at every layer of your stack, is the job.

About the author: Sapna Paul, CISA, is a cloud security, compliance, and risk management professional with more than 12 years of federal and international compliance experience. Recognized for pioneering AI-powered automation in federal compliance and vulnerability management, she specializes in FedRAMP authorization, enterprise vulnerability management, quantitative risk assessment, and GRC framework implementation across multi-cloud environments. She currently serves as Senior Manager of Cybersecurity Risk at Dayforce, is a speaker at IIA and ISACA chapter events, a contributor to OWASP open-source projects including AIBOM and AI Exchange, and an industry advisor to the UT Dallas IAEP program. Her article “From Container Security to AI Supply Chains” published in ISACA Journal Volume 3, May 2026.