KubeCon + CloudNativeCon North America 2025 is almost here, bringing together thousands of developers, security leaders, and platform engineers, to explore the latest in cloud-native technology. With dozens of talks, workshops, and keynotes across multiple tracks, it can be tough to know where to focus your time. To help, we’ve curated a list of 

 covering security, AI, cloud-native innovation, and platform engineering - including some interactive, hands-on experiences.

Georgia World Congress Center, Atlanta, GA

1. Kong AI gateway & insomnia workshop: AI success through API heroics

 Embassy Suites by Hilton Atlanta at Centennial Olympic Park

 is hosting this hands-on workshop exploring how AI-driven APIs can streamline workflows and improve automation. Attendees will work with Kong’s API Gateway and Insomnia tools to see practical examples of AI integration in real-world projects. If you’re curious about how Kong secures its software supply chain while supporting modern development practices, check out their 

2. Project lightning talk: The same great OPA, only faster

 Building C | Level 3 | Georgia Ballroom 2

 performance, demonstrating how teams can implement faster, more efficient policy-as-code pipelines. Learn tips and tricks for maintaining security and compliance at scale, while reducing the friction often associated with enforcing policies in CI/CD pipelines.

3. Capture the Flag challenge: Defend the pipeline

 Hilton Garden Inn Atlanta Downtown | Atlantic Room - 2nd Floor

 where you’ll defend a CI/CD pipeline against realistic attack scenarios. Participants can test their skills against malicious packages, misconfigurations, and supply chain threats, all in a safe, gamified environment. This session is a great way to see security best practices in action and get hands-on experience defending a modern software pipeline.

4. Keynote: Supply chain reaction - a cautionary tale in K8s security

This keynote examines lessons learned from major supply chain attacks and highlights how Kubernetes environments can be hardened against similar risks. Security leaders and DevOps teams will gain actionable insights on improving artifact integrity, detecting threats early, and reducing downstream risk across CI/CD pipelines.

5. Keynote: Maximum acceleration - Cloud Native at the speed of AI

Adobe’s Joseph Sandoval explores how cloud-native architectures can be optimized for AI-driven workloads. The session covers practical strategies for designing infrastructure that can scale dynamically, accelerate development cycles, and maintain operational reliability while supporting AI initiatives across the enterprise.

6. Taming the complexity beast: Rethinking software architecture & deployment

This session brings together engineers from Chainguard, IBM, and other organizations to share how they simplify complex architectures and streamline deployments. Learn practical approaches for reducing operational overhead, improving reliability, and supporting fast-moving development teams across multiple platforms.

7. Platform Engineering day zero: The origin story

Google’s Murriel McCabe shares a blueprint for building scalable platform engineering teams from scratch. Attendees will learn how to structure teams, select tooling, and define processes that maximize productivity and maintain developer velocity from day one.

8. Keynote: There’s nothing to fear about the EU’s new Cybersecurity Law

Linux Kernel maintainer Greg Kroah-Hartman explains the implications of the EU’s new cybersecurity legislation for open-source projects and enterprise security teams. This session is essential for anyone responsible for compliance or managing public and private codebases.

9. Turn up the heat: Driving cloud-native innovation into real-world impact

Learn from real-world examples of how organizations are accelerating innovation while maintaining secure, reliable cloud-native deployments. This session highlights strategies for balancing velocity with compliance, and how cloud-native principles can drive tangible business outcomes.

10. The hidden risks in AI/ML supply chains: How to secure your workloads

 Building B | Level 5 | Thomas Murphy Ballroom 1

Yash Pimple from Chainguard explores the emerging security challenges in AI/ML pipelines, including model provenance, dependency risks, and how malicious artifacts can propagate across environments. Attendees will get actionable guidance on securing AI workloads in production.

11. Cloud-native back to the future: The road ahead

Microsoft and Akamai leaders discuss the evolution of cloud-native practices, including modern tooling, automation strategies, and architectural patterns that will define the next era of software delivery.

12. Ulysses: Odyssey through platform engineering

William Rizzo of Mirantis takes attendees on a deep dive into platform engineering maturity, sharing lessons learned, best practices, and practical advice for building reliable developer experiences at scale.

13. Mapping the next phase: Updating the Cloud-Native maturity model for 2025

Akamai, StackEgy, and Glennium explore how cloud-native maturity models are evolving in the AI era and what this means for teams designing future-ready infrastructure. This session is ideal for technical leads planning long-term

 at KubeCon + CloudNativeCon 2025! Gain insights from booth lightning talks, get hands-on with live demos, and swap ideas with engineers solving the same challenges you are. Our team will be on hand to demo our cloud-native artifact management platform, answer your questions, and share tips on securing your software supply chain, AI artifacts, and CI/CD pipelines. We can’t wait to connect with you in person and explore how Cloudsmith can help your teams move faster, stay secure, and embrace modern development practices.

13 sessions not to miss at KubeCon and CloudNativeCon 2025

When a region in the Cloud goes down, it impacts people everywhere. Engineers are stressed. PagerDuty is screaming. People are asking questions. That’s not the moment to blame your Cloud provider or write cynically about single-cloud risks. It’s time to knuckle down and take responsibility.

On Monday, October 20th, 2025, a large part of the internet blipped in and out of existence. One of AWS’ busiest regions, us-east-1, went dark. A single DNS bug inside DynamoDB snowballed into hours of failures worldwide. The list of affected services was absurd: PlayStation, Snap, Disney+, Slack, Zoom. And the weird ones: VAR decisions in the Premier League and the inability to control Eight Sleep beds. It hit some harder than others, but even companies built for ultra-high availability, like Vercel and our own Cloudsmith, saw some impact.

Outages like this aren’t surprising. They range from mild and short-lived to rare and catastrophic. But they all share one thing: inevitability. Every service with real users will eventually get hit by something upstream, midstream, or downstream. The important part is not that they can happen; it's that they 

. It might sound macabre to suggest three certainties in life: death, taxes, and outages. But if you build services others depend on, maybe that’s not far off.

So how much should you care? As always in engineering, 

Critical infrastructure is any system that people or businesses rely on to deliver their own value. It isn’t defined by size or marketing, but by dependency. If your outage prevents someone else from fulfilling their promises to customers, and they can’t operate, deploy, or ship because of you, you’re a critical dependency, whether you consider yourself that way or not. Your downstream might be banks, game studios, logistics companies, database providers, automotive manufacturers, trading platforms, or alert systems. Internal or external, it’s all critical.

So, it’s a big ask. But someone is paying you, so they don’t have to think about it. That’s why you exist.

The outage made me think about the “3Rs of building critical infrastructure” and why they matter:

 You own the story of your architecture, uptime, and blast radius.

 Design for failure at every layer, so the system continues to run when something breaks.

 Outages are inevitable. No platform is perfect. Your honesty and preparation are what matter.

When you sit in someone else's critical path, the 3Rs are the cost of doing business well. Responsibility means you don’t blame vendors for the choices you made. Resilience means you engineer for failure as if it were a routine occurrence. Reality means you’ve got a job to do, and outages aren’t hypothetical. They’re coming. You just don’t know when.

I’ll return to the 3Rs later, explaining how we apply them inside Cloudsmith and how that might relate to you. However, it’s worth examining what happened last week, as just like backups are not real until you try to restore them, an outage of this magnitude is a significant test of the 3Rs across the industry.

When us-east-1 went down, it had a long tail recovery, and we saw a broad spectrum of responses in the industry: Some services kept operating, some degraded gracefully, some vanished (for a time). Some pointed fingers. Some used it for marketing. And some wrote about it. The best stayed calm, honest, and worked to minimize the impact.

So what did it look like for us as a vendor?

First, you don’t need another retelling of what happened during the AWS outage. If required, there’s an 

. However, I'd recommend reading one of my favorite blogs to follow, The Pragmatic Engineer, where Gergely Orosz asked, “

?” and articulately wrote about it, with diagrams. He explains the root cause: a DNS failure in DynamoDB caused by a race condition. The failure snowballed, from the inability to start or manage EC2 instances to a thundering herd of network congestion issues. DynamoDB was down for around 3 hours, but the EC2 outage (and things built on it) extended to around 12 hours beyond that.

An approximate timeline for the entire event looks like:

Gergely also mentioned one of my all-time favorite Haikus (even though it’s not 

Well, DNS, plus the bane of engineers everywhere: the Heisenbugs that manifest from race conditions. Gergely’s article also provided an excellent insider's look into how the outage was connected to other architectural components within AWS (as many people know, us-east-1 is a crucial control plane), as well as the sequencing of the events that led to, participated in, and followed the blackout. I’d also recommend “

” by Jonathon Belotti for additional technical details. Read both and return here to continue.


Back to the matter: What happened behind the scenes at Cloudsmith during the outage? First, let’s look at our public 

. On Monday, 20th October, we posted the following public communications (in addition to private communications sent directly). As shown, the incident from our perspective lasted for around 90 minutes:

Peering behind the veil, this is what was happening (times in UTC+1/BST/IST):

~9:18 AM. We were alerted to potential customer issues near us-east-1, and a low-category incident was raised as an SEV-3 (code for “may or may not be a big problem”).

~9:22 AM. The engineers could not start a Zoom call, indicating that the issue was possibly something more unusual than a “regular” outage. A Google Meet call was utilized as a fallback.

~9:30 AM. The team continues to investigate the root cause and notes that the investigation is slower due to some issues with our observability and logging tooling. However, after checking in with the team at AWS, we discovered that an incident had been raised with DNS as the potential root cause, affecting us-east-1.

~9:35 AM. Traffic continues to route worldwide, and most customers are not impacted; the team observes that some of our observability/notification systems are affected, requiring extra investigation effort.

~9:46 AM. The team notes that a dependency on pulling the latest TrivyDB from Public ECR has impacted our ability to execute some vulnerability scans and is intermittently blocking some package syncs.

~10:11 AM. The team notes that upstream fetching is failing for requests serviced near us-east-1.

~10:15 AM. The team highlights that the most significant impact is that Docker Hub is down, and a fetch bug related to tags has caused some issues for many customers. An engineer is assigned to fix it.

~10:20 AM. The team notes that some non-critical processes are impacted, such as slower webhook delivery broadcast in comms. In anticipation of recovery and to help with traffic routed to other regions, the team pre-emptively scales out additional resources.

~10:26 AM. Early signs of recovery are noted for AWS. The team notes that the Docker pull issue continues to impact customers. We communicate estimates directly with customers affected by the fix.

~11:04 AM. Due to AWS’ recovery and a combination of mitigations, impacted services for uploads, downloads, and webhooks are beginning to recover. Metrics are looking gradually healthier.

~11:07 AM. The incident is considered “resolved” due to system-wide recovery. The team notes that AWS is still encountering issues. Still, since we don’t operate critically in us-east-1, the impact on Cloudsmith and Cloudsmith customers is massively reduced at this point, enough to consider incident resolution.

~12:30 PM. The fix for the Docker image fetching is tested and ready for shipping, but the team is encountering issues with our deployment services. Therefore, they plan to deploy the fix manually.

Side question: You ask, how do you remember all of these details, Lee? We use 

 religiously to catalog everything that happens during any incident, outage, or other event. The auto-Scribe feature is a fan-favourite amongst the engineering teams at Cloudsmith. Subscribe to the church of graphs, yes, but also to the church of ... scripture? Either way, keep track of what happened.

For clarity, the following provides a simplified visual of what the multi-regional routing looked like during the failure, including Docker Hub’s unfortunate downtime, which added salt to the process of pulling images for some of our customers affected by the caching bug. Aside from that, when traffic got routed away from us-east-1 and towards us-east-2, things Just Worked; this is something that often automatically happens due to latency-based routing with associated health checks (note: we run in several regions worldwide, but us-east-1 is deliberately not one of them, because we chose to avoid AWS’s control plane on purpose; we have edge nodes there, though):

During the incident, we relied on a combination of Incident.io, DataDog, Sentry, and CloudWatch to tell us the story and communicate with potentially impacted customers. However, those services were at least partially impacted; the combination of multiple, plus manual effort, allowed us to investigate thoroughly. The following shows a CloudWatch graph highlighting the spikes in 5xx (errors) for customers located near us-east-1, mostly frontloaded, as well as gradual recovery towards the end of the incident (times are in UTC+1/BST/IST):

From the post-incident review, we had the following observations and fixes:

The Docker image fetch bug was fixed almost immediately after the incident was closed.

Our primary methods of communication (Zoom and Slack) had issues during the incident, and although we had fallbacks, we had some initial problems; we noted that we should add them to BC/DR processes.

We required manual fallbacks for specific processes, such as deployment and incident management, due to the outage impact on other vendors we use; we noted the need to document these processes more effectively. The team was satisfied that we didn’t need any operational change with our vendors.

The dependency on TrivyDB at runtime for scanning was identified as a potential failure point; we’ve taken action to automatically fail over to our own cache for this purpose (caching = less freshness). This failure was initially overlooked, so we’ve also taken action to enhance monitoring for this issue.

Although we didn’t need to failover all clients near us-east-1 to another region (our closest region that services people is actually in us-east-2), we noted that it should be easier to route traffic away completely to reduce intermittent noise (e.g., via retries); we’re already working on Edge-based work related to this.

Although the outage didn’t affect S3, and our confidence in it remains high, we did note a potential future impact for customers who store artifacts within specific regions for compliance reasons. However, we are developing new global storage topologies that remediate this issue. Watch this space.

So, we were not perfect, but it was good. The team did fantastic work with a highly unusual outage; as noted above, we required some manual fallbacks, and we had a reduced (or frustrated) ability to investigate, but the combination of our architecture and the strength of the vendors and platform we’re built on meant the storm was weathered. I’m confident that if us-east-1 had failed more extensively, it would have been problematic, but not catastrophic; although it is AWS’s control plane for some services, global routing would have continued.

I’m pleased to say that we had very few complaints during the outage, and despite it all, we still achieved our internal targets for overall availability. For those customers who were impacted, I know they felt that we were doing our best to minimize the disruption. Although operating a critical infrastructure service is high-stakes and high-pressure for the team, it’s also gratifying to be a crucial part of our customers’ operations. When they have problems, fixing (and preventing) them is hugely satisfying.

OK, that’s what happened at Cloudsmith; what about the 3Rs mentioned earlier?

Responsibility is simple. If you’re part of someone’s critical path as a dependency, then you own the results and outcomes. Not AWS. Not another vendor that you’re built upon. This truth doesn’t mean you can’t use vendors or trust them. No, it’s the complete opposite. It means 

, but like any other final link in the software supply chain, as the last touchpoint, the buck for accountability stops with you and your service. It’s a 

Winston Churchill once said that “the price of greatness is responsibility.” He wasn’t talking about distributed and high-availability systems, but the principle holds. Here, the greatness is the trust of your customers in your service, and the price is that you have to deliver on it, so you don’t get to point at someone else’s status page and say, “Not our fault.” You architect to prevent it. And you fix the problem, now or next.

Although I’m loath to provide counter-examples of this, Gergely, who I mentioned earlier, tweeted that Robinhood, a popular market trading platform popular in the US, with a market cap of $125B, had issues throughout AWS’ outage in which people were unable to make or complete trades, 

because they hadn’t architected for multi-region

. Their primary communication with users was “AWS is experiencing an outage”. It didn’t go down well (although I personally have no reason to think that Robinhood cares less about their users; they’ll be taking notes):

When a region goes down, customers don’t care which of your internal services or vendors broke, only that it broke 

, indirectly or not. For a domain like Robinhood’s, it meant that the livelihood of people who rely on it for trading was completely locked out, personal or business, and perhaps critically so if they 

 on the executed trades. By comparison, in our domain, our customers cared that they couldn’t fetch or deploy software on time. Completely different domains and use-cases, but the impact was equivalent; stopping you from working.

So for us, the responsibility for critical infrastructure means:

We don’t blame vendors for our choices or the architectures we built.

We stay accountable for the experience we deliver, even when it’s not a positive one.

And when something breaks, we say what happened, what we did, and what we’re fixing.

It’s not a glamorous part of the job, but it’s probably the most important of the 3Rs, which leads us to the question of, if you’re highly responsible, what should you be doing as a service to ensure continuity?

Resilience is the practical side of responsibility. If responsibility is the duty of care, then resilience is the method. If you’re building critical infrastructure, you don’t assume components behave or exist in an untouchable vacuum. You think they will fail. DNS breaks. Race conditions happen. Dependencies fall over. That one part of your logging pipeline that shouldn’t be critical but somehow disappears. Expect the unexpected.

And yeah, regions can fail. Cloud can fail. So, why AWS? I’m sometimes asked why we chose AWS and why we haven’t adopted a multi-cloud strategy yet. When we decided on AWS several years ago, there was no competition as to which Cloud was better; it was AWS, and I think it still is (but others are catching up). They’re a fantastic partner, enabling us to build a worldwide, fault-tolerant, resilient, highly available service.

, which goes well beyond the context of security. Not only do we build for an ecosystem to work well with others, but we also believe in building on partnerships (more on that later). AWS, in particular, excels in both security and operational aspects 

 the Cloud. Cloudsmith focuses on security and operations 

the Cloud. It’s a highly symbiotic match that allows us to do what we do at scale.

Multi-cloud is a whole other kettle of negative fish. We wouldn’t have the same symbiotic relationship, and trying to run our infrastructure in several drastically different ways would dilute our offering. It’d be OK for connectivity/routing; otherwise, I would be wary of saying multi-cloud is an excellent or good answer for resilience. It’s not. Cloud providers already provide tools to enable excellent, resilient architecture. Corey Quinn, of the Duckbill Group, wasn’t pulling too many punches when he said, “

Boring > "Interesting" > Exciting. In other words, it just works, and works well.

So for us, the resilience for critical infrastructure means:

Designing for failure from day zero, with a composable architecture built for redundancy and failover.

Minimization of failure from dependencies and upstream services to reduce or isolate cascading failures.

Expect the unexpected with escape hatches and (sometimes manual and unusual) fallbacks, for extreme scenarios.

If you think, “that sounds expensive”, you would be 100% right. Let’s just say that we had to justify the reason that our Cost of Goods Sold (COGS) was not particularly good early on. And yet, it’s the morally right investment if you’re building 

like we’re building. We did it, not because it was cool or shiny. Most people will never see it directly and will only feel its absence. No. It’s because resilience is the method to deliver on that duty of care.

OK, so it’s expensive to build and mandatory for critical infrastructure, but what’s the reality of running it?

You’ve probably guessed the reality already, but it’s still uncomfortable regardless of whether you’re a service provider or a service consumer. No matter what you do, how well you build it, or how much COGS you’ve turned into resilience, something will break in ways you didn’t expect, and people will be impacted. There are no magic bullets for this, and anyone claiming 100% uptime is probably 

There is no perfect platform to build on that will protect you, but some do a better job than others. AWS, Google, Azure, Alibaba, DigitalOcean, a VPS provider, racks in your own data-center, your machine under the desk: all of them have outages, caused from any combination of mechanical gremlins and chaos monkeys, through to Human error and PEBCAK. Cloud platforms are not infallible gods. They’re software and people, at a massive scale.

OK, great, so we’re all doomed then? Well, no. Businesses are software and people, too. The whole world is 

software and people. People know and understand that things break, but do you know what people like? Doing business with others who care, take their job very seriously, and exercise the appropriate care to build the thing well that others depend upon. Yes, the other 2Rs, responsibility and resilience.

They also appreciate partnerships, and good partners clearly communicate their expectations to each other. Corey said it pretty well in the above article, which applies more generally than the original quote, that “regardless of what provider you pick, once a [vendor is part of your critical infrastructure], they cease being your vendor and instead become your partner [...] Adversarial relationships aren’t nearly as productive as collaborative ones.”

 we have is “Automate Everything,” but many people don’t know that the whole phrase for us was “Automate Everything, apart from the Human element.” So, this Tao means automating tedious tasks and allowing our customers more genuine Human contact. We had always intended for others to feel like we were just an extension of their org, an in-house team of experts in managing artifact management infrastructure for them.

So for us, the reality for critical infrastructure means:

Everything will break eventually; it’s just a matter of space and time, so we must prepare for it.

No perfect solutions will save you without effort; build for resilience responsibly.

Be the best possible partner for those you serve; own it and communicate effectively.

If your customers walk away from an outage, no matter how bad it is, and they can say, “They were honest, they worked the problem, they kept us informed, they got us running, and they’re going to ensure it doesn’t happen again, if possible.” You did your job, and you’ve built a solid partnership. If they walk away unhappily saying, “They said AWS had an issue,” then you possibly didn’t. One evergreen quote that I love related to this is a classic from Charity Majors: “Nines don’t matter if users aren’t happy.”

The 3Rs boil down to a simple philosophy that we tell 

You play a crucial role in the supply chain.

You don’t get to shout at your vendors.

But when you take responsibility, build resilience, and accept the reality of your job, it’s beautiful.

There’s no better feeling than delivering the promises of good service. The primary objective is to implement those 3Rs with an architecture that aligns with an excellent product that others rely on. That’s what people pay for.

The 3Rs of Critical Infrastructure: Responsibility, Resilience, and Reality

We often advise our customers to consider a “Hybrid” repository structure, which incorporates both the development environment (dev, staging, prod) and the specific team/application/service for artifact repositories in Cloudsmith. This is essentially just adding another layer to the team/application/service specific repository structure that provides better visibility and traceability of different environments. 

It might help to visualize the hybrid approach (we’ll discuss what we mean by “automated promotion” below).

Why Choose a Hybrid Repository Structure?

You might consider a hybrid repository structure if you find that a purely environment-based or purely team-based model leaves gaps in your workflow. For example, if your artifact repositories are currently team-based (set up solely by teams/services/applications), it can be difficult to put the right artifact promotion workflows in place without leveraging very strict artifact tagging practices. It also makes it harder to view artifacts across your various development stages. On the other hand, if you use an environment-based model group by development environment) without clear distinctions between teams/services/applications, you might run into visibility and traceability issues across artifacts.

We often see Cloudsmith customers that have outgrown single-model repository setups and are beginning to feel growing pains. As your organization grows, so does the demand for more efficient software development practices. The “simpler” repository model runs the risk of ultimately creating confusion, duplication, and lack of accountability. The hybrid approach contains that complexity in a clear and concise way that aligns with your development environments and organizational structure.

When To Choose a Hybrid Repository Structure?

Different compliance requirements across applications and environments is often a trigger for moving to a hybrid repository structure. For example, if your production environment for your government-facing application needs stricter security controls than your development environment for an internal application, a hybrid approach lets you apply different vulnerability policies to each.

Another reason to choose a hybrid structure is when you start getting into different product lines, diverse tech stacks, or growing sets of microservices. If you need to ensure that each product or service can move through specific stages of development independently, the hybrid approach makes that possible without sacrificing consistency.

It also rewards organizations that value observability. For instance, there may be times where you may need to investigate rogue image downloads from specific client requests within your staging environment that are causing a spike in package delivery demand. Or consider what happens when a pipeline has ingested a malicious package and you need to trace back to the originating repository. If the hybrid approach is adopted correctly, both of these situations can be addressed a lot more easily and quickly by security and observability teams.

At Cloudsmith, we partner closely with SRE’s and infosec teams early in the onboarding process to ensure our customers are well equipped to handle these situations.

One of the more popular topics we discuss during customer onboardings is the practice of artifact promotion across repositories. Package promotion workflows can be the place where artifact management breaks down in less structured setups.
In the hybrid model, environment based repositories act as quality gates that artifacts must pass through before reaching production. This ensures that only vetted, tested, and approved artifacts move forward, reducing the risk of instability, untested code, or vulnerable code being deployed into customer-facing applications. Development teams can still own and manage their artifacts independently, while the environment boundaries guarantee a consistent, auditable path throughout the artifact lifecycle.

The other significant benefits of the hybrid approach are visibility and governance. With a purely environment-based structure, it can be difficult to quickly identify who “owns” a package or service, while a purely service-based approach risks muddying the waters when promoting artifacts across environments.
The hybrid approach solves this tension but allows teams to retain clear ownership of their artifacts, while environment-based repositories enforce quality “gates” as well as access controls as packages move from development to staging, to production.

A hybrid repository structure strikes the balance between order and flexibility. By combining environment-based repositories (development, staging, and production) with service, application, or team-specific segmentation, organizations gain more control over how software flows through their pipelines without losing sight of ownership or accountability.
This approach creates clear boundaries between environments while still aligning repositories with the way development teams actually build and ship software.

How to Implement the Ideal Hybrid Repository Structure?

There isn’t a “one-size-fits-all” approach to implement a hybrid repository structure, but there are a few patterns that work especially well depending on how your organization is structured. One common approach is to segment by team and environment. For example, you might have repositories like frontend-dev, frontend-staging, and frontend-prod, alongside backend-dev, backend-staging, and backend-prod. This approach works well when you have dedicated frontend and backend teams who need clear ownership of their artifacts, while environment-based repositories provide the quality gates required to promote code safely through your organization’s environments.

Another variation is to organize by product/service and environment, such as payments-dev, payments-staging, and payments-prod for services. This model is particularly effective for organizations running microservices or multiple customer-facing products. Each service has a self-contained promotion pipeline making it easier to test, release and troubleshoot independently without impacting other teams. Larger organizations sometimes prefer a department or function-based hybrid model, where repositories are grouped for example by mobile-dev, mobile-staging, mobile-prod for a mobile app focused engineering team, while a data focused team might have their own set of similar repositories. Again, this keeps things scalable and avoids proliferation of repositories, while still ensuring environment-based control.

Finally, a useful approach includes a shared dependency repository alongside service and environment repositories. For example, you might have a shared-libs repository where internal SDKs, libraries, and external dependencies might live to be used across multiple services or applications. The Cloudsmith customer success team often recommends enterprise customers adopt this approach for both deduplication of dependencies as well as ensuring there is a dedicated “ingress” repository that acts as a security gate for proxied dependencies. This avoids having multiple “development” repositories having multiple upstream configurations and helps greatly with auditability.

Companies with just a few major products often do best with a product + environment structure, while those running many microservices benefit from a service + environment structure. Smaller, more agile teams might lean towards a team + environment approach to meet their specific needs. In most enterprise environments, it’s actually common to mix multiple hybrid patterns within a single artifact registry. Your teams might use all 3 of the above approaches depending on specific workflow requirements. We call this “multi-pattern hybrid repository structure”.

For each of the above hybrid structures, our customers have the ability to automate the creation of these repositories on behalf of their development teams using our REST API and Terraform provider, with some customers even creating golden paths or secure self-service workflows to enable development speed and freedom. Overall, the key to getting the hybrid approach just right for your organization is to align your repositories with how your development teams are organized as well as how your CI/CD pipelines actually operate.

Cloudsmith’s Support for Hybrid Repository Structures

Cloudsmith is the modern way to store and distribute your software at scale, securely. With Cloudsmith’s multi-format support and build-in scale, we are able to meet the needs of the largest enterprises building and distributing software today. Gone are the days of language formats bound to repositories and limits on how many repositories you can create.

With Cloudsmith, your developers are able to spin up new globally distributed repositories with just a few clicks or commands to meet their needs. All of this comes out of the box with Cloudsmith. The Cloudsmith Customer Success team is here to help you navigate repository configurations, especially the hybrid approach given the amount of customers we have benefitting from this approach.

If you haven’t already, check out our previous post, 

, where we break down the foundational principles behind effective repository organization and how the right structure can shape your software delivery success.

The Hybrid Repository Structure: Balancing Control and Flexibility

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

Cloudsmith Blog

The DevOps Guide to Mitigating Software Supply Chain Risks

Kubernetes 1.35 – What you need to know

Securing the intersection of AI models and software supply chains

Shai-Hulud: The Second Coming - What You Need to Know and Do Now

Artifact distribution: Securing the trust with your own domain

Breaking the "Department of No": Ship fast but also secure

Securing the intersection of AI models and software supply chains

The true cost of legacy artifact management

AI generated code is changing the demands being put on artifact management

13 sessions not to miss at KubeCon and CloudNativeCon 2025

The 3Rs of Critical Infrastructure: Responsibility, Resilience, and Reality

The Hybrid Repository Structure: Balancing Control and Flexibility

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