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

Following the recent npm ecosystem attacks, a new threat emerged: the ‘s1ngularity’ attack, and its subsequent evolution into the ‘Shai-Hulud’ worm. The new attack vector demonstrates a significant escalation in the tactics of malicious actors, moving beyond simple package compromise to target the developer’s environment and even their AI tools.

How did this differ from the previous npm supply chain attack?

Both the intention and vector of the attack were different.

The ‘s1ngularity’/nx attack was focused on harvesting credentials and data exfiltration.

The initial entry point was not a phishing attack (which was the vector of the previous attack), instead it exploited a vulnerable GitHub Action, which allowed attackers to steal an npm publishing token.

Notably this was one of the first documented cases of malware using AI command-line tools (like Claude, Gemini, and Q) to assist in identifying and exfiltrating sensitive data.

 as with previous attacks, immediately block any known malicious packages and versions.

 Use your Cloudsmith client logs to identify any user or service account that may have pulled down a malicious package.

 Enable Enterprise Policy Management (EPM) and Continuous Security. Use policies to automatically quarantine packages that are identified malicious by security feeds like OSV.dev.

 Due to the nature of these attacks, it is critical to immediately revoke and rotate all potentially compromised credentials. Think about implementing ephemeral tokens (using OIDC) or strict policies for short-lived tokens.

: implement a more robust security posture. This includes enforcing multifactor authentication, limiting the scope of access tokens, and closely monitoring your CI/CD pipelines for anomalous behaviour.

As with the previous attack, once identified, a simple EPM policy would quarantine malicious packages:

The 's1ngularity' and 'Shai-Hulud' attacks demonstrate that attackers will continue to exploit the trust within the open-source ecosystem. The gap between a zero-day and an n-day is shrinking, and the ability of a threat to self-propagate can cause widespread damage in a matter of hours.

Strengthening your software supply chain starts with understanding where you are today. Our free maturity assessment highlights gaps, benchmarks your current practices, and points you toward practical next steps. 

Npm ecosystem update: a new attack vector emerged with ‘s1ngularity’ and ‘shai-hulud’ attacks

 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 

Speed, reliability, and security are now essential in modern software delivery. With organizations increasing the speed of their engineering processes, software artifacts, including Docker images and npm packages, have grown to be the foundation of the development lifecycle. It is crucial to manage these artifacts effectively in order to enable teams to deliver to users faster and with greater confidence.

Historically, artifact management, like many parts of the CI/CD pipeline, was managed in-house, with organizations setting up their own artifact repository and infrastructure. Although such a strategy was viable at smaller scales, it frequently resulted in issues, particularly the lack of storage capacity, bottlenecks in performance within a region, and a high maintenance overhead.

In recent years, organizations have been shifting 

 towards the cloud. This move to cloud-native infrastructure removes the physical limits of on-prem systems and allows teams to scale across the world, reduce latency, and sustain high performance on each stage of the CI/CD pipeline.

This blog will discuss seven aspects of how a 

 system can enhance your software delivery processes by scaling and enhancing their performance, enabling teams to deliver software more quickly, dependably, and globally.

1. Elastic scaling of storage and distribution

Conventional artifact repositories often run into difficulties when engineering teams scale their usage. As developers begin generating hundreds of thousands of versions of Docker images, packages, or libraries, traditional on-premise systems require manual maintenance. This often involves increasing on-premise systems, more hardware, manual configuration, and frequent maintenance.

In contrast, cloud-native artifact management leverages elastic scaling to automatically expand storage as demand grows. This guarantees that as engineers produce more artifacts; performance will remain constant. With physical infrastructure deletion, scalability with artifacts is easily accomplished without capacity bottlenecks, and doing incremental upgrading is costly.

 performance does not only hinge on the storage of artifacts, it also depends on how quickly they can be accessed in different regions of the world to support globally distributed teams. The problem of latency is a significant problem in globally spread enterprises when teams are compelled to draw artifacts in one, centralized on-premise repository, which is often very distant from where builds are occurring. It may cause slow builds, delays in deployments, and exasperated developers.

Cloud-native artifact management systems address this issue through replication and caching. Replication is the process of storing copies of the artifacts in more than one location, in places near the teams that require them. Caching goes a step further: When an artifact is initially requested, it is momentarily stored, or rather cached, in edge servers at key points around the world. The next time a team in that region orders the same artifact, it can be delivered directly out of the cache, and they do not have to take a long, latency-intensive journey back to a central repository.

Systems and developers can retrieve the closest copy of an artifact, which can significantly reduce their retrieval time. This type of cloud-native scaling makes global distribution a strength and not a weakness, meaning that the performance of artifacts will not be weakened when teams are operating in North America, Europe, or Asia.

3. Seamless integration with CI/CD pipelines

Automation is the core of the new-generation software delivery, and artifacts are the key to any build, test, and release. Using cloud-native artifact management, repositories have been built into CI/CD pipelines, and artifacts have been made a first-class citizen in the delivery process.

New builds are automatically checked, analyzed and subsequently validated. Integration with other tools (i.e., Jenkins, GitHub Actions, and GitLab CI) through webhooks and APIs allows pipelines to continue running seamlessly. Such integration enhances the DevOps artifact management that helps in delivering much faster with a lesser amount of manual work and risk.

 repositories are often offline due to maintenance, upgrades, or other unexpected loss of online accessibility, thereby making development difficult. Cloud-native systems provide reliability by design, with redundancy and auto-healing load balancing being part of the infrastructure. This guarantees the presence of artifacts even when the demand is high.

For engineering teams, that means repeatability, uninterrupted workflows, and confidence that outages won’t disrupt delivery. By removing the fear of downtime, organizations can stay on schedule and ensure developers always have the artifacts they need.

Scaling artifacts with traditional infrastructure is typically expensive in terms of procurement costs, such as servers, storage, and licenses. Cloud-native models typically remove this limitation by allowing users to paying-as-you-go, aligning cost directly with their use.

Enhanced capabilities, such as deduplication, avoiding storage redundancy, and tiered storage, aim to keep commonly used artifacts from high-performance systems and archive older versions in lower-cost ones. This is an efficient way to enable scale as well as prevent overspending because of team growth. When artifact scalability and economic efficiency combine, so do performance and cost in cloud-native platforms.

The larger your store of digital artifacts becomes, the more critical it is to ensure their integrity and compliance. Cloud-native repositories often have built-in security controls, as they help to keep them trustworthy and auditable. Immutability characteristics disallow alterations from being made to published artifacts, and access restrictions stop undesired users from publishing or retrieving artifacts. 

Artifacts are encrypted both at rest and in transit and are integrated with SBOM reporting to achieve regulatory (SOX, HIPAA, GDPR) compliance. This is a security-first approach that guarantees both speed and trust to enterprises, as artifact performance is coupled with integrity and compliance.

7. Future-proof scalability for innovation

Technology does not stand still, and neither should your artifact management strategy. Cloud-native systems are futuristic and therefore can be scaled as organizations start adopting new architectures like microservices, edge computing and AI-driven development.

An OCI-aligned open standard helps an enterprise achieve long-term tool- and platform-portability. Such flexibility denotes that cloud-native scalability can be used to accommodate new workloads and worldwide growth without subjecting teams to re-engineering artifact handling. Organizations prepared today receive a platform that keeps in step with tomorrow’s innovation.

How Cloudsmith delivers cloud-native scalability and performance

Cloudsmith has been created to address these problems through its fully managed and cloud-based 

. Our platform is elastic, globally distributed, and tightly integrated with CI/CD pipelines without the complexity of managing infrastructure yourself.

 Allow storage and bandwidth to scale automatically as your volumes of artifacts expand.

 Deploy artifacts to 225+ edge sites around the world to be close to immediate access.

 Be able to plug directly into pipelines to securely store, scan, and deploy artifacts.

 Artifacts are available all the time, and 99.99 percent uptime makes this possible with redundancy.

 Immutability, RBAC, encryption, and SBOM capabilities keep your supply chain compliant.

 with global reach, performance, and security, Cloudsmith transforms artifact management from a bottleneck into a competitive advantage.

As the volume and complexity of software artifacts grow, organizations must ensure both speed and scalability in how they manage them. With cloud-native artifact management, businesses unlock global distribution, resilient infrastructure, and built-in performance optimization.

With cloud-native scalability of artifact storage, your teams will have faster innovation, more reliable shipping, and the trust of your customers—today and beyond.

1. What kind of software artifacts are best suited to use cloud-native storage?

Containers, language packages (Python, npm, and Java), Helm charts, and operating system packages can all be scaled in a cloud-native environment.

2. How does artifact performance differ between cloud-native and on-prem repositories?

Cloud-native utilizes multi-region replicating, distributed caching, and scalable infrastructures in order to minimize the latency and accelerate the speed of retrieval at a global level.

3. Do large enterprises only use cloud-native artifact management?

No, startups, medium-sized teams, and enterprises all enjoy it. Cloud-native is cost-effective at each scale of size because of its pay-as-you-go model.

Parul Jhawar

Marketing

7 Ways Cloud-Native Improves Artifact Management Scalability and Performance

DevOps is hard enough. You really don’t want your tooling to introduce new bottlenecks. You need speed, security, and reliability from your software supply chain—and when things go wrong, you need a support team that actually delivers.

 was born in the cloud. Legacy vendors built their tools for on-premise deployments, and even when these tools are “managed” in cloud environments, they can feel sluggish, fragmented, and reactive. Vendor support often mirrors that—gated to named users only, slow to respond, tiered behind ticket queues, and disconnected from engineering.

 flips the model on its head - not just in the way the product delivers on artifact management, but in the way it enables our team to deliver on customer support.

Cloud-Native by design means support that moves at your speed

. No patchwork of on-prem tools, no outdated architecture. This matters because it creates some really important support-related outcomes:

 Our cloud-native platform means our support team sees what’s happening across environments in real time. Legacy tools often require layers of logs, configs, and manual back-and-forth.

, without any manual intervention or advance planning. Legacy vendors often leave customers waiting for infrastructure adjustments 

 Cloudsmith evolves daily with continuous delivery. Support is never stuck in “which version are you on?” purgatory. That means when you request support, there’s no confusion about what version you’re on, or whether your feature set is “old” or “incompatible.” We’re all running on the same platform, always.

Cloud-native isn’t just a better way to deliver artifacts. It’s what enables customer support teams to be effective, fast, and relevant.

Support as a strategic partner, not a ticket queue

Here’s where the difference really shows. Legacy providers often treat support as an afterthought: slow response times, hidden behind multiple tiers, and “premium” price tags just to get basic help.

Our support is reactive, of course—we’re here when you need us–but it’s also proactive and embedded into how the platform operates.

 From the first interaction, customers speak with dedicated engineers who understand the platform inside out. There are no scripted handoffs, and no wasted time.

 Because we manage a single global service, our team sees trends across customers. If something looks off in your setup, chances are we’ve already solved it elsewhere—and we’ll help you get ahead of it.

Cloudsmith Blog

Using vulnerability scoring systems to prioritize risks in your environment

Npm ecosystem update: a new attack vector emerged with ‘s1ngularity’ and ‘shai-hulud’ attacks

Python 3.14 – What you need to know

7 Ways Cloud-Native Improves Artifact Management Scalability and Performance

Cloud-native means better customer support, too

npm ecosystem alert: What you need to do today with Cloudsmith

The platform of choice for AI companies

Why Repository Structure Matters

NX npm Supply Chain Attack: How Cloudsmith Would Have Contained the Blast Radius

Extending Supply Chain Governance to AI and ML Artifacts

Compliance policies in EPM

Typosquatting a package? How about typosquatting the whole registry!