By submitting this form, you agree to our 

Explores AI-driven development, rising supply chain attacks, and new regulatory requirements.

2026 Artifact Management Report

Figuring out a scalable way to secure AI continues to be a significant challenge for businesses everywhere. According to our 

 use AI to accelerate their software development cycles. We are building faster than ever, yet the infrastructure supporting this speed was largely designed for a pre-AI world.

As AI agents dictate the pace of production, they are also expanding software attack surfaces. Security practices that worked at human speed are buckling. At Cloudsmith, we see this as a two-sided challenge: securing the code AI writes (the output) and securing the models AI uses (the input).

Here is how the landscape is shifting and how a cloud-native approach to artifact management can provide the control necessary to future-proof your development.

AI agents prioritize functional results over security provenance. When an AI suggests a block of code, it can pull in new dependencies. When you factor in transitive dependencies, the situation gets even more complex. Our survey data shows that 

 feel very confident in the security of AI-generated code.

The problem: Manual validation is scaling poorly

 manually validating the dependencies introduced by AI. This “operational tax” chips away at the speed gains promised by AI adoption. Furthermore, AI is prone to hallucinating packages, suggesting names that don't exist, which attackers then register in public repositories to facilitate “

The solution: Automated quarantine and policy guardrails

Cloudsmith addresses this by acting as a sophisticated gatekeeper between your AI agents and the public internet.

 Instead of developers or AI agents pulling directly from public registries, everything flows through Cloudsmith.

 You can define rules (using OPA/Rego) that govern what you allow into your environment and what to block.

 Create policies that automatically quarantine packages that meet specific criteria. When an AI agent calls for a new, unknown package, you can inspect quarantined packages before they reach your development environment.

While AI generates code at scale, the models themselves don’t get the same scrutiny that regular binaries receive. Companies frequently store AI models in ad-hoc silos like local drives or unmanaged cloud buckets, detached from the standard software development life cycle.

Our findings show significant fragmentation in how companies handle AI models. Only 

 unify their model management with their standard artifact workflows. Meanwhile, 

 only perform basic integrity checks (like checksums), leaving them vulnerable to model tampering or malicious weight injections.

The solution: Models as first-class artifacts

To future-proof your AI initiatives, you must treat models exactly like other artifacts, like container images or npm packages.

 By using tools like Cosign within Cloudsmith, you can 

 your models. This ensures that the model running in production hasn't been tampered with and originated from your trusted pipeline.

 Cloudsmith scans the metadata and layers of these artifacts, ensuring that your “inputs” are as secure as your “outputs.”

Future-proofing: Building for machine scale

 isn't a temporary trend; it’s a fundamental change in how we build software. Traditional artifact managers – often on-prem and slow to update – cannot provide the visibility required for this new development velocity.

Cloudsmith helps you move from a reactive “trust then verify” posture to an automated, proactive “verify then trust” one. By centralizing code, containers, and AI models in a single, cloud-native platform, you gain the visibility needed to comply with international compliance standards and frameworks, like the EU’s Cyber Resilience Act, while giving your developers the freedom to move at machine speed.

Security should be the foundation for AI. By implementing automated quarantine workflows and a unified registry for models, you can reclaim the hours lost to manual validation and protect your organization from the unique risks of the AI era.

This post only scratches the surface of the shifts we’re seeing in the industry. Download the complete 

 to explore the full demographic breakdown, competitive findings, and our deep dive into the state of software supply chain security.

Jason Myers

Technical Content Marketer

The AI speed trap: Securing the future of software supply chains

The Hybrid Repository Structure: Balancing Control and Flexibility

And now, let’s dive into part three: How 

 keep your multi-format repositories secure, consistent, and developer-friendly.

In the first two blogs of this series, we explored why repository structure matters and how Cloudsmith’s Hybrid Repository Structure balances control with flexibility. While we touched on policies and permissions, we didn’t dive into the 

 mechanics of how access control ensures artifact security, traceability, and consistency, especially in 

, where different packages, languages, and tooling coexist in a single place.

While multi-format repositories allow for more flexibility in how your repositories are set up, they can introduce a new way of thinking about how and when different artifacts can be accessed and by whom. This blog breaks down how Cloudsmith provides fine-grained, flexible, and secure controls for teams of any size.

Cloudsmith provides the following user roles:

These roles help limit access based on organizational need and provide the foundation for more granular permissions.

You can explore the full breakdown of Cloudsmith roles, permissions, and privileges in our documentation.

You can read more about user roles, permissions, and privileges in Cloudsmith 

Every Cloudsmith customer is given the opportunity to set default global privileges. These global default privileges are set for the “Member” user role in Cloudsmith, which is often suited best for individual developers. Within a customer’s global workspace privileges, organizations can choose to grant members the ability to create new teams, invite new users, and even create new repositories. Organization owners can also grant “blanket” repository privileges to all users within Cloudsmith. 

While we offer the flexibility for organizations to shift responsibility and access to the developer, we often see our enterprise customers lean away from blanket permissions and access toward more fine-grained permissions. As an example, we have a semiconductor manufacturing customer that has disabled default workspace global privileges so that only Organisation owners are the only users who can invite new users, create new teams, invite 3rd-party collaborators, and create new repositories. 

In addition, this customer has access control, and privileges are scoped down to specific teams. Default global repository privileges are disabled so that they can choose exactly which team(s) should have access to repository(s). Even Cloudsmith service accounts are grouped together within a team for ease of tracking permissions and access when it comes to build and deployment times. 

If we zoom in once and look at the repository level in Cloudsmith, we can assign a default privilege for organization members for accessing packages within the repository, and we can assign specific privileges for specific teams, users, or service accounts.

This is the stage where you’ll have to consider what packages the repository is storing and if you want developers and service accounts to have default admin, read, or write permissions to the repository. Continuing to use my customer example, they have chosen to set default read permissions for all repositories; however, specific service accounts have write and 

 to different repositories. You may be okay with your developers downloading artifacts to their local machine for testing or even service accounts requesting stored artifacts tied to staging and production environments.

On the other hand, there are customers that may not want their developers having the ability to write to every repository and would most likely want specific service accounts tied to their CI/CD pipelines to only have write permissions. While this is generally best practice, there are certainly exceptions to this rule, as we also have platform teams that choose to grant specific developer teams write access to specific artifact repositories.

On top of the permission and access control settings we’ve discussed, Cloudsmith goes even further to ensure that, through various additional settings, platform teams can decide exactly what their developers need and don’t need to be reconfigured within a repository.

Platform teams are able to grant or deny developer permissions, such as:

Copying Packages From One Repository to Another

Moving Packages From One Repository to Another

Managing, Using, Or Viewing Entitlement Tokens

If you thought that wasn’t enough, Cloudsmith takes it a step further by scoping down permissions to the individual developer’s generated packages. So while platform teams can restrict tampering of artifacts generated by other developers or systems, they can also decide if they would like to allow developers the ability to scan, move, copy, delete, or resync their own packages.

Most of the enterprise customers I work with allow developers to do as they please with their own packages to avoid a developer mutiny! In either case, these user actions are catalogued in our 

 for enhanced observability across your Cloudsmith environment.

For instances where our customers want to be very particular about what, how, and when users can access specific packages, Cloudsmith offers 

. These scoped tokens are read-access only, so there is never a risk of a user performing a write action against the repository they have limited access to.

Customers are able to restrict access by creating a precise search query to narrow down specific packages within a repository, should they choose not to provide visibility into all the packages within the repository. On top of visibility restrictions, customers can also add token usage restrictions to avoid prolonged access and usage of the token. Parameters include:

Typically, we see our customers use entitlements for 3rd party software distribution or even for systems that don’t require logins to Cloudsmith.

For our security-conscious customers, Cloudsmith also offers the ability to configure 

 based on country, with an easy-to-use preconfigured list of countries to choose from. Choose to deny or allow access from specific countries. Although keep in mind that theoretically, no unauthenticated user should have access to your Cloudsmith workspace in general. This restriction applies more towards open-source repositories that you may be hosting in Cloudsmith, but it’s always a good idea to practice defence-in-depth!

If geo-based restrictions are too broad, you can scope down to IP-based restrictions to either allow or deny client access based on IP address. This added protection ensures that requests coming from clients with an unapproved IP address do not have access to your repositories. 

With all of these configuration options, it can be tricky to decide how you want to best enable your developers while balancing security and flexibility. Not to worry—the Cloudsmith Customer Success team is here to help you in your decisions throughout the onboarding process. We’ve walked through these decisions with many customers and have outlined decision impacts for you so you’re not left wondering “what if”. Learn more about Cloudsmith 

 to get started with us. See you on the other side! 

1. What is access control in a multi-format repository?

Access control defines who can read, write, or administer artifacts across different package formats stored in the same repository. It ensures secure, consistent governance across diverse tooling.

2. How do permissions work in Cloudsmith for multi-format repositories?

Cloudsmith supports global, repository-level, team-based, and user-specific permissions, allowing organizations to tailor access to packages, teams, service accounts, and even individual artifact actions.

3. Why is fine-grained access control important in software supply chain security?

Fine-grained controls reduce the blast radius of errors, prevent unauthorized writes, and help organizations enforce policies required by modern software supply chain frameworks like SLSA and SSDF.

4. What are entitlement tokens used for in Cloudsmith?

Entitlement tokens provide scoped, read-only access to specific artifacts without requiring user accounts, making them ideal for external distribution, automation, or least-privilege workflows.

5. Can developers manage their own packages in Cloudsmith?

Yes. Cloudsmith allows permissions that let developers manage only the packages they personally created—without putting others’ artifacts at risk.

6. How does Cloudsmith support secure CI/CD pipeline access?

Service accounts can be granted precisely the permissions needed for pipeline operations (like write or admin) while keeping developers and collaborators restricted to read-only or scoped access.

7. What’s the difference between global and repository-level privileges?

Global privileges affect the entire workspace, while repository-level privileges enable granular control over specific teams, users, or service accounts interacting with a particular repository.

Cristian Garcia

Senior Customer Success Manager

Repository Structure

Access control & permissions for multi-format repositories

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.

 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

Nigel Douglas

Head of Developer Relations

Python 3.14 – What you need to know 

In the world of artifact management, a repository structure refers to how software artifacts—such as Docker images, Python packages, npm modules, and more—are organized, stored, and accessed. It defines how repositories are named, grouped, and managed, often aligning with how software development teams build, release, and consume software binaries across an organization.

Repository structure is a fundamental foundation of secure, efficient artifact management practices. Your goal is to create the right structure that meets the needs of your developers.

Cloudsmith has an intrinsically flexible approach to repositories. We don’t force you to have a separate repository for each format type, like most other artifact management systems do. This presents you with an opportunity to define a more meaningful structure for your repositories, and this means you have many more interesting options!

We see some common patterns among Cloudsmith users that fall into the following groups:

We’ll be covering each structure in greater detail in our upcoming blogs as part of our Repository Structure Best Practices series.

Now that we’ve identified the “what” behind repository structures, we can dig into the “why” a little bit.

We address repository structure at the beginning of our onboarding process for new customers. If you get the repo structure wrong, then over time, artifact repositories can become a ‘dumping ground’ for all manner of software artifacts. When platform engineering teams are migrating to Cloudsmith, we find that there’s often a newfound interest in organization and consolidation of software artifacts, in order to ‘do better next time’ than they were able to with their legacy solution.

Perhaps the number one question we get at this point is, “How do we balance software supply chain security best practices with a great developer experience?”

While there isn’t really one simple answer to this question, the good news is that the flexibility Cloudsmith offers in choosing the repository structure can help you to check both boxes – security AND productivity.

Key benefits of the right repository structure

Choosing a clear, intuitive structure removes significant friction for developers. If they are able to easily locate the packages they need, pull the open-source dependencies for their builds in a central location, and integrate quickly with CI/CD pipelines, you’re winning as a platform team already.

Many enterprise customers of Cloudsmith leverage a dedicated repository for all ingress packages, where open-source dependencies are proxied and cached for developers and pipelines to begin accessing. This centralized repository makes it easy for developers to remember the direct path URL for pulling on their local machines and even easier for updating their CI/CD pipelines.

With our API and UI, a developer can quickly review what packages are within a specific repository. No digging through countless folders and subfolders to find what you’re looking for!

You’ll want your developers to be able to pull dependencies, create repositories, and configure upstream sources easily. But you also want to ensure developers are working securely. Repository structure directly influences how platform teams will be able to configure repository access controls, set permissions, review vulnerabilities, and inspect audit trails for suspicious signals.

In Cloudsmith, platform teams can restrict repository access by designating only specific developer teams to have access to specific repositories. At the permissions level, you can set read/write/admin permissions for each repository. This allows for granular access control, self-serve ownership, multiformat flexibility, and better visibility into team-by-team usage.

Observability and auditability of packages within your artifact management environment are directly correlated to how fine-grained your repositories are structured. The more segmented you configure them (i.e., by specific team, application, or environment), the clearer an observability team is able to view when a package was pulled and by whom. On the contrary, if an organization just has “non-prod” and “prod” repositories with many different service accounts and users pulling packages, it might be more difficult to pin down a specific action or event.

The right repository structure really impacts an organization’s CI/CD pipelines. When pipelines are tightly coupled to poorly structured repositories, the result can be pipeline failures due to ambiguous package resolution, security risks from pulling artifacts from the wrong stage, and even increased build times due to inefficiencies in caching.

As your organization grows, what originally worked for your first few developers will often break at scale. Without a flexible, scalable repository structure, you will quickly become susceptible to artifact sprawl, naming collisions, and access control issues. Cloudsmith’s fully cloud-native architecture helps enterprise customers scale tremendously while also maintaining order and consistency across repositories.

Cloudsmith Blog

The AI speed trap: Securing the future of software supply chains

Access control & permissions for multi-format repositories

The Hybrid Repository Structure: Balancing Control and Flexibility

Python 3.14 – What you need to know

Why Repository Structure Matters

Compliance policies in EPM

Golden Paths Made Easy With Cloudsmith