AI-Powered Supply Chain Attacks Are Here. CVSS Has No Answer. VRCM Does.

March 31, 2026. 11:47 PM.

Axios, the HTTP library sitting inside over 100 million npm projects every week, was quietly backdoored by a North Korean state actor. Two poisoned versions, [email protected] and [email protected], delivered a cross-platform Remote Access Trojan before the packages were pulled from the registry. Developer environments, CI/CD pipelines, and production systems had already ingested them.

Your scanner saw [email protected]. The CVE database had nothing. CVSS had nothing.

That's the supply chain problem in 2026. And the year before wasn't quieter.

In August 2025, the widely used Nx build system was compromised in the "S1ngularity" attack. Palo Alto's Unit 42 researchers confirmed the malicious bash scripts were AI-generated, LLM-crafted, functional, and deployed at scale. Weeks later, the "Shai-Hulud" campaign poisoned packages with a combined 2.67 billion weekly downloads, seeding over 25,000 malicious GitHub repositories through a single phishing compromise of one npm maintainer account.

Now add slopsquatting to the threat model. AI coding assistants hallucinate package names roughly 20% of the time. Attackers register those hallucinated names, things like plain-crypto-js or react-codeshift, before your developers hit npm install. The Axios attack itself used a pre-seeded typosquat called [email protected], poisoned and timed to coincide with the mainline compromise. Socket's automated scanner flagged it within six minutes. Most teams don't have Socket.

Every security team knows the feeling.

The scanner finishes its run. The dashboard lights up red. 847 findings. 23 Critical. 91 High. Your Slack channel explodes with escalations. Developers push back. Management wants a timeline.

And you're sitting there thinking: "Are all 23 of these actually critical in OUR environment? And what about the compromised dependencies that don't even have a CVE yet?"

The honest answer is almost always no. But the tooling doesn't help you say that with confidence.

I got tired of CVSS 9.8 triggering fire drills when the vulnerability was contextually not exploitable, buried behind authentication, a WAF, and network segmentation. I got tired of treating every "Critical" finding equally when context made half of them low priority. And I got tired of watching supply chain attacks slip through entirely because a poisoned transitive dependency had no CVSS score at all.

So I built the Vulnerability Risk Context Matrix (VRCM) - a synthesis framework that answers the question security teams actually need answered:

"What's the REAL risk in OUR environment?"

The result: 40% reduction in the noise I was reacting to.

🛠️ Want to try it on a real finding? I built an interactive VRCM Assessment Tool - no signup, runs entirely in your browser. Answer the 12 questions and get an instant risk score, section breakdown, and a copyable report for your ticketing system. Three pre-loaded examples from this article are included — the healthcare portal, internal inventory tool, and the Axios supply chain scenario. Keep reading for the full framework, then go run it.

---

🎯 The Problem with CVSS (And Why We Need Context)

CVSS is a phenomenal standard for measuring vulnerability severity in a vacuum. But vulnerabilities don't exist in a vacuum. They exist in your environment.

Consider these two scenarios:

Factor	Scenario A	Scenario B
Vulnerability	SQL Injection - CVSS 9.8	SQL Injection - CVSS 9.8
Internet-facing	✅ Yes	❌ No (internal only)
Authentication required	❌ None	✅ Admin + MFA
WAF	❌ None	✅ Yes, blocking SQLi patterns
Data exposed	Patient health records	Internal wiki content
Public exploit	✅ Metasploit module	❌ Theoretical
Compliance scope	HIPAA	None

Same CVSS score. Completely different risk profiles.

Scenario A is a genuine emergency. Scenario B is important but not deployment-blocking.

CVSS alone cannot distinguish between these. That's the gap VRCM fills.

⸻

🤖 AI Is the New Attack Factory

The 2025-2026 supply chain wave isn't just notable for its scale. It's notable for what's enabling it.

AI-generated malware. 🦠 The S1ngularity attack didn't just compromise the Nx build tool. The malicious payloads were written by an LLM. Unit 42 identified the tells: inline comments, emojis inside bash scripts, a consistent code style that no human writes under time pressure. LLMs generate functional, polished exploit code fast. Attackers with modest technical skills now have a force multiplier that used to require a senior developer.

AI-accelerated scale. ⚡ The Shai-Hulud campaign showed what happens when social engineering meets automation. One compromised maintainer account. 25,000 malicious repositories seeded in hours. 2.67 billion combined weekly downloads in the blast radius. That kind of operational scale is only achievable with AI-assisted tooling behind it.

Slopsquatting: the AI supply chain trap. 🪤 LLMs hallucinate package names roughly 20% of the time. Researchers tested 16 AI coding models across 756,000 generated code samples and found nearly 1 in 5 recommended a package that doesn't exist. Attackers catalogue those hallucinated names and pre-register them on npm and PyPI with malicious payloads before anyone notices. Factor in AI coding agents: when your CI/CD pipeline runs an agentic tool to scaffold or update dependencies, that agent can install a hallucinated package automatically with no human review at all.

Nation-state precision. 🎯 The March 2026 Axios compromise, attributed to Sapphire Sleet (a North Korean state actor), combined account hijacking, a pre-seeded typosquatted dependency, and a coordinated two-stage publish. It wasn't opportunistic. It was a planned operation against a package trusted by millions. AI-assisted reconnaissance and payload generation are lowering the bar for this level of sophistication.

The CVSS gap this creates: Most supply chain attacks arrive with no CVE and no CVSS score. A scanner looking at your dependency tree can confirm [email protected] is installed. But it can't tell you whether your build pipeline was exposed during the six-minute detection window. It can't tell you if the hallucinated package your AI assistant suggested last week is already sitting in node_modules. It can't tell you how many hops your transitive dependency chain is from the next poisoned package.

VRCM can't detect these attacks before they happen. But it can tell you exactly how exposed your environment is when they do, and where to focus your response.

⸻

🧠 The VRCM Framework: 12 Questions, 4 Dimensions, 1 Score

VRCM synthesizes the best parts of three established methodologies:

• OWASP Risk Rating Methodology - structured likelihood/impact assessment
• FAIR (Factor Analysis of Information Risk) - quantified financial risk
• CVSS 4.0 - standardized vulnerability severity metrics

Into 12 questions organized across 4 dimensions that anyone on the team can answer in minutes.

Section A: Exploitability (0–40 points)

Can an attacker actually use this?

#	Question	Points	What It Measures
1	Is it internet-facing?	15	Attack surface exposure
2	Can code be reached from user input?	12	Reachability
3	How hard is it to exploit?	8	Attack complexity
4	What access level is needed?	5	Privilege requirements

Why this matters: A CVSS 9.8 behind three layers of authentication and internal-only access scores a maximum of 20 in this section. That's the context injection CVSS is missing.

Section B: Business Impact (0–30 points, capped)

What happens if this gets exploited?

#	Question	Points	What It Measures
5	What data is at risk?	15	Data sensitivity (Public → Internal → PII → Health records)
6	What's the financial impact?	8	Dollar-value exposure ($10K → $1M → business-threatening)
7	Does this trigger compliance?	7	HIPAA? PCI? SOC2? GDPR?
8	Reputational damage potential?	7	Minor headline → brand destruction

Scoring note: Section B's individual question maxes sum to 37, but the section is capped at 30. Questions 6, 7, and 8 are strongly correlated - if data sensitivity is critical (Q5=15), financial impact, compliance, and reputation tend to cascade together. The cap prevents correlated dimensions from doubling the score.

Why this matters: A SQLi on a marketing blog and a SQLi on a patient records system have identical CVSS scores but wildly different business impact.

Section C: Threat Landscape (0–20 points)

Are people actually exploiting this?

#	Question	Points	What It Measures
9	Is there a public exploit?	10	Metasploit? PoC on GitHub?
10	What's the EPSS score?	6	Probability of exploitation in 30 days
11	Are threat actors targeting this?	4	Critical infra? Opportunistic? APT?

Why this matters: This is where EPSS shines. CVSS says "severe." EPSS says "will someone actually exploit this in the next 30 days?" A CVSS 7.5 with an EPSS of 0.90 deserves more urgency than a CVSS 9.8 with an EPSS of 0.02.

Section D: Controls Posture (0 to −10 points)

What protection already exists?

#	Question	Points	What It Measures
12	What compensating controls are in place?	−10	WAF? Segmentation? Encryption? Monitoring?

Why this matters: This section reduces the score. If you have a WAF blocking SQLi patterns, network segmentation, encryption at rest, and active monitoring, you subtract up to 10 points. This is the "what defenses do we already have" reality check.

⸻

📊 Scoring: From Numbers to Action

Score	Risk Level	Action
80–100	Critical	Block deployment. Fix NOW.
60–79	High	Fix this sprint.
40–59	Medium	Fix next sprint.
20–39	Low	Backlog.
0–19	Minimal	Awareness only.

The score isn't arbitrary. It maps directly to sprint planning and deployment gates. No more "everything is Critical so nothing gets fixed."

⸻

🔬 Walkthrough: CVSS 9.8 Meets Reality

Let's run a real finding through VRCM.

Finding: "Critical SQL Injection" - CVSS 9.8 on a public-facing healthcare portal.

VRCM Assessment

Exploitability (Section A):

• Internet-facing? Yes (+15)
• Direct user input to vulnerable code? Yes (+12)
• Easy to exploit? Yes, automated tooling (+8)
• Authentication required? No (+5)
• Subtotal: 40/40

Business Impact (Section B):

• Data at risk? Protected Health Information (PHI) (+15)
• Financial impact? HIPAA fines up to $1.9M per violation category per year (+8)
• Compliance triggered? HIPAA, HITECH (+7)
• Reputational damage? Patient trust destruction (+7)
• Subtotal: 30/30 (maximum - this is healthcare data)

Threat Landscape (Section C):

• Public exploit available? Yes, SQLmap + Metasploit (+10)
• EPSS score? 0.85 (+6)
• Threat actors targeting healthcare? Yes, constant targeting (+4)
• Subtotal: 20/20

Controls Posture (Section D):

• WAF blocking SQLi patterns? Yes (−3)
• Encryption at rest? Yes (−2)
• Network monitoring? Yes (−2)
• Database activity monitoring? No
• Subtotal: −7

VRCM Score: 83 (Critical)

This one actually IS Critical. Every dimension confirms it. Fix immediately.

But now let's run the same vulnerability type on a different system.

---

Same SQLi, Different Context:

Finding: "Critical SQL Injection" - CVSS 9.8 on an internal inventory management tool.

VRCM Assessment:

• Internet-facing? No (0)
• Direct user input? Yes (+12)
• Easy to exploit? Moderate, requires chaining (+4)
• Authentication required? Yes, admin + MFA (0)
• Data at risk? Internal inventory data (+5)
• Financial impact? Low, operational only (+2)
• Compliance triggered? None (0)
• Reputational damage? None (0)
• Public exploit? Generic SQLi, not specific (+5)
• EPSS? 0.12 (+3)
• Threat actors targeting? Unlikely (0)
• Controls? Segmented network, encrypted DB (−5)

VRCM Score: 26 (Low)

Same CVSS 9.8. VRCM score of 26. Backlog item, not a fire drill.

This is the power of contextual risk assessment. Both findings get appropriate attention - just at different speeds.

---

Now the scenario CVSS can't score at all.

Finding: Compromised transitive npm dependency ([email protected]) detected in production payment service via poisoned axios release. Active RAT payload, nation-state actor, no CVE assigned.

VRCM Assessment

Exploitability (Section A):

• Internet-facing service? Yes (+15)
• Malicious code reachable? Yes, executes on install/build (+12)
• Exploit complexity? None, payload auto-executes in pipeline (+8)
• Authentication required? No, runs in build environment (+5)
• Subtotal: 40/40

Business Impact (Section B):

• Data at risk? Payment data, developer credentials, SSH keys (+15)
• Financial impact? Active RAT exfiltration, PCI scope, breach-level exposure (+8)
• Compliance triggered? PCI-DSS, SOC2 (+7)
• Reputational damage? Customer payment data exposure (+7)
• Subtotal: 30/30 (capped)

Threat Landscape (Section C):

• Active exploit? Yes, live campaign, coordinated two-stage attack (+10)
• EPSS? No CVE assigned, treat as confirmed exploitation in-the-wild (+6)
• Threat actors? Sapphire Sleet (North Korean state actor) (+4)
• Subtotal: 20/20

Controls Posture (Section D):

• Dependency scanning in CI? Yes, CVE-based only, missed this package (-2)
• Network egress monitoring? Yes (-2)
• Build environment isolation? No (0)
• Secrets in environment variables, not vault? No deduction, increases exposure (0)
• Subtotal: -4

VRCM Score: 86 (Critical)

No CVE. No CVSS score. VRCM: 86, Critical. Immediate response required.

This is the supply chain gap that CVSS can't bridge. VRCM works even when there's no assigned vulnerability score, because it assesses exploitability, business impact, and threat landscape directly from what you know about your environment and the active threat. The absence of a CVE isn't the absence of risk.

⸻

🔗 How VRCM Relates to Existing Standards

VRCM doesn't replace these frameworks. It synthesizes them into something actionable.

EPSS - Exploit Prediction Scoring System

EPSS scores predict the likelihood a vulnerability will be exploited in the next 30 days (0.0 to 1.0).

CVE	CVSS	EPSS	Interpretation
Log4Shell	10.0	0.90+	Actively exploited - drop everything
Random obscure vuln	7.5	0.02	No one cares - fix when you can

VRCM uses EPSS in Question 10 to ground threat assessment in data, not gut feelings.

FAIR - Factor Analysis of Information Risk

FAIR calculates dollar-value risk using: Risk = Probability of Loss Event × Magnitude of Loss

Loss categories (Primary Loss):

• Productivity - Operational downtime and lost output
• Response - Incident response and investigation costs
• Replacement - Asset repair or replacement costs
• Competitive Advantage - Loss of market position or IP
• Fines & Judgements - Legal penalties and regulatory fines
• Reputation - Brand and trust damage

VRCM translates FAIR's financial quantification into Questions 6–8, making business impact tangible without requiring a full FAIR analysis for every finding.

The Sound Byte

CVSS: How severe? EPSS: Will it be exploited? FAIR: How much will it cost? VRCM: What do we do about it?

⸻

💡 Why I Built This

The frustration started with a side project. I had a self-hosted home lab running a mix of open source tools I'd spun up to experiment with threat detection and network monitoring. I ran a vulnerability scan against the setup out of curiosity and got back 47 "Critical" findings.

I sat with that list for a while. Some of those services were internet-facing. Some were locked behind WireGuard and only accessible from a trusted device. Some had public exploits. Others had CVEs so obscure they hadn't been touched since 2019.

A raw CVSS score treated all 47 the same. That made no sense.

I spent the next few weeks reading through OWASP's risk rating methodology, FAIR's approach to financial quantification, and what CVSS 4.0 improved on compared to earlier versions. I wanted a way to answer a simple question for each finding: is this actually a problem in this specific environment? The synthesis became VRCM.

When I ran those 47 "Critical" findings through it:

• 6 scored Critical or High - genuine issues that needed fixing immediately
• 14 scored Medium - worth addressing in a reasonable timeframe
• 27 scored Low or Minimal - useful awareness, not worth losing sleep over

40% reduction in the noise I was reacting to. Not by ignoring vulnerabilities, but by understanding which ones actually mattered in context.

⸻

🏗️ Implementing VRCM in Your Team

Week 1: Adopt the 12 Questions

Print them. Put them in your triage runbook. Every vulnerability that comes through gets 12 answers before it gets a priority.

Week 2: Calibrate the Scoring

Run your last 50 findings through VRCM and compare the scores against your team's actual triage decisions. You'll find patterns - maybe your team is consistently over-prioritizing or under-prioritizing certain categories. Adjust.

Week 3: Integrate with Tooling

VRCM can be automated into your vulnerability management workflow. Build a simple scoring template in your ticketing system or spreadsheet. The questions are designed to be answerable from scanner output + asset inventory data.

Week 4: Socialize the Results

Share the before/after with stakeholders. Show them how VRCM reduced the "Critical" queue from 47 to 6 while increasing confidence in the remaining priorities. That's the kind of metric that gets security a seat at the table.

⸻

🛠️ Try It Yourself - Interactive VRCM Tool

I built an interactive VRCM Assessment Tool you can use right now - no signup, no data collection, runs entirely in your browser.

→ Open the VRCM Assessment Tool

Walk through the 12 questions for any vulnerability in your environment and get an instant risk score, section breakdown, and a copyable plain-text report you can paste straight into your ticketing system. Three pre-loaded examples let you see the healthcare portal, internal inventory tool, and Axios supply chain scenarios from this article play out in real time.

⸻

🎯 The Bottom Line

Security teams are drowning in findings. CVSS gives us severity without context. Scanners give us volume without priority. What we need is a framework that says:

"This vulnerability, in this environment, with these controls, protecting this data, facing this threat landscape, equals THIS risk level. And here's what we should do about it."

That's VRCM. 12 questions. 4 dimensions. 1 risk score. Context-driven prioritization.

Stop firefighting every CVSS 9.8. Start asking the questions that matter.

⸻

📚 References & Further Reading

Foundational Frameworks:

• OWASP Risk Rating Methodology
• FAIR Institute - Factor Analysis of Information Risk
• CVSS v4.0 Specification
• EPSS - Exploit Prediction Scoring System

Related Research:

• CAVP: Context-aware Vulnerability Prioritization Model
• NIST IR 8286A - Cybersecurity Risk Enterprise Management
• NIST SP 800-30: Guide for Conducting Risk Assessments

---

VRCM is a framework I designed and implemented. If you're dealing with vulnerability overload and want to discuss contextual risk assessment, connect with me on LinkedIn.

---

Disclaimer: The VRCM framework, scoring methodology, and all views expressed in this article are my own and were developed independently in a personal capacity. They do not represent the views, methodologies, tools, or practices of any current or former employer. Any metrics referenced reflect personal experimentation and study, not organisational data. This content is shared for educational and informational purposes only.

#VRCM #VulnerabilityManagement #AppSec #DevSecOps #CVSS #RiskAssessment #SecurityFramework #EPSS #FAIR #SupplyChainSecurity #npm #Slopsquatting