In today’s interconnected software landscape, most applications don’t just spring up from thin air. Developers are constantly pulling in countless open-source libraries, frameworks, and other third-party components to speed things up and reuse existing solutions. And why not? If a specialized solution already exists for a particular problem, why reinvent the wheel? However, while efficient, this reliance opens up a massive new vulnerability: the software supply chain.

💡 This article is designed to accommodate different learning and reading styles, so feel free to jump ahead:

• Weak links: Anatomy of a supply chain attack and the new threat AI poses

• The intersection of dependency management, SBOMs and CVEs

• A stick or a snake: A framework for evaluating risk

• How security contributes to code quality

• More resources and references

Weak links: Anatomy of a supply chain attack

In the context of cybersecurity, a supply chain attack refers to a cyberattack that targets an organization by infiltrating less secure elements in its extended network of partners, suppliers, or components, rather than directly attacking the primary target itself. Simply put, it’s like a hacker getting to you by attacking someone you do business with.

The core idea is to compromise a trusted third party or a component that the target organization relies on. By doing so, the attackers can then gain unauthorized access or introduce malicious code into the target’s systems, products, or services without directly breaching their main defenses.

Think of it like this: If you want to break into a heavily guarded fortress (the main target), instead of attacking the front gates, you find a weakness in the company that supplies their food or builds their walls, and use that weakness to get inside.

These attacks are particularly dangerous because:

• They leverage trust: The malicious element comes from a source that the target organization or its customers inherently rely on.

• They have a wide blast radius: Compromising one component or supplier can lead to a ripple effect. That means that even if your organization wasn’t the primary target of such an attack, you can still be compromised.

• They are often difficult to detect: The malicious activity might be hidden within legitimate software updates, hardware, or services, making it challenging for standard security measures to identify.

Common vectors for supply chain attacks include:

• Software updates: Injecting malware into legitimate software updates, often by compromising the software vendor’s systems or exploiting vulnerabilities in the update delivery mechanism.

• Open-source components: Introducing malicious code into widely used open-source libraries that developers then incorporate into their applications.

• Hardware tampering: Modifying hardware components during manufacturing or shipping.

• Compromised build tools or environments: Attacking the tools or infrastructure used to build software.

• Third-party service providers: Gaining access through a less secure vendor that has legitimate access to the target’s systems (e.g., an IT service provider).

We’ve seen this play out in countless high-stakes scenarios, where everyone from savvy cybercriminals to highly resourced, persistent threat actors has leveraged these dependency pathways. These weren’t about traditional application hacks. They were about malicious packages quietly slipped into public repositories, compromised build pipelines, or trusted updates carrying hidden payloads. And it’s not always malicious! Sometimes a supply chain vulnerability is just a really, really big unintentional complication.

As these supply chain attacks and vulnerabilities illustrate, maintaining a clean Software Bill of Materials (SBOM) is critical to code security. An SBOM is essentially a detailed “ingredient list” for your software, identifying all its components, including open-source libraries and third-party code. This transparency helps you understand exactly what’s in your software, which is crucial because bad actors know how challenging it can be to assess, verify, and remediate these hidden supply chain vulnerabilities. In modern software, it’s a constant tightrope act of prioritization with weights that shift as you cross the wire.

But don’t worry — it gets more complex!

First came “vibe coding” …

“Vibe coding” is an emerging approach to software development, heavily reliant on artificial intelligence, particularly large language models (LLMs). First mentioned by AI researcher Andrej Karpathy in early 2025, “vibe coding” describes a process where developers primarily use natural language prompts — speaking or typing in plain language — to instruct AI tools to generate, refine, and debug code. The core idea allows users to focus on describing what they want the software to do (the “vibe” or intent), letting the AI handle much of the how (the actual code implementation), often without the developer needing to fully understand the generated code. This method aims to make software creation more accessible and potentially faster, especially for simpler projects or prototypes.

It has been met with both a great deal of skepticism and support. Love it or hate it, “vibe coding” is changing the way we approach the software development lifecycle, and with these new tools come new challenges.

Now there is “slopsquatting”

Coined by Python Software Foundation Developer-in-Residence Seth Larson and popularized by a Mastodon post from Ecosyste.ms creator Andrew Nesbitt, “slopsquatting” — more formally known as “package hallucination” — is a type of cybersquatting. It is the “practice of registering a non-existent software package name that a LLM may hallucinate in its output.” At best, developers may attempt to install an AI-suggested package only to run into an annoying error; at worst, these false packages are exploited.

For example, if an AI suggests using a non-existent package like super_fast_lib and a malicious actor then registers that name on a public repository, a developer blindly installing it could inadvertently introduce malicious code. This is where a robust Software Bill of Materials (SBOM) becomes crucial: An SBOM would ideally reveal the presence of such an unfamiliar or newly added dependency, alerting security teams to a potential slopsquatting attempt and a vulnerability in their supply chain.

Either way, slopsquatting is yet another threat to software supply chain integrity, and along with all the other risks of vibe coding, further emphasize the need for human oversight in AI-generated code.

Whether it’s a package that doesn’t actually exist or a package that has been deliberately exploited, software dependencies can be a point of weakness in any system. Secure code is an important aspect of the reliability and integrity of your production systems, regardless of whether the code comes from a third-party, AI, or in-house development. Implementing best practices at every step of development helps ensure that code is not only readable and maintainable, but secure as well.

The intersection of dependency management, SBOMs and CVEs

As highlighted by some of the most notable supply chain attacks and the emerging threat of “slopsquatting,” the increasing reliance on third-party software components underscores the critical importance of robust dependency management. This discipline isn’t just about integrating external code, it’s about understanding and mitigating the inherent risks associated with it. Central to this understanding are Software Bills of Materials (SBOMs) and Common Vulnerabilities and Exposures (CVEs).

What is an SBOM?

An SBOM acts as a comprehensive, machine-readable inventory of all components within a software package. Much like an ingredients list on a food product, a Software Bills of Materials (SBOM) details every piece of open-source and proprietary software, libraries, and modules that make up a given application, along with their versions and origins. And just as a food label might list “enriched flour” and then detail its components like niacin and thiamine, an SBOM also breaks down your dependencies’ dependencies, giving you a complete picture of every ingredient. For developers, maintaining an up-to-date SBOM is crucial for visibility into their software supply chain, enabling them to track and respond to security advisories more effectively.

What is a CVE?

Closely related to SBOMs are Common Vulnerabilities and Exposures (CVEs). A CVE is a publicly available identifier for a known cybersecurity vulnerability. When a vulnerability is discovered in a specific software component (often a library or framework), it is assigned a CVE ID. By cross-referencing components listed in an SBOM with known CVEs, organizations can rapidly identify and prioritize patching efforts for vulnerable dependencies. This proactive approach helps to prevent exploitation by malicious actors who might otherwise leverage unpatched weaknesses. The “SunSpot” malware’s ability to operate with elevated permissions and deploy backdoors underscores the severe consequences of unaddressed vulnerabilities, whether they stem from sophisticated supply chain attacks, more common software flaws, or AI hallucinations.

A stick or a snake: Not every CVE is a threat to your supply chain

According to CVE.org, 40,077 CVEs were published in 2024, which is a significant jump from 2023’s 28,961 published CVEs. Responding to each and every CVE in a supply chain is neither feasible nor practical and with FIRST (the Forum of Incident Response and Security Teams) predicting an increase of CVEs in 2025, you need to draw on other information to determine best next steps when alerted to a CVE for one of your dependencies.

Imagine you are walking down a road where snakes are known to slither and you see a stick in the distance. You might mistake it for something more dangerous than just an errant piece of wood. If you’ve had the misfortune of a snake bite, you might be biased toward assuming the stick is more than just a stick. Conversely, if you’ve never encountered a snake despite reports of their presence, you might walk too close past what you think is a stick and make your last mistake ever.

Not all dependency vulnerabilities and exposures pose the same risk. How a CVE may affect a system is dependent (See what I did there?) on a few different factors:

• The Common Vulnerability Scoring System (CVSS)

• The Known Exploited Vulnerabilities (KEV) catalog

• The Exploit Prediction Scoring System (EPSS)

Combining all these facets of a CVE helps provide a more holistic approach to vulnerability remediation. In order to understand how CVSS, KEV, and EPSS come together, it’s important to understand them independently.

What is the CVSS?

The Common Vulnerability Scoring System (CVSS) is a free and open industry standard for assessing the severity of computer system security vulnerabilities. It provides a numerical score (ranging from 0.0 to 10.0) that reflects the characteristics and severity of a vulnerability. Commissioned by the National Infrastructure Advisory Council (NIAC) and now under the custodianship of the Forum of Incident Response and Security Teams (FIRST), the CVSS was introduced in 2005. Its mission is to standardize vulnerability assessments to empower organizations to evaluate and respond to risks efficiently and effectively.

A CVSS score is determined by three metric groups:

1. Base: These represent the intrinsic characteristics of a vulnerability and are constant over time and across user environments. They consider factors like attack vector, attack complexity, required privileges, user interaction, scope, and impact on confidentiality, integrity, and availability.

2. Temporal: These reflect the evolving characteristics of a vulnerability over time. They account for factors such as the maturity of the exploit code, the availability of a fix, and the level of confidence in the existence of the vulnerability.

3. Environmental: These metrics allow for custom adjustments to the score based on the specific context of an organization’s environment. For example, a vulnerability might be more critical in a system handling sensitive government data than in a less critical internal tool.

To summarize, CVEs provide a unique identifier for a publicly known security flaw while the CVSS provides the numerical severity rating that helps organizations assess the risk associated with a CVE within their specific context. CVSS scores serve as a vital tool for making informed decisions about which dependencies to use, which to patch first, and how to allocate limited security resources most effectively.

What is a KEV?

While the CVSS provides a crucial framework for assessing the technical severity of a vulnerability, it doesn’t inherently tell you if that vulnerability is actively being used by attackers “in the wild.” This is where the concept of a Known Exploited Vulnerabilities (KEV) catalog becomes useful.

A KEV catalog is a curated list of vulnerabilities that are known to have been actively exploited by threat actors. Unlike a comprehensive database of all discovered vulnerabilities (which can number in the hundreds of thousands), a KEV catalog focuses on the subset of vulnerabilities that pose an immediate and proven threat because they have already been leveraged in real-world attacks.

The most prominent and widely referenced KEV catalog is maintained by the U.S. Cybersecurity and Infrastructure Security Agency (CISA). The CISA’s KEV contributes critically to cybersecurity by:

• Prioritizing remediation: If a dependency in your software has a CVE that appears on the KEV list, it signifies an urgent need for patching or mitigation, regardless of its CVSS score. (Not surprisingly KEVs often have high CVSS scores.) The fact that a vulnerability has been exploited means it’s not a theoretical risk, but a clear and present danger.

• Shifting from reactive to proactive defense: By focusing on vulnerabilities that attackers are already exploiting, organizations can more effectively cut through the noise of countless theoretical vulnerabilities and target efforts where they will have the most impact.

• Providing actionable intelligence: The KEV catalog is not just a list; it provides actionable intelligence to defenders. It serves as a clear signal from a trusted authority that these specific vulnerabilities are being weaponized and require immediate attention.

For federal agencies and — increasingly — for private sector organizations, vulnerabilities listed in the CISA KEV catalog are considered extremely high-priority. Without this particular KEV catalog, organizations may be forced to cross reference several different sources in order to not waste precious resources chasing after every single risk in an increasingly insecure cyber landscape.

What is the EPSS model?

In the ongoing battle to secure complex software supply chains, simply knowing about vulnerabilities (CVEs) and their technical severity (CVSS), or even if they’ve been exploited (KEV), isn’t always enough to make the most informed decisions. Security teams need to understand the likelihood that a newly disclosed vulnerability will be exploited in the near future. This is precisely the gap that the Exploit Prediction Scoring System (EPSS) model aims to fill.

The EPSS is an open, data-driven, and predictive scoring system that estimates the probability of a software vulnerability being exploited in the wild within the next 30 days. Developed by FIRST — the same organization behind CVSS — EPSS provides a crucial layer of intelligence that complements existing vulnerability management tools.

Unlike the CVSS, which scores the severity of a vulnerability’s potential impact, EPSS focuses exclusively on the probability that it will be actively exploited. A vulnerability might have a high CVSS score, but if no one is actually exploiting it, its immediate risk profile might be lower than a medium-CVSS vulnerability that has a high EPSS score.

The EPSS estimate is updated regularly based on the following criteria:

• The existence of publicly available exploit code.

• Discussions of the vulnerability on social media and dark web forums.

• The age of the vulnerability.

• The prevalence of the affected software.

• Its relationship to other exploited vulnerabilities. This dynamic nature means EPSS scores can change rapidly as new information emerges, reflecting the evolving threat landscape.

Combined with CVEs, a CVSS score, and data from the CISA KEV catalog, the EPSS estimate plays a vital role in an environment where the speed and sophistication of attacks — as seen in supply chain compromises — demand smarter and more efficient resource allocation to secure ever-growing and complex software dependencies.

In other words, security threats contain different facets of vulnerability that together determine the risk they pose and the urgency with which they should be addressed. Once you have decided that the stick down the road is indeed a snake, your next moves are based on your proximity to the snake, whether or not the snake is poisonous, whether or not an antidote exists, and whether or not the snake is an aggressive and deadly rattle snake or a common garter snake that will mostly likely just slither away upon your approach. In moments where quick decisions can be a matter of life or death — or a matter of a quick patch or a security notice to customers — these inputs help form a framework of threat evaluation that can help streamline next steps.

How security contributes to code quality

At a fundamental level, high quality code exhibits the following traits: it is maintainable, it is reliable, and it is secure. With software’s increasing power and complexity, relying on third party components is inevitable. And that’s not a bad thing — in fact, avoiding redundancy is a good coding best practice. However, since you don’t get to review the pull requests that are merged into the code of your dependencies, you need some other method of ensuring that their potential lapses in code quality don’t affect the quality of your code. These days, a robust and intelligent code quality discipline needs to include security considerations such as dependency vulnerability management.

A tool like SonarQube Advanced Security and its Software Composition Analysis (SCA) enables you to not only view all the dependencies within your project, but provides you with a list of dependency risks with holistic scoring and actionable fixes so you can prioritize next steps according to the specific needs of your organization.

In collaboration with Tidelift and its roster of open source maintainers, SonarQube SCA goes beyond public databases of vulnerabilities and provides insights straight from the source. This adds a layer of specialized intelligence that can help reduce the noise often associated with dependency scanning. While the Exploit Prediction Scoring System (EPSS) offers a probability of exploitation, building on the critical “Known Exploited Vulnerabilities” (KEV) catalog, SonarQube SCA further enhances this by integrating real-world maintainer insights, providing an even more refined and actionable understanding of risk. (Because we all know how often we actually look at our Dependabot alerts …)

💡 Want to learn more about SonarQube Software Composition Analysis? Check out a tutorial here.

More resources and references

• Read more about coding best practices here.

• Read more about best practices for dependency risk management in particular here.

• For a breakdown of other top security flaws and how to address them, check out Jonathan Vila’s article on the topic.

• Want to learn more about SBOMs? This article provides a comprehensive overview.