By submitting this form, you agree to our 

Healthy competition makes industries stronger, products better, and benefits customers. JFrog has recently published two blog posts (

) criticizing our platform, a clear sign that Cloudsmith’s approach - built cloud-native, open, transparent, and customer-focused - is winning over customers.

JFrog’s own CEO has framed Cloudsmith as just “

fluffy marketing spin and empty presale promises.

” We disagree strongly. Our platform is proven in production every day, powering software delivery for some of the world’s most demanding organizations. Enterprise customers 

use Cloudsmith to build, secure and deliver software at scale

. And we are open about our capabilities for anyone to evaluate firsthand, through a 

 that shows exactly what it’s like to work with Cloudsmith.

JFrog’s latest tests seem intentionally designed to mislead. Rather than respond point by point, we invite customers to conduct their own comparisons. We welcome head-to-head evaluations because this is where our truly cloud-native, massive-scale architecture really shines. We believe our vision for the software supply chain serves customers best today and into the future. We’ve faced off against JFrog in a number of competitive situations recently, and we’ve won more than we’ve lost. It’s the spirit of healthy competition that has prompted all of this recent attention from JFrog. We welcome it.

JFrog has been able to test our platform because we let them trial Cloudsmith, too. The same cannot be said about JFrog, since they block our domain (and possibly others) from even signing up. This lack of openness ultimately hurts customers; many large organizations have multiple artifact management systems in place, and access to both systems would let us better support customers’ interoperability requirements.

Openness and transparency are core to who we are

: “Hide nothing, then there is nothing to hide.”

Openness and honesty, both in how we operate our business and how we communicate, are essential for building trust with customers and also how we work together as Cloudsmithers. Transparency is second nature for Cloudsmith; it’s how we make decisions, share information, and hold ourselves accountable.

We avoid that “lies, damned lies, and statistics” feeling when sharing information. We focus on facts, context, and clarity.

That’s why anyone can sign up for a Cloudsmith developer account - yes, even if you’re from JFrog - and experience our platform firsthand; no gatekeeping, no NDA. It’s why we share platform status and service issues, no matter how minor; it’s more important to share the small stuff than to stick to a claim of “flawless 100% uptime.”

Transparency isn’t just fluffy marketing - it’s how we operate, every day.

We believe in Community and Open Ecosystems

Security of the software supply chain depends on collaboration. From open standards to public registries, collaboration is how enterprises actually build software securely and at scale. We support open ecosystems because they accelerate innovation and benefit everyone.

Closed platforms and walled gardens are tempting to legacy software vendors like JFrog, but they inevitably lead to lock‑in and slow progress. Our approach is different: Cloudsmith is designed to integrate, not isolate. We recognize that we are the trusted control plane and data plane for software artifacts. To do that effectively means working alongside the tools and ecosystems our customers already rely on, rather than forcing a single‑vendor stack.

Competition pushes every company to deliver more value to customers. We welcome direct competition with JFrog because it helps us to improve our platform and our customer experience.

Artifact management is critical infrastructure. Software teams depend on us to build, secure, and deliver their products. Choosing an artifact management platform is a decision about who you trust, and who you want to work with for the next 5-10 years and beyond.

Cloudsmith’s growth has been built on long‑term partnerships. We understand our customers’ needs, deliver meaningful improvements, and act as a trusted partner as requirements evolve. That’s what real competition is about: 

Alison Sickelka

VP of Product

Competition, transparency and building the future of the Software Supply Chain

 is right around the corner, and there are quite a lot of changes to unpack! Removing enhancements with the status of “Deferred” or “Removed from Milestone” we have 59 Enhancements in all listed within the 

Kubernetes 1.34 brings a whole bunch of useful enhancements, including 45 changes tracked as ‘

’ in this Kubernetes release. From these, 

 are graduating to stable, including support for Direct Service Return (

) and overlay networking in Windows kube-proxy.

 features are also listed in the enhancements tracker, including a built-in capability for pods to authenticate to kube-apiserver using mTLS. This is especially cool as it's built from pieces that are easy for external projects to reuse to deliver additional functionality using X.509 certificates. Amongst other new benefits, DevOps teams will benefit from new container restart rules. These rules declare the container-specific logic that can be used to customise the restart behaviour of the container when it exited or crashed.

If you don’t have time to read the entire release report right now, Gerome Grignon provides an easy to consume, status overview of each feature release from 1.19 through to 1.34 - 

. The Cloudsmith team is really excited about this release and everything that comes with it! Let’s jump into all of the major features and changes in Kubernetes 1.34.

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

“From a personal perspective, I find the introduction of CEL-based mutating admission policies in Kubernetes 1.34 incredibly exciting because it brings clarity and simplicity to an area that’s historically been complex and operationally heavy. For those dealing with the overhead of managing external mutating webhooks (whether for debugging latency issues, ensuring HA, and handling failure edge cases) this feels like a major leap forward. Being able to express common mutations declaratively using CEL, directly within the API server, eliminates an entire layer of moving parts while still retaining flexibility. It also aligns beautifully with the Kubernetes philosophy of declarative configuration, and I’m particularly excited about how this could streamline GitOps workflows and simplify secure, consistent policy enforcement across environments.”

Nigel Douglas - Head of Developer Relations

#4427 Relaxed DNS search string validation

“I'm really happy to see this KEP graduate to stable in Kubernetes 1.34 because it finally addresses a long-standing pain point when dealing with legacy or standards-bending DNS setups. In the past, trying to use valid-but-practically-common patterns like underscores or a single dot in dnsConfig.searches meant hitting a frustrating wall with 

 validation. This often forced awkward workarounds or even blocked legacy workloads from being migrated into Kubernetes entirely. With this KEP now stable, Kubernetes is acknowledging real-world usage patterns while still maintaining safe, opt-in behaviour.

From a practical standpoint, it's empowering for me to be able to configure a pod with dnsConfig.searches like abc_d.example.com without having to fight the platform. These are small changes, but they remove major friction, especially when you're dealing with SRV records or short-name resolution in systems not designed with strict DNS compliance in mind. The design is also thoughtful: it's gated, it respects compatibility boundaries, and it won't break clusters on upgrade or downgrade. To me, this shows Kubernetes is maturing in a way that balances standards compliance with usability, and that's worth celebrating.”

Esteban Garcia - Principal Software Engineer

#4639 VolumeSource: OCI Artifact and/or Image

“This is a game-changer. Allowing OCI images to be mounted as volumes is incredibly exciting for us. It means our customers can now leverage their existing OCI registries to seamlessly distribute ML models, configurations, and binaries directly to their pods. This move greatly simplifies artifact management, streamlines MLOps and CI/CD pipelines, and enhances security. All of it while using familiar, standard tooling. I can’t wait to document some new examples about this.”

Pablo Javier López Zaldívar - Technical Writer

Allow recreation of pods once fully terminated in job controller

 require dedicated pods per index, but issues arise when these pods are prematurely terminated due to factors like preemption or eviction. Currently, replacement pods are created immediately, which often results in failure to start - especially in clusters with limited resources or strict budgets. This premature creation can delay scheduling, as resources may not be available until the terminating pod has fully exited. Additionally, if cluster autoscaling is enabled, these early replacements may trigger unnecessary scale-ups.

To address this, the proposed change introduces more control and visibility into pod replacement behaviour for Kubernetes Jobs. The Job controller will now differentiate between active, failed, and terminating pods. A new 

 field will track the number of terminating pods, and an optional spec field will allow users to configure whether replacement pods should wait for termination to complete. This information can also support queueing controllers like Kueue in better quota calculation. The goal is to offer more flexible and efficient scheduling without affecting other workload APIs.

This enhancement introduces support for a 

. Currently, StatefulSets update their pods one at a time, which can be slow and inefficient for certain workloads. By allowing multiple pods to be updated simultaneously (up to the specified 

 value). This change enables faster and more flexible rolling updates for stateful applications.

The motivation stems from several real-world scenarios. For instance, StatefulSets preserve pod identities, making them ideal for applications that publish consistent metrics or rely on fixed pod names - something not possible with Deployments. Additionally, applications that perform lengthy startup tasks or can tolerate multiple replicas going down (e.g., follower nodes in a distributed system) would benefit from the faster updates enabled by 

 for tracking updates, offering simpler and more predictable revision management compared to Deployments. The proposal aims to make StatefulSets more feature-rich and deployment-friendly, while retaining their core identity-preserving capabilities.

Deployments in Kubernetes currently show inconsistent behaviour when dealing with terminating pods, depending on the rollout strategy or scaling activity. In some cases, it might be more efficient to wait for pods to fully terminate before creating new ones, while in others, launching new pods immediately is preferable. To address this inconsistency, a new field, 

, is proposed to give users control over when replacement pods should be created during deployment updates.

The goal is to let users define whether a Deployment should wait for pods to terminate before spinning up new ones or proceed without delay, all while respecting the chosen deployment strategy. Additionally, the status of Deployments and ReplicaSets would be enhanced to reflect the number of managed terminating pods. This distinction is important, as pods marked for deletion (with a 

 field. This can lead to temporary over-provisioning - especially during rollouts or unexpected deletions like evictions - causing resource strain, potential scheduling issues, and even unnecessary autoscaling, which may increase cloud costs in large-scale or tightly resourced environments.


This proposal outlines a plan to enhance Kubernetes scalability and performance by enabling consistent reads directly from the watch cache instead of querying etcd. The core idea is to ensure that cached data is up-to-date by leveraging etcd's progress events, which indicate the latest revision observed and guarantee that all future events will be newer. This mechanism allows Kubernetes to verify how fresh the watch cache is and safely serve consistent (

) reads from it, without needing to go back to etcd each time.

The motivation behind this change is significant: serving reads from the cache is far more efficient than querying etcd, filtering, deserialising, and garbage-collecting large numbers of objects. This is particularly impactful for node-originated requests, such as kubelets listing pods scheduled on their nodes. Instead of listing and filtering hundreds of thousands of pods from etcd, the cache can immediately return just the relevant data. Beyond performance, this also resolves the long-standing “

” issue, where reflectors could receive outdated data on startup due to defaulting to non-consistent reads.

The implementation plan includes using a consistent read to get the latest resource version, waiting for the watch cache to reach that revision (with repeated 

 calls every 100ms if necessary), and then serving the request once the cache is fresh enough. This approach introduces little to no extra scalability cost and enables Kubernetes to maintain correctness while improving efficiency - particularly in large-scale clusters.

 as a simpler, declarative alternative to 

 in Kubernetes. Many common mutation scenarios (such as adding labels or injecting containers) can now be expressed using concise 

 (Common Expression Language) expressions, significantly reducing operational complexity.

This method eliminates the need for running and managing external webhooks and provides better introspection and performance. Because these policies run in-process within the Kubernetes API server, they avoid the latency and reliability issues associated with webhooks and support automatic re-invocation when needed.

, depending on the desired semantics and compatibility needs. The structured merge strategy is preferred for its declarative nature and integration with 

A key feature is the use of CEL expressions to dynamically construct the partial object to be merged into the original request. For example, injecting a sidecar initContainer can be done using the following 

This enhancement provides a Kubernetes-native way to express and apply mutations with clarity, speed, and declarative consistency - without sacrificing flexibility. It also paves the way for policy frameworks to be built around in-tree mechanisms and reused across systems like GitOps or CI/CD, all without relying on external webhook infrastructure.

This proposal introduces a new approach to handling leader election transitions for key Kubernetes components (

) by allowing them to gracefully release their leadership lock and revert to a follower state without restarting the entire process. Currently, when a component loses leadership, it forcefully exits using 

, requiring the kubelet to restart it. This results in unnecessary overhead and prevents clean shutdowns. The proposed change, gated behind a new feature flag (

), aims to improve high-availability (HA) behaviour by enabling components to stop their internal controllers, release resources, and then attempt to reacquire the lease - all without exiting.

To implement this, the components' control loops will be updated to support proper context cancellation and cleanup when leadership is lost. Key technical changes include modifying the 

 callback, enhancing health check de-registration, and deferring or resetting resources upon leadership loss. While this offers clear benefits in reduced latency and better lifecycle handling, there are associated risks - such as memory leaks, failure to respect shutdown signals, and regressions from future code changes. These risks are mitigated through audits, new tests, best practice documentation, and conditional gating of shutdown logic.

This enhancement proposal introduces KYAML, a new output format for kubectl (invoked via 

 is a strict subset (or dialect) of YAML designed to be compatible with existing YAML tooling while avoiding many of YAML’s most common pitfalls. It emphasises syntactical rules that prevent ambiguous behaviour, such as always quoting strings to avoid unintentional type coercion (for example "

" being interpreted as a boolean), using explicit flow-style syntax (

 for maps), and eliminating reliance on whitespace sensitivity. These design choices make KYAML easier to read, write, patch, and template, particularly beneficial in tools like Helm.

The KEP also proposes making KYAML the standard format for all Kubernetes project-owned documentation and examples. The motivation stems from YAML’s complexity and its tendency to produce valid but incorrectly interpreted files due to issues like indentation or ambiguous values. While JSON is an alternative, it lacks comments and is less human-friendly. KYAML aims to blend the safety and clarity of JSON with YAML’s readability and flexibility. By updating examples and tooling to use KYAML, the project hopes to guide the ecosystem toward more reliable and error-resistant configuration practices.

 Implement a .kuberc file to separate user preferences from cluster configs

 phase, this feature will be enabled through the 

. Users can override this location using the 

). The kuberc file will serve as an optional configuration to separate user preferences from cluster credentials and server configurations. This proposal aims to introduce a new file dedicated to user preferences, which will offer better flexibility compared to 

, which currently under-utilises its preferences field due to the creation of new files for each cluster that mix credentials with preferences.

The kuberc file will provide a clear separation between server configurations and user preferences, allowing users to define command aliases, default flags, and other customisations. The file will be versioned to support easy future updates, and users will be able to maintain a single preferences file, regardless of the 

 environment variable. This proposal also suggests deprecating the kubeconfig preferences field to streamline configuration management. The kuberc file will be entirely optional, providing users with an opt-in way for custom kubectl behaviour without impacting any existing setups.

Nigel Douglas

Head of Developer Relations

Kubernetes 1.34 – What you need to know

In modern software development, managing the growing number of build outputs—packages, containers, binaries, and more—can quickly become chaotic without the right systems in place. That’s where artifact management comes in.

This guide dives deep into what software artifacts are, why managing them matters, and how adopting a cloud-native artifact management platform can streamline your CI/CD workflows, enhance security, and future-proof your software supply chain.

Software artifacts are the by-products and outputs of the software development process—think packages, containers, binaries, metadata, and configuration files. They represent the building blocks of deployable applications.These artifacts are the actual deliverables of your software. They represent what will be deployed to staging, production, or shared across teams and services. Managing these artifacts properly is essential for ensuring consistency, traceability, and reproducibility in modern software systems.

Artifact management is the process of storing, organizing, versioning, and distributing software artifacts across the entire development and deployment lifecycle. A reliable artifact management platform acts as a central source of truth, allowing teams to trace, audit, and access every component involved in delivering software.

, development teams often resort to ad hoc methods—storing build outputs in cloud drives, sharing binaries via email or chat, or duplicating packages. These workarounds are error-prone, insecure, and non-compliant with modern software delivery practices.

The lack of centralized control can lead to:

 tracking down the correct artifact versions

The solution lies in implementing a centralized software artifact repository—one that supports multiple formats, integrates into CI/CD workflows, and enforces security controls such as access management and vulnerability scanning.

Learn more about Universal Artifact Management

Why artifact management matters for your software lifecycle?

Artifact management isn’t just about storage. It plays a strategic role across all phases of your development lifecycle, including:

Track artifact provenance, enforce access control and comply with industry standards to ensure secure artifact usage throughout your pipeline.

Speed up pipelines by caching and reusing immutable, versioned artifacts. This reduces failures, accelerates workflows, and simplifies rollback strategies.

Deliver artifacts worldwide through edge caching and geographic replication, reducing latency and improving collaboration in distributed environments.

A modern artifact repository integrates with CI/CD tools such as Jenkins, GitLab CI, GitHub Actions, CircleCI, and others, ensuring seamless automation.

A modern, cloud-native approach to artifact management

Artifact management comes in various forms depending on infrastructure, scale, and organizational maturity. Broadly, these types include:

Local Storage or Manual Artifact Handling

: Artifacts are stored in shared folders or drives or manually passed between teams. This approach lacks traceability, security, and version control.

: These are installed and maintained within the organization's infrastructure. While they offer control and compliance, they often struggle with scalability, require significant operational overhead, and can become bottlenecks in distributed teams.

: Traditional tools hosted in the cloud. While they relieve some maintenance burdens, they may lack modern scalability and integration features needed for fast-moving DevOps pipelines.

: Built specifically for the cloud, these platforms are designed with elasticity, global distribution, and high availability from the ground up. Cloud-native solutions leverage modern architecture to integrate tightly with CI/CD workflows, offer edge caching, and minimize operational complexity.

 software development calls for a transformation in how artifacts are managed. Traditional on-prem artifact repositories can be difficult to scale, prone to outages, and challenging to maintain.

 are built to scale elastically, provide instant global distribution, and operate with minimal overhead. They are resilient, highly available, and come equipped with features that align with the needs of modern software teams.

Key benefits of a cloud-native artifact repository

Choosing a cloud-native artifact management solution offers clear advantages that traditional on-premise or self-hosted artifact repositories struggle to match. A cloud-native software artifact repository is designed for modern DevOps workflows and continuous delivery pipelines.

: Cloud-native artifact management platforms automatically scale storage and performance as your software artifacts and teams grow. There’s no need to provision hardware or manually plan capacity.

: With a multi-region, fault-tolerant architecture, cloud-native artifact repositories ensure your critical software artifacts are always accessible, helping reduce downtime and business risk.

: Cloud-native solutions use edge caching to distribute artifacts closer to where your teams, customers, and CI/CD systems are, ensuring faster access and minimal latency worldwide.

: The cloud-native model removes the burden of managing servers, applying patches, or handling upgrades. Your teams can focus on building and delivering software rather than maintaining infrastructure.

: Cloud-native artifact repositories often include built-in vulnerability scanning, SBOM support, and access controls, helping secure your software supply chain at every stage.

Key features of an effective cloud-native artifact management platform

 Reduce latency with distributed edge nodes.

 Manage who sees and touches what, down to the package level.

 Guarantee reproducible builds and safe rollbacks.

 Continually scan and block known vulnerabilities before artifacts enter production.

 Native support for GitHub Actions, Jenkins, GitLab, and more.

 Generate and manage Software Bill of Materials (SBOMs) for better supply chain insight.

 Aggregate and manage all package formats in one centralized location.

How artifact management enhances software supply chain security

Modern software supply chains are under constant threat—from dependency confusion to malicious injections. Without proper visibility into your artifacts, you’re flying blind.

Artifact management plays a vital role in defending against these threats:

 Know exactly when and where an artifact was created and by whom.

Ensure that artifacts can’t be altered post-publication.

 Provide full transparency into what each artifact contains, including third-party dependencies.

Detect and block artifacts with known CVEs.

 Prevent unauthorized uploads or modifications.

 systems help mitigate risks and build a secure, resilient software supply chain.

Cloudsmith is a fully managed, cloud-native artifact management platform that powers software delivery for organizations of all sizes—from fast-moving startups to global enterprises. From global package distribution to compliance automation and cost optimization, here are a few real-world examples of how Cloudsmith is making a difference. 

Check out the Cloudsmith product demo series

Diligent: Streamlining Compliance and Scaling Securely

 Secure artifact management at scale.
Diligent needed to modernize its artifact workflows as legacy systems became too complex and inefficient. With Cloudsmith, they achieved secure, centralized control, automated delivery pipelines, and real-time visibility—boosting compliance and development velocity.

Humanising Autonomy: Enhancing Developer Experience and Global Delivery

Multi-format distribution with developer-first UX.
After struggling with high costs and poor support on Artifactory, Humanising Autonomy adopted Cloudsmith for fast onboarding, reduced expenses, and a dramatically improved developer experience. Cloudsmith now powers global SDK distribution across Python, Docker, npm, and more.

Font Awesome: Scaling Global Distribution Without the Headaches

Digital artifact delivery with licensing support.
Font Awesome turned to Cloudsmith when internal solutions couldn’t meet uptime or performance demands. Cloudsmith now enables seamless, secure distribution of fonts and icons globally—while handling entitlements, licensing, and performance at scale.

“Cloudsmith transformed how we manage dependencies. Our releases are faster, more secure, and always reproducible.”

Getting started with cloud-native artifact management

 isn't just a nice-to-have—it's a core pillar of modern software delivery. With Cloudsmith as your enabler, teams gain:

 Versioned and cached artifacts reduce build time dramatically and automate CI/CD integration.

 Sign, scan, and verify every artifact in your pipeline to strengthen software supply chain security.

 Elastic scalability, zero maintenance overhead, and high availability by design.

 Fine-grained permissions, full audit logs, and flexible policies.

When to move to cloud-native artifact management

As organizations scale and their software delivery becomes more complex, traditional artifact storage solutions often fall short. Here are some of the key signals it’s time to move to a cloud-native artifact management platform:

You’re driving cloud-native or platform engineering initiatives:

 Shift-left strategies, microservices, and containerization demand flexible, scalable tooling.

You’re building a “golden path” for developers:

 Standardizing dev workflows requires a universal, reliable, and developer-friendly artifact solution.

Compliance and audit requirements are growing:

 From SBOMs to regulatory mandates, centralized visibility and policy enforcement become critical.

 Bringing multiple dev teams onto one platform simplifies operations and improves security posture.

You’re experiencing scale or performance issues:

 Global distribution, high availability, and edge caching are essential for modern delivery pipelines.

Here are the key steps to begin your artifact management journey:

Audit your existing storage methods. Are they scalable? Secure?

Eliminate infrastructure headaches and adopt elastic, managed repositories.

 Automate artifact publishing and retrieval to streamline builds.

 Start enforcing software supply chain security from the source.

 Protect sensitive artifacts and avoid clutter by defining expiration or cleanup policies.

By implementing the above, teams can modernize their pipelines and strengthen their DevOps foundation.

An artifact repository provides a central, secure location for storing build outputs, enabling reproducibility, traceability, and controlled access during development and deployment.

2. How does artifact management work with CI/CD pipelines?

CI/CD systems publish artifacts to a repository after builds and retrieve them during deployment. This creates consistent, versioned, and repeatable pipelines.

3. What is the difference between JFrog Artifactory, Nexus, and Cloudsmith?

Parul Jhawar

Marketing

Artifact Management: A Complete Guide

Why developers must prioritise logging and visibility in CI/CD pipelines

This marks the final entry in our 10-part series on the OWASP Top 10 for CI/CD security risks. While production environments often benefit from rigorous hardening, logging and observability, in CI/CD pipelines this often remains critically under-addressed, despite being a key focus of OWASP. In this post, we’ll unpack the security risks posed by insufficient logging in CI/CD environments, why it matters, and how you can strengthen your defences using modern artifact management solutions like Cloudsmith, alongside powerful open-source tools like Falco and GUAC.

Risk of attacks going undetected in CI/CD pipelines

Without proper logging and visibility, attackers can move through your CI/CD systems undetected - whether stealing credentials, injecting malicious code, or tampering with artifacts. This lack of audit-ability makes post-incident investigations nearly impossible, delaying containment and increasing the potential damage.

As we look to evolving regulatory pressures through EU’s Cyber Resiliency Act (

), Network and Information Systems Directive 2 (

) and Digital Operational Resilience Act (

), it’s more urgent than ever to have adequate auditing and visibility capabilities to meet these compliance requirements.

At the same time, threat actors are increasingly exploiting programmatic access, automated bots, and compromised tokens to breach and persist within CI/CD pipelines. While strong observability might feel like a "nice-to-have" on a checklist, it should be your first line of defence and your best tool for recovery.


Why logging in CI/CD is often overlooked

While logging is typically mature in production environments (covering servers, apps, and network infrastructure) CI/CD systems often fall through the cracks. Consider how many tools touch your pipeline:


Supply Chain Management (GitHub & GitLab)

Deployment/orchestration platforms (Kubernetes)

Artifact repositories (Cloudsmith, Nexus & Artifactory)

Each of these components introduces new vectors, and often lack default security logging capabilities unless explicitly configured.


How to build effective logging and visibility in CI/CD

There are several elements to achieving sufficient logging and visibility:

Before you can secure your pipeline, you need to inventory every system involved, from source code managers, build servers, artifact storage, through to deployment systems, whether that be Kubernetes or Terraform. Open-source tools like 

 (Graph for Understanding Artifact Composition) help you 

 between artifacts, identify missing SBOMs/SLSA attestations, and catch policy violations. GUAC ingests metadata like SBOMs and builds a graph to trace how artifacts are produced, increasing transparency across your pipeline.

 explores the various nodes and relationships of GUAC. The below 

Cloudsmith Blog

Competition, transparency and building the future of the Software Supply Chain

Kubernetes 1.34 – What you need to know

Artifact Management: A Complete Guide

OWASP CI/CD Part 10: Insufficient Logging and Visibility

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

Of Course We Embrace Open Source!

Unlocking policy-as-code automation with Cloudsmith EPM

Using Trivy Inside Cloudsmith

Golden Paths Made Easy With Cloudsmith

OWASP CI/CD Part 9: Improper Artifact Integrity Validation

Security is a leading priority for 2025

The Artifact Management Market Is Up For Grabs