For most developers, the traditional security pipeline is a source of friction, not a tool for enablement. You push a new feature, the CI build kicks off, and suddenly you're facing a wall of 1,200 critical CVEs from a transitive dependency you didn't even know you had. The release is blocked, and the security team becomes the "Department of No" - a metaphorical bottleneck that seems to exist solely to slow down velocity. This dynamic is broken. The goal isn't to have 

 security; it's to have smarter security that enables speed; that requires moving from noisy alerts to prioritised, actionable risk.

" culture is a direct result of missing context. When a security team sees a thousand CVEs, they have to assume all are critical. Without clear software provenance, every new dependency is a potential "

" - an unaudited package that could be anything from a benign tool to a typosquatted nightmare. An SBOM (Software Bill of Materials) provides the "what," but it doesn't provide the "so what?" This is why developers get buried in alerts for vulnerabilities that aren't even reachable in their code. To fix this, you need a system that doesn't just find problems, but also provides the context to 

This is where the pipeline needs to get smarter, starting at the build. A tool like 

 integrates directly into your CI pipeline to provide this missing context 

 an artifact is ever created. Its job isn't just to find every CVE; it's to intelligently triage them. By performing context-aware analysis, it determines if a vulnerability is 

 within your application's call path. This is the practical power of 

 (Vulnerability Exploitability eXchange) reporting. That jaw-dropping list of 1,200 CVEs becomes a manageable, actionable list of something like 

 that can genuinely pose a threat. Kusari acts as the guardian of the build, generating a tamper-proof evidence packet containing a signed SBOM, a VEX report, and a provenance attestation, ensuring you only build what you trust.

Once Kusari verifies a build and signs its evidence packet, the artifact can be pushed to the Cloudsmith artifact repository. Cloudsmith isn't simply a passive vault, it also serves as an intelligent admission control layer via Enterprise Policy Management (

 offering allows users to quarantine packages with a deep-level of context. This is where you set the rules: "Block any artifact with a non-compliant license from being pulled," or "Prevent any package with a critical-severity CVE from being deployed to production, if we know there’s a fix already available." It gives you the "last mile" of control, ensuring that only verified, secure, and compliant artifacts are distributed and consumed by developers and production systems.

This combination of Kusari and Cloudsmith creates a closed-loop security system that finally busts the "Department of No" myth. For developers, this means an end to the noise. You get fast, actionable feedback directly in your CI pipeline, allowing you to fix the five critical, reachable vulnerabilities instead of arguing about the 1,200 that aren't. For the organisation, it means security transforms from a reactive bottleneck into a proactive, automated discipline. You can trust that anything you pull from Cloudsmith is pre-vetted, and security teams have an end-to-end, auditable trail from source to deployment. This is how you stop fearing security and start automating it, enabling your team to ship with confidence and speed.

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

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

Artificial intelligence has moved beyond a futuristic concept to a daily collaborator for almost all development teams today. Tools like GitHub Copilot and ChatGPT are writing functions, suggesting dependencies, and building application skeletons at a blistering pace. This revolution in speed is undeniable, but it comes with a critical, often-overlooked consequence: AI-generated code is fundamentally changing the demands on artifact management.

We're moving faster than ever, but that speed has created massive blind spots in our software supply chain. The core question is no longer just "

Does AI check its sources and provide provenance checks?

Let's address the first fundamental question. When an LLM suggests a software package or a new dependency, does it perform 

" if a dependency is credible, accurate, or safe. It's not testing that package in a sandbox. It's making a statistically probable recommendation based on the data it was trained on.

This creates a terrifying new attack vector. The AI has no concept of:

, pulling in a malicious package. Oftentimes it depends on what you ask for, and sometimes you get exactly what you asked for - whether that’s a good package or not.

: AI can't scan a dependency for malware before recommending it. After the ‘s1ngularity’ and ‘

’ attacks on the NPM ecosystem, there is a heightened focus on understanding the contents of open-source packages that we consume from these upstreams.

: AI doesn't differentiate between a well-maintained library from a trusted foundation like the CNCF vs. an abandoned, vulnerable package from a random user that likely will not be actively maintained going forward.

If a developer accepts that suggestion, a compromised dependency is instantly pulled into the codebase, bypassing all traditional human vetting.

Typosquatting is a type of cybercrime where attackers register domain names, or in this case dependency names, that are common misspellings or slight variations of legitimate websites/packages/dependencies to trick users into visiting a malicious site or downloading a software dependency that ultimately contains malware. A perfect example is the 

 example we mentioned earlier. One extra letter and many users wouldn’t immediately recognise it as a typo. Let’s query PyPi to see the owner of both packages:

 (AKA bitprophet). Whereas, the typosquatted package name returns “

” for the owner. You’ll have probably noticed by now that this package no longer exists on PyPi as it was intentionally created to cause harm - and has since been removed. While that’s good for the community, there’s a chance that an organisation may have already cached that package locally. In those cases, the OSV.dev public API can be really useful to identify whether your cached dependencies were created as part of a typosquatting campaign:

So what’s all this got to do with generative AI? Well, GenAI is just as guilty of hallucinating and recommending package names that simply don’t exist. Adversaries pick up on the behaviour, and thus create more typosquatted upstream packages in the hope that “

” code generation recommends one of those typosquatted package names. This is commonly known as 

. To stay ahead of slopsquatting, modern artifact management are expected to have full provenance checks on all software artifacts to understand who created them, are they credible, and have they already been flagged as compromised according to the 

Malware, unlike vulnerabilities in software, is a dedicated piece of software that is specifically designed to disrupt, damage, or gain unauthorised access to a computer system. Traditional vulnerability scanners are looking for flaws in an application code that can be exploited. These are marked by CVEs (like 

). However, malware contained within compromised upstream packages will not show-up in those CVE reports. Instead, we can use the same OSV.dev public API to see if an open-source upstream package, such as 

After running this command, you see that the package is identified as containing malware, with a unique identifier - 

. Now you couldn’t be expected to run this manual action every time you want to check if a specific dependency and version contain malware, that would take all day. Thankfully, Cloudsmith integrates the 

 API directly within our product. So on package synchronisation, we will automatically scan for known Malware identifiers (ie: MAL-YEAR-ID) associated with the open-source software dependency. If there’s a match, we can quarantine this automatically through 

Most recently, a variant of PhantomRaven malware was found in 

, designed to steal GitHub Tokens from developers. If LLMs cannot quickly identify whether an upstream package is compromised or not, what stops these generative AI tools from suggesting compromised packages? As the prevalence of malware in upstream repositories increases, this simultaneously changes the demands being put on artifact management. Modern artifact management solutions need to be able to identify and prevent compromised open-source software packages from being used by developers.

AI models used for code generation are trained on vast, uncurated datasets of public repositories, learning statistical patterns rather than semantic quality. This training methodology makes them incapable of assessing 

. The model does not understand that a CNCF-hosted project undergoes rigorous security audits, has a dedicated maintenance team, and follows a clear governance model. To the AI, that project's code patterns may look statistically similar to an abandoned, single-maintainer package on GitHub that contains known CVEs or is a prime candidate for a typosquatting attack. This "

" means the AI's suggestions are based on pattern frequency, not on a risk assessment of the dependency being recommended.

This blind spot directly reflects the current software supply chain risk. An AI can confidently recommend a dependency that, while functionally correct for the prompt, introduces significant security debt. This is backed up in the data. Chainguard’s "

" found that 1 in 5 respondents said that their engineers are not allowed to use AI for some of the most time-intensive tasks, such as patching vulnerabilities, running tests, or conducting code reviews. These are the tasks where technical credibility is needed to make those final judgements.

Furthermore, AI models trained on these OSS software ecosystems will inevitably learn from and recommend historically compromised packages from those upstreams. This problem is recognised by security foundations like OWASP, whose "

" lists risks like "Insecure Output Handling" (LLM03) and "Training Data Poisoning" (LLM04), where the model's output or its training data can be leveraged to inject vulnerabilities directly into a developer's workflow.

Ultimately, the credibility of these outputs can be benchmarked against frameworks such as the 

. This project was built by open-source developers to help secure the critical projects the community depends on. It assesses open-source projects for security risks by running a series of automated checks. You can use it to proactively analyse the security posture of your own code and make better-informed decisions about acceptable risks. The tool also helps you evaluate other projects and dependencies, giving you a basis to work with LLMs on improvements before you integrate into your codebase.

Does this mean we should be discouraged from using AI-generated code?

The short answer is 'no,' but a cautious and deliberate approach is essential.

We view generative AI much like any other programmable interface. It excels at following instructions, which means the quality of the output is directly dependent on the quality of the input.

A developer who is skilled in their domain will understand how to instruct the AI to produce high-quality, relevant content, thereby accelerating their workflow. For example, knowing precisely which software packages and versions are appropriate for a production application prevents the AI from referencing and introducing compromised dependencies.

By providing specific context, such as example code, the application framework, established code styles, library usage, specific dependency versions, and error handling protocols, a developer can guide the AI. This ensures it follows established rules and helps produce code significantly faster than manual methods.

Regardless of popular sentiment, our view is that generative AI is not close to replacing human intelligence in software development. Its current, practical role is to speed up and facilitate the quality work humans do, ultimately increasing overall productivity.

This new power, however, requires a corresponding increase in diligence for software governance, provenance checks, and vulnerability scanning. Maintaining control over AI-generated code means knowing exactly what is running in the estate, who created it, and being confident whether it is safe or not. This is all achievable through a comprehensive artifact management platform. If you’d like to learn more about this, we have an 

 on the topic of slopsquatting in the age of GenAI.

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

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.

Cloudsmith Blog

Extend EPM policies to HuggingFace artifacts

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

Kubernetes 1.35 – What you need to know

Slopsquatting and Typosquatting: How to Detect AI-Hallucinated Malicious Packages

The DevOps Guide to Mitigating Software Supply Chain Risks

Artifact distribution: Securing the trust with your own domain

Extend EPM policies to HuggingFace artifacts

Securing the intersection of AI models and software supply chains

The true cost of legacy artifact management

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

13 sessions not to miss at KubeCon and CloudNativeCon 2025

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

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