By submitting this form, you agree to our 

Instead of wasting time clicking buttons in a UI, Cloudsmith gives dev teams the freedom to write their security rules as code for more power and flexibility. This approach, called policy-as-code, requires them to define precise limits/thresholds for what they consider a risky software artifact. When you're building policy-as-code, you can sometimes be stuck deciding exactly what thresholds to set for risky software artifacts. With a tsunami of vulnerabilities being thrown your way daily, it's impossible (and inefficient) to treat them all as emergencies. This blog post will help you understand the various scoring systems you can use to build smarter, context-aware security policies.

What is CVSS (Common Vulnerability Scoring System)?

For years, the Common Vulnerability Scoring System (

) has been the industry standard for rating the severity of vulnerabilities. It provides a numerical score from 0.0 (Low) to 10.0 (Critical), giving security teams a consistent way to assess risk.

A CVSS score is derived from three metric groups:

 Assesses the intrinsic qualities of a vulnerability, like the attack vector, complexity, and impact on confidentiality, integrity, and availability. This is a theoretical, worst-case assessment.

 Reflects characteristics that change over time, such as the availability of exploit code or an official patch.

 Allows you to customize the score based on your specific environment, considering factors like the importance of the affected system.

While CVSS is excellent for understanding a vulnerability's theoretical potential for harm, it can't answer the most important question: "

Does this actually pose a threat to my environment right now?

 (Common Vulnerabilities and Exposures) identifier without an accompanying CVSS score. This happens for a few reasons:

A CVE ID is often assigned the moment a vulnerability is disclosed. The detailed analysis required to calculate a CVSS score comes later from non-profit organisations like the 

 Some vulnerabilities affecting obscure products or deemed too minor may never get formally scored.

 If researchers and vendors disagree on a vulnerability's impact, it might remain un-scored until a consensus is reached.

What is EPSS? (Exploit Prediction Scoring System) and Why It Matters for Risk Prioritization

This is where the Exploit Prediction Scoring System (

) changes the game. Managed by FIRST.org, EPSS doesn't measure theoretical severity; it estimates the probability (from 0% to 100%) that a vulnerability will be exploited in the wild within the next 30 days.


A high CVSS score signals potential danger, but EPSS provides the real-world context needed to answer critical questions like:

"Is this vulnerability reachable from the internet?"

EPSS uses a machine learning model trained on vast datasets of vulnerability and threat intelligence. It's continuously updated to provide daily probability scores, helping you focus on the threats that are most likely to materialise.

It’s important to note that the EPSS model itself is updated periodically to maintain its predictive accuracy. For example, EPSS v4 was introduced on March 17, 2025, to improve performance.

When you look up an EPSS value, you'll see two numbers:

The direct output of the model. This is the probability of exploitation. (for example 0.92, or 92%).

 Ranks a vulnerability against all others. A percentile of 0.98 (or 98%) means this vulnerability is more likely to be exploited than 98% of all other CVEs.

How to Build a Risk-Based Vulnerability Triage Strategy Using CVSS, EPSS, and KEV?

Neither CVSS nor EPSS tells the whole story alone. The most effective strategy combines them with other key data points, like the CISA Known Exploited Vulnerabilities (

) catalog, which lists vulnerabilities that are actively being exploited in real-world attacks.

By layering these sources, you can move from a theoretical risk assessment to an evidence-based one. Imagine you have thousands of vulnerabilities. Instead of chasing every "Critical" CVSS score, you can narrow your focus dramatically.

The goal is to get to a workflow like the one depicted above. Of 922 known vulnerabilities, 352 might be rated "Critical" by CVSS. But by applying EPSS, you might find that only a small fraction have a high probability of exploitation. Add in context, like whether the package is actually in use and has a fix available, and you can pinpoint the few vulnerabilities that demand immediate attention.

Here is a practical matrix you can adapt for your own security policies to decide when it's okay to use a package versus when you need to take immediate action.


Use the matrix to prioritize fixes by combining severity, exploitability, and context in CVE details.

Don’t rely on labels alone. 
For example, a “High” CVE with low CVSS and EPSS may not need urgent action.

Always assess whether the vulnerability is actually exploitable in your environment. Do this before deciding to block or patch a vulnerable software package.

Both were assessed “High” by CVSS due to potential impact/scope if triggered, but EPSS (being telemetry/data-driven) remained very low because there was little to no evidence of widespread attacker uptake.

 in the Linux kernel had a CVSS of 7.0 (High) but an EPSS of just 0.04%. Why? Its exploitation requires local access and specialised conditions, making it an unattractive target for widespread attacks.

High EPSS before NVD had published details

 (a critical PHP vulnerability) had an EPSS score of ~94% days before the NVD published its full analysis and CVSS score. Teams relying only on NVD/CVSS feeds would have been blind to a major, actively exploited threat.

Why Traditional Vulnerability Management Fails in DevSecOps Pipelines

Blend EPSS (likelihood), KEV (known exploitation), and exposure context (is it reachable/authenticated?). For example, treat CVE-2024-4577 and 

 as urgent even if your NVD-only feeds lag.

When the NVD record date is later than public disclosure/research, lean on EPSS + vendor advisories + KEV until NVD catches up.

While it’s one thing to enumerate vulnerabilities within a platform, it’s another thing to enable our customers to manage the vulnerabilities in an effective way to reduce organisational risk as quickly as possible, while not impeding on development processes.

Creates a generic ticket: “CVE-2024-XXXX found in package Y”

Developer stops current work to research CVE while vulnerable package remains deployed in staging or production

Developer figures out which version fixes the vulnerability

Beyond EPSS: Combining Scoring Systems for Smarter Vulnerability Management

While EPSS is valuable in implementing a risk-based vulnerability management approach, it has limitations that have to be considered when integrating EPSS within a broader security strategy. For one, EPSS scores are only applicable to vulnerabilities with CVE identifiers, so unknown or unreported vulnerabilities (including zero-day vulnerabilities) that haven’t been cataloged with a CVE identifier are not covered.

EPSS should be part of a larger strategy, as organisations benefit more when they use EPSS along with CVSS and other vulnerability prioritization methods. The CISA KEV (Known Exploits) catalog, for example, informs security professionals if the vulnerability has already been successfully exploited in the wild. Combining EPSS, CVSS, and CISA KEV allows organisations to implement risk-based more effective vulnerability management.

Modern vulnerability management isn’t just about finding what's broken; it's about knowing if it actually matters. By combining CVSS, EPSS, and CISA KEV, you can build an automated triage system that only flags what's truly urgent.

This smarter lifecycle asks four simple questions:

Is it being actively exploited or likely to be (EPSS, CISA KEV)?

Is the affected asset internet-facing or part of a critical system?

If the answer to all is "yes," you act. If not, you can de-prioritize it and let your developers focus on what they do best: building great software.

Toward a smarter vulnerability lifecycle with Policy-as-Code

This triage model reflects the realities of limited time, team resources, and the explosion of third-party software risk. Users are advised to focus primarily on CVEs associated with in-use packages that have a known fix available. If there’s no fix available, we cannot take proactive steps to patch the known vulnerable packages.

Nigel Douglas

Head of Developer Relations

Using vulnerability scoring systems to prioritize risks in your environment

 is right around the corner, and there are 11 clear new Python Enhancement Proposals (PEPs) added to the Python project! There are several over significant changes listed within the 

Python 3.14 brings a whole bunch of useful build improvements, including discontinuation of PGP signatures in 

. Python versions 3.14 and onwards will no longer provide PGP signatures for release artifacts. Instead, Sigstore is recommended for verifiers. Similarly, free-threaded mode (

), which was introduced in the previous version, 3.13, has undergone major enhancements. The implementations outlined in this enhancement are now complete, incorporating updates to the C API, and the interpreter’s earlier temporary fixes have been replaced with long-term solutions.

The Cloudsmith team is really excited about this release and everything that comes with it! Note that some of the statuses may change between the time of this blog being posted and the final release date. Knowing that, let’s jump into all of the new features and improvements in Python 3.14.

Here are a few of the changes that Cloudsmith employees are most excited about in this release:

PEP 761: Discontinuation of PGP signatures

“From my perspective at Cloudsmith, the move away from PGP signatures in Python is a welcome change. PGP has long struggled with usability and the burden of managing long-lived private keys, and while it was the default for artifact signing, it never felt ideal. Sigstore offers a much more practical approach, using short-lived keys tied to human-readable identities, and it’s already gaining traction across ecosystems like PyPI, NPM, Homebrew, and GitHub. We’re also seeing projects we work with, like 

, embracing Sigstore, which reinforces that this shift is a real step forward for security and usability.”

PEP 734: Multiple interpreters in the stdlib

“This was an inevitable development, in my opinion. While the CPython runtime has supported running multiple interpreters, which are independent copies of Python within the same process, for well over 20 years at this point, the feature was still limited to the C-API and thus saw little adoption due to low awareness and the absence of a standard library module. With Python 3.14 introducing the new 

 module, this long-standing capability is finally becoming more accessible, marking a significant step toward mainstream usage. While current limitations remain, their impact will diminish as CPython evolves and the community contributes solutions via 

PEP 784: Adding Zstandard to the standard library

“Python 3.14’s addition of Zstandard (via 

) is an exciting upgrade because it brings one of the fastest, most efficient modern compression algorithms directly into the standard library, alongside a new unified 

, consistently outperforms older formats like 

 by offering both higher compression ratios and dramatically faster decompression speeds, which has made it the de facto standard across filesystems, packaging tools, and industry at large.

By including it natively, Python eliminates the confusion of multiple third-party bindings, enables direct support in core modules like 

, and opens the door for faster, smaller Python wheels and other packaging improvements. The reserved 

 namespace not only avoids naming conflicts with PyPI packages but also creates a clean, future-proof home for compression libraries, much like 

 does for hashing. This change reflects Python’s “batteries included” philosophy while giving developers a state-of-the-art compression tool that is both practical today and well-positioned for long-term usage.”

Free-threaded Python is now officially supported

 this enhancement proposal, which actually sets requirements for advancing 

, which was the larger, ongoing effort to make Python’s 

) optional. PEP 703 outlines a three-phase plan:

First phase introduces an experimental GIL-free build in Python 3.13

Phase two makes this build officially supported - though still optional

While Phase 3 makes it the default. 
This new feature defines the expectations for the second phase, ensuring the free-threaded build is stable, usable, and performant enough for broader adoption.

The motivation behind this shift is to balance the benefits of free-threaded Python, which offers greater concurrency, reduced latency, and expanded threading capabilities against costs such as performance penalties, memory overhead, and ecosystem complexity. Current benchmarks show around a 10% slowdown and 15-20% more memory use compared to the traditional GIL build, both considered acceptable trade-offs for Phase 2.

The APIs introduced so far have proven stable, and further refinements are expected without breaking changes. With growing third-party support and clear criteria for performance, memory use, documentation, and API stability, Python 3.14 is targeted as the point where free-threaded Python becomes an officially supported build.

Standard Library Support for Isolated Python Interpreters

Python 3.14 sees the addition of a new standard library module, 

, to expose CPython’s long-standing support for multiple interpreters in a single process. Each interpreter is strictly isolated, with its own modules, classes, and variables, while sharing only certain immutable or low-level process state. Unlike threads, which share most of the same runtime state, interpreters provide stronger isolation, making them better suited for parallelism, especially now that 

The new module will provide a high-level interface for creating, inspecting, and executing code in interpreters, as well as managing communication through a built-in, cross-interpreter-safe 

. This brings powerful functionality, previously limited to the C API, into Python code. An additional 

concurrent.futures.InterpreterPoolExecutor

 will be provided to simplify concurrent workloads.

The interpreters module defines an Interpreter object with methods like 

 to initialise globals. Interpreters can safely exchange data using 

, which supports pickle-based transfers and special handling for buffer objects like 

. This queue acts as a synchronisation and communication mechanism, enabling patterns like worker coordination across interpreters. For example, the below snippet taken from the PEP documentation shows multiple interpreters sharing a 

 of large data, synchronised with a queue token:

Making Parentheses Optional in Except and Except Blocks

 blocks in Python, users can now catch multiple exception types, so long as the “

” operator clause is not used. Currently, parentheses are mandatory around multiple exception types, a requirement carried over from Python2.

Removing this requirement simplifies the syntax, improves readability, and makes it more consistent with other comma-separated constructs in Python, such as function arguments and tuple literals. Parentheses will still be required when using as to capture the exception instance to avoid ambiguity. The change is purely syntactic, fully backwards compatible, and does not alter exception handling semantics.

Deferred Evaluation Of Annotations Using Descriptors

Python annotations let developers attach type information and metadata to functions, classes, and modules. Traditionally, annotations were evaluated eagerly when the object was defined, which led to common problems with forward references and circular dependencies. 

 attempted to fix this by “stringizing” annotations (storing them as strings), solving the forward-reference issue but breaking runtime use cases where actual objects were expected instead of strings.

A new proposal introduces a third, more flexible approach: lazily evaluating annotations through a dedicated 

 method. At compile time, Python generates a helper function that constructs the annotation dictionary, then attaches it to the object as 

. Accessing these annotations triggers this function, evaluates the annotations only when needed, and caches the results. This design eliminates circular-reference issues, preserves runtime usability, and allows for new introspection capabilities. Furthermore, 

 gain a new format parameter, letting users choose between evaluated values, forward-reference proxies, or source-code strings for annotations.

Here’s a simplified illustration of how this lazy evaluation model works:

With this change, annotations retain their runtime meaning while still avoiding forward-reference pitfalls, which supersedes the enhancement #563 string-based approach mentioned earlier, as well as offering a unified solution for both static and runtime use cases.

Safe external debugger interface for CPython

This introduction of a zero-overhead debugging interface for CPython should allow debuggers and profilers to safely attach to running Python processes. By providing well-defined safe execution points within the interpreter’s evaluation loop, external tools can request code execution without modifying normal execution or introducing runtime overhead.

This mechanism enables scenarios like attaching pdb to live processes by PID, similar to 

, allowing developers to inspect, evaluate, and step through running Python code interactively without stopping or restarting applications. Current approaches to live debugging in Python are risky because they rely on unsafe code injection, which can execute at arbitrary points in the interpreter, leading to crashes, memory corruption, or deadlocks. By integrating a small support structure into each thread state and extending the debug offsets table, this proposal ensures that debugging code is executed only when the interpreter is in a consistent and safe state.

The interface works by having debuggers write control information, such as the path to a Python script, into dedicated memory locations in the target process. The interpreter checks for pending debugger requests at existing safe points (via the 

), executing the provided code without interrupting critical operations like memory allocation or garbage collection.

 API simplifies remote execution for external tools, while environment variables and build flags allow redistributors and administrators to disable the feature if desired. Multi-threaded considerations are handled naturally: injected code runs under the normal GIL, ensuring thread safety, and can target individual threads or all threads as needed. This approach aligns Python with other major languages in live debugging capability while maintaining safety and zero runtime overhead during normal execution.

Deprecating PGP signatures for CPython artifacts

Again, this PEP isn’t merely a deprecation announcement. Instead, we see the introduction of an entirely new security model through Sigstore. Since 

, CPython artifacts have been signed with both PGP and Sigstore. PGP relies on long-lived private keys, which release managers must maintain and protect for many years, creating ongoing risks and burdens. In contrast, Sigstore uses short-lived keys tied to human-readable identities via OpenID Connect, greatly simplifying the signing process while providing stronger ergonomics. Sigstore is already gaining wide adoption across ecosystems like PyPI, NPM, Homebrew, and GitHub.

This new feature will not only deprecate, but will eventually discontinue the PGP signatures for CPython altogether, transitioning fully to Sigstore. Current stable releases (3.11 through 3.13) will continue offering PGP signatures until end-of-life, but new release managers (starting with Python 3.14) will not be required to generate them. Maintaining dual systems has slowed adoption of newer methods, creating a “

” that discourages verifiers from moving forward.

By dropping PGP, CPython can encourage downstream ecosystems to fully adopt Sigstore, while still providing flexibility for extraordinary delays if needed. Though this change shifts reliance to Sigstore’s centralised infrastructure, it aligns with the security practices already expected of release managers and leverages services better suited for long-term key management. Documentation will guide integrators, such as Linux distros and package managers, on verifying artifacts with Sigstore.

Disallow return/break/continue that exit a finally block

Python 3.14 – What you need to know 

Regulatory compliance in the software supply chain is a moving target that shifts with every dependency, security advisory, and regulatory update. Cloudsmith’s EPM puts control back in your hands by enabling development and operations teams to create real-time policy enforcement, right where it matters: at the package level.

By leveraging OPA and Rego, EPM lets you define precise, programmatic policies that determine how packages are evaluated, tagged, or quarantined before they’re ever promoted downstream. That means compliance policy enforcement is built directly into your distribution pipeline rather than being left to chance, or worse, post-release audits.

For development teams out there, the last thing we want to do is slowing you down with red tape security features. We want to help shift compliance left in the supply chain so issues are caught early, consistently, and transparently. Whether it’s blocking unlicensed packages, quarantining vulnerable builds, or ensuring artifacts meet naming conventions, EPM ensures that policies are applied automatically and uniformly through your own unique policy-as-code configurations.


Copy-Left policy that matches license strings

This policy is important from a compliance perspective because the use of 

 in production environments can create significant legal and operational risks if not properly managed. Many of these licenses impose obligations, such as requirements to disclose source code, distribute derivative works under the same license, or provide attribution, that may in some cases be incompatible with an organisation’s business model, intellectual property strategy, or contractual commitments.

By proactively detecting both free-text and standardised System Package Data Exchange (

) variants of these licenses, the policy ensures that potentially problematic code is flagged before it reaches production, enabling the necessary legal review or approval. This not only reduces the risk of inadvertent license violations but also demonstrates due diligence in open-source governance, which is often a key expectation in audits, customer contracts, and regulatory environments.

The license trigger conditions are highlighted in our detailed schema which is available towards the bottom of 

 v.3.1.1 package that we know has a GNU Lesser General Public License (

) license that should trigger the policy:

 If you have a tagging response action attached to your policy, you could tag the package with 

This policy checks whether a package includes specific 

 descriptors in the filename. This could be the simplest way for an organisation to state whether a package is a debug package, and therefore should not be ingested into, say, the 

The policy will trigger on these kind of wildcard examples:


Cloudsmith EPM allows users to easily match package filename metadata based on Regular Expression (RE) string matching patterns. Once ready, you can download the 

 Python package and push it to Cloudsmith to cause the policy violation:

From a compliance perspective, preventing debug, test, or temporary builds from entering production is critical because these artifacts often contain unverified code, verbose logs, or experimental features that were never intended for public release. If deployed, they may expose sensitive internal information, introduce security vulnerabilities, or degrade system performance, any of which can result in regulatory noncompliance, contractual breaches, or audit findings. Enforcing this control at the ingestion point ensures that only vetted, production-ready packages flow downstream, reducing the likelihood of costly incidents while demonstrating due diligence in software governance.

The use of RegEx strengthens this control by providing a highly adaptable mechanism for detecting noncompliant naming conventions across diverse development and CI/CD practices. Instead of hardcoding rigid checks, RegEx allows compliance teams to define broad yet precise patterns that evolve alongside the organisation’s software ecosystem. This flexibility enables policy enforcement to remain effective without creating excessive operational overhead.

This policy exists to ensure that packages coming from upstream sources are explicitly reviewed and marked as "

" before being allowed to proceed in the pipeline.

You could think of this as an advanced use-case for tagging. When both conditions are true, the policy will trigger. Note: There is also a commented-out condition for restricting it to specific repositories, if you’d prefer to whitelist certain repositories that are not under the same level of regulatory scrutiny.

From a compliance perspective, this policy enforces a controlled workflow for handling externally sourced or upstream packages, which are often beyond the direct control of the security team. By requiring an explicit "

" tag before these packages are considered safe, it creates a checkpoint where security, licensing, and quality reviews can be performed. This helps prevent unverified or potentially malicious code from entering production systems. It also encourages consistent documentation of the approval process, which can be important for compliance frameworks such as SOC 2, ISO 27001, or internal governance policies.

From a risk management perspective, the policy reduces the chance of introducing vulnerabilities, licensing conflicts, or compatibility issues from upstream sources. Operationally, it gives teams the flexibility to integrate valuable external software while maintaining a robust safeguard against unvetted changes. Over time, this approach can significantly improve software supply chain security, maintain regulatory compliance, and protect the organisation’s reputation by ensuring only reviewed and trusted packages make it into critical environments.


 architecture packages and blocks others like 

To trigger the above policy (which blocks all architectures 

), you'd want to upload or sync a Python package that is built for a 

 architecture - like arm64. However, pip by default fetches packages built for your local system architecture, so you typically won't download architecture-specific wheels unless they're explicitly tagged.

This architecture-specific allow list policy plays a critical role in compliance by ensuring that only packages built for the approved amd64 architecture are permitted in production and testing environments. In organisations standardised on x86-based servers, containers, and CI/CD pipelines, introducing packages built for other architectures, such as the case with arm64, can create hidden risks such as runtime failures, inconsistent behaviour across platforms, or the inability to reproduce builds reliably.

From a compliance perspective, these risks undermine key principles of software assurance, reproducibility, and auditability, all of which are essential for demonstrating control over the software supply chain. Blocking non-amd64 packages at enforcement ensures that software deployed downstream aligns with documented infrastructure baselines, reducing the likelihood of noncompliant system configurations.

Additionally, different architectures may introduce unique vulnerabilities, require distinct patching procedures, or fall outside the scope of validated security tools and compliance checks. Allowing multiple architectures without proper governance complicates vulnerability management, weakens evidence for audit trails, and can create gaps in regulatory coverage. By restricting deployments to a single, vetted architecture, this policy simplifies compliance verification, strengthens the integrity of vulnerability scanning, and provides assurance that all deployed software is consistent with approved security and operational standards.

Build your own compliance policies with Cloudsmith EPM

These four examples illustrate just a handful of the ways Cloudsmith EPM can be applied to enforce regulatory compliance across your software supply chain. From licensing governance to architecture restrictions, debug-build quarantines to upstream approvals, each policy demonstrates how compliance controls can be codified, automated, and enforced consistently.

But this is only the beginning. Because EPM is powered by OPA and Rego, it offers almost limitless flexibility to address the unique compliance challenges your team is facing. Whether you’re aligning with industry standards like ISO 27001 or SOC 2, meeting customer contract requirements, or simply reducing operational risk, you can design policies as code that fit your exact environment.

The power lies in treating compliance as part of your pipeline rather than an afterthought. With Cloudsmith EPM, you can move fast without breaking trust, ultimately ensuring that every package that flows downstream has already been checked, validated, and approved against the rules that matter most to your business. Check out our official documentation on how to 

Compliance policies in EPM

Typosquatting is now a well-known exploit, whereby malicious actors register domains or package names that are visually similar to popular ones. Examples include misspelling 

 as “expresss” - a mistake we’ve all made when typing too fast under pressure. Normally, when you make a typo retrieving a software package, you just get a build error since the package doesn’t exist. However, adversaries pick up on these subtle behaviours and in the process publish package names, deliberately containing malware, knowing someone is inevitably going to make this mistake at some point.

We just saw this threat has escalated. Instead of just mimicking individual package names in ecosystems like npm or PyPI, attackers are squatting on 

An alarming post by Bruno Schaatsbergen on 

 highlights this issue. A user discovered an active container registry at 

, which is the GitHub Container Registry. The poster warns: “I'm not sure who owns it, but be careful”. And it makes sense, unless investigated further, it’s unclear what is currently being distributed via this fake registry. Funny side note, if you go to the fake (ghrc.io) instead of the correct Github Container Registry address, it displays one of those generic default Nginx web server pages instead of the expected Github redirect (

Again, simple typo, swapping the positions of “r” and “c” leads to a completely different registry. Given that container workflows often operate in scripts or automated pipelines, a single-character mistake can redirect your push or pull operations to an attacker-controlled endpoint.

While it might seem unlikely that this is happening right now in any organisation, a simple 

 would show you that this typo has been made on quite a number of occasions. If your CI/CD workflow is also scripted to push to 

, those images will never reach GitHub, and instead will end up elsewhere. In doing so, the adversaries operating 

 could intercept or modify container images. They might serve backdoored images, leak credentials, or inject exploits. But this stuff is easy to make mistakes with. In logs or configuration files, 

 basically look identical at a glance. Developers may not notice the swap until something breaks, or even worse, when the damage is already done.

But you can take action. As an immediate first step, you can carefully review your registry URLs, especially in automation files like Dockerfiles, CI pipelines, docker push or docker pull commands. Additionally, you could enforce DNS or host-level protections to prevent access to known malicious or typo versions like GHRC. Explicitly only allow the registries that you expect to work with.

 exists as a live container registry masquerading behind a one-letter typo of 

This reflects an escalation from typosquatting individual package names to targeting entire registries.

The implications are severe. As the story evolves, it is worth adopting some vigilance when working with your container registries.

 later clarified that while the 401 response and 

 header are standard parts of the OCI spec, in this case they’re being returned by a server that isn’t a registry at all. The fact that only the 

 endpoint mimics OCI behavior, while the rest of the site is a default nginx install, suggests the setup is intentionally crafted to lure OCI clients into sending credentials to a fake token API.

This scenario highlights why companies should prefer providing developers a registry within their organisation. Having a control plane (like Cloudsmith) in front of registries in which to verify and block things like this fake registry, backed-up by a powerful audit trail for post-incident forensics.

Typosquatting a package? How about typosquatting the whole registry!

Cloudsmith’s Enterprise Policy Management (EPM) now supports the Open Source Vulnerability (

) database as an additional data source, so users can define 

 policies. OSV.dev is a distributed vulnerability database specifically for open source software (OSS) packages, including dependencies. The open, precise, and distributed vulnerability information for OSS projects from OSV complements EPM’s existing vulnerability data from Common Vulnerability Scoring System (

) and Exploit Prediction Scoring System (

The OSV database was originally developed by Google, and is fully open source. It consolidates data from multiple vulnerability repositories that follow the OSV schema, such as 

 database, Python Packaging Advisory Database (

OSV offers a straightforward API that allows clients to look up vulnerabilities based on either a specific commit hash or a package version. All records adhere to the 

 specification, which was created through collaboration with open-source communities. This schema provides a standard approach, for both human- and machine-readable format for detailing vulnerabilities, ensuring they can be accurately linked to exact package versions and commits.

Creating a Malicious Package policy in Cloudsmith

Let’s look at an example of Cloudsmith EPM policy. This one serves as a malware detection gate. EPM runs 

 the Cloudsmith security scan completes during package synchronisation, making scan results available as 

. In this case, the policy code loops over the 

 array, which is the OSV malware data from the scan. For each vulnerability object, it checks, “does the ID start with the string 

So what does this policy do in practice? It flags any package that has been reported as known malicious as part of the OpenSSF Malicious Packages project. "

" is used specifically in vulnerability feeds to indicate malware-related findings. Once a match is found, Cloudsmith will execute the 

Cloudsmith Blog

Using vulnerability scoring systems to prioritize risks in your environment

Python 3.14 – What you need to know

Compliance policies in EPM

Typosquatting a package? How about typosquatting the whole registry!

Managing Malicious Packages with Cloudsmith EPM

Migrating from Docker Content Trust to Sigstore

Kubernetes 1.34 – What you need to know

OWASP CI/CD Part 10: Insufficient Logging and Visibility

Pull back the hood on the data and tech that informs EPM

Unlocking policy-as-code automation with Cloudsmith EPM

OWASP CI/CD Part 9: Improper Artifact Integrity Validation

Security is a leading priority for 2025