Signing Artifacts to Prevent Artifact Poisoning

Breaches in software artifact integrity can have severe consequences. Bad actors poison artifacts by injecting malicious code into software packages, libraries, or container images, tricking developers and users into downloading compromised artifacts. These attacks can lead to data breaches, system takeovers, and widespread supply chain disruptions.

Continued artifact poisoning incidents highlight the increasing risk to software supply chains. A recent 

 let attackers inject malicious code into artifacts, compromising CI/CD pipelines. 

 enabled remote code execution and tampered dependencies. These cases underscore the need for strong artifact verification.

A highly effective defense against artifact poisoning is cryptographic signing, which verifies the authenticity and integrity of software artifacts. By digitally signing artifacts, developers use a private key to generate a cryptographic signature unique to their software. When an artifact is retrieved, the corresponding public key is used to verify the signature, checking that you can trust the source and the artifact hasn’t been tampered with.

Signing can be a complex process due to the expertise required and the various components involved. Developers need knowledge of key management, certificate verification, signing standards, and security policies. A good artifact management system aims to simplify this process.

When signing artifacts, there are two fundamental approaches:

 – Uses the artifact's built-in signing support (e.g., Swift Package Manager’s built-in signing, npm’s signature verification). This integrates well with artifact workflows, ensuring signatures are tied directly to the artifact format and verified automatically by native package managers.

, independent of the package format. While flexible and commonly used, third-party signing requires additional manual steps for verification.

Native signing is automated, built-in, and verifies artifacts within their ecosystem. Third-party signing tools such as GPG offer greater flexibility and compatibility, but they require manual integration and verification.

Native signing plays a role in maintaining compliance with industry and government regulations by ensuring that software artifacts are verifiable, traceable, and tamper-proof. It enforces cryptographic integrity, meeting the requirements of standards like SLSA, S2C2F, and FedRAMP Rev 5.

 enforces stricter security controls for software integrity and supply chain protection. Native signing supports this by ensuring artifacts remain verifiable, untampered, and compliant with cryptographic policies. Integrating native signing into CI/CD pipelines automates verification, simplifies compliance reporting, and aligns with FedRAMP’s Zero Trust principles.

Extending Native Support to Swift, NuGet, and Docker

Cloudsmith supports non-native signing for all package formats. In practice, organizations are making use of native signing for certain formats to improve workflows and reach compliance.

As part of Cloudsmith’s prioritization of security and compliance, three more package formats have been added to the roster for native signing support. Swift, NuGet, and Docker’s native signing tools can now be used in Cloudsmith, streamlining the workflow and eliminating the need for manual verification using GPG. These formats add to existing native signing support for Maven, Gradle, npm, RPM, SBT, Debian, and Alpine.

Cloudsmith is the first artifact management platform to offer Swift native signing. This positions Cloudsmith as a leading contender for enterprises engaged in Apple’s development ecosystem.

When working with Docker images, Cloudsmith uses Sigstore’s Cosign to automatically add a signature on upload. This uses an ECDSA (Elliptic Curve Digital Signature Algorithm) private key which is a type of public-key cryptography. An ECDSA key is generated automatically when you create a repository.

Cloudsmith automatically signs an image when it is uploaded using the repository’s ECDSA private key.

Anyone using the image can verify that it is trusted by downloading the matching ECDSA public key.

Alternatively, you can upload your own Cosign signature using 

Cloudsmith now supports native signing for all NuGet packages 

, a digital certificate that uses public key infrastructure (PKI) to verify the authenticity and integrity of signed artifacts. This allows consumers to verify repository signatures directly within native tooling or the NuGet CLI.

Native signing is enabled for the Cloudsmith repository, which issues a unique X.509 certificate.

When a NuGet package is uploaded or resynced, a repository signature is generated, and the signing certificate is included in the NuGet repository 

If a NuGet package contains an author signature, Cloudsmith will countersign the package.

Users can verify a package’s repository signature locally using native tooling or the NuGet CLI, confirming that the package originated from Cloudsmith.

Swift packages are signed using ECDSA private key in combination with an X.509 certificate, which holds the corresponding public key.

 consist of a source archive and a manifest file. The source archive contains the package’s sourced code and the manifest defines package details, dependencies, and configuration.

The manifest signature is an ‘attached’ signature - it is stored directly in the manifest file.

The source archive signature is a ‘detached’ signature - it is included in the metadata response when fetching a package by scope, name, or version. Swift verifies package signatures by checking the signing attribute in the metadata response. The source archive signature is generated after signing the manifest.

Swift signing in Cloudsmith works as follows:

Swift packages are signed with the X.509 certificate when a package is uploaded or synchronized.

Existing packages need to be resynchronized to append the signature to the manifest and generate one for the source archive.

To ensure secure artifact validation, Swift CLI uses a registry security configuration, defined in a JSON file for each user.

Take a look at the following documentation pages for more detailed information on how to use signing in Cloudsmith:

Native Signing Support In Cloudsmith Extended To Docker, NuGet, And Swift

Attacks targeting open source software (OSS) are on the rise, making the security of your software supply chain a top priority. What do you have to do, exactly, to secure your software supply chain?

This is the third blog in a Cloudsmith series about software supply chain security. The first blog gave an overview of the

Secure Supply Chain Consumption Framework (S2C2F)

, which is designed to mitigate against these attacks.

Level 1 of S2C2F is the bare minimum organizations should do to securely consume OSS. Today's blog focuses on the actionable steps and essential tools required to attain Level 1.

Level 1 primarily centers on the ingestion of OSS and requires the following:

Use an artifact repository (like Cloudsmith!) to cache OSS

Maintain an automated OSS inventory, such as a software bill of materials (SBOM)

Scan OSS for known vulnerabilities and licenses

Update your vulnerabilities (manually is okay at this level)

A major step in Level 1 is the adoption of an artifact repository like 

 as a central location for all OSS packages. This facilitates applying security controls for your OSS, and guarantees the availability of OSS package dependencies and protects you from incidents like the

Let's refresh on the eight principles of S2C2F:

— Consume your OSS from one location controlled by your organization, like Cloudsmith.

 — Create a list of all your OSS dependencies.

 — Update known vulnerabilities in a timely manner.

 — Force developers to adopt secure practices.

 — Audit that developers are consuming through the approved ingest method, and validate the integrity of the OSS that you are consuming.

 — Scan for malware and vulnerabilities using automation where possible.

 — Rebuild OSS on trusted infrastructure.

 — Have the ability to fork and fix code, when necessary, for a temporary fix.

Level 1 of the S2C2F concentrates on the Ingestion, Inventory, Scan and Update principles. The following initiatives are required:

Before you start implementing changes in your organization to align with S2C2F it is advised that you 

 of the organization's degree of maturity in software developer OSS management, security, and consumption processes.

Use a package manager to consume OSS packages. A package manager keeps track of what software is installed on your computer, and allows you to easily install new software, upgrade software to newer versions, or remove software that you previously installed. Scroll to the table below for a list of commonly used languages and their respective package format, registry, etc.

 to host all of your software packages and OSS packages. To set up Cloudsmith to cache your upstream OSS, do the following:

Update your software’s configuration file to point to your artifact repository (see the table below for the settings file for popular languages).

Start hosting your OSS packages on Cloudsmith by 

caching your public repositories or upstreams

. If the upstream repository you depend on goes down or is otherwise unavailable, your team can still access your cached versions stored in Cloudsmith. Cloudsmith will scan all the OSS packages for malware and vulnerabilities and also extract their licenses. This setup empowers our users to apply customized policies for enhanced security and management.

Level 1 of S2C2F requires organizations to maintain an automated inventory of all OSS used in development. There are a number of ways to take an inventory of your OSS

The gold standard for inventorying your OSS is to 

generate a Software Bill of Materials (SBOM)

 at build time. An SBOM is an ingredient list of all the dependencies in your software in a standardized format. SBOMs are needed for more advanced levels of this framework. OSS tools to generate SBOMs that can be integrated into your CI/CD include 

If you cache and proxy all the public registries that your organization uses on Cloudsmith, you can 

search for all packages that originated from an upstream

 via the UI or API by searching for tag:upstream (or even tag:maven-central if that's what you named the upstream when setting it up etc).

You can use your software’s dependency file (e.g. requirements.txt for Python builds) to see what dependencies your software is pulling in. This file may not include your software’s transitive dependencies (your dependencies’ dependencies).

Scan OSS for known vulnerabilities (i.e. CVEs, GitHub Advisories, etc.). Here are a few ways to do this:

Ideally you are integrating scanning tools early in your software development process using free tools like grype or paid tools like snyk.

Cloudsmith scans cached OSS for malware and vulnerabilities

. You can set a policy so that all packages must be above a certain vulnerability level and you can rescan a package for vulnerabilities.

Scan all the OSS in your organization for licenses.

for all cached OSS packages. Cloudsmith’s license policies allow you to define which package licenses are allowed within your organization.

Update vulnerable OSS manually using the results of your scanners, Level 1 S2C2F requires you to update vulnerable OSS manually. The framework advises that every organization should aspire to patch vulnerable OSS packages in under 72 hours. More advanced levels of S2C2F require you to use tools like 

Ingest it Inventory it Scan it Update it Cloudsmith
package managers Cloudsmith
Dependency-Track
CycloneDX
Syft
Trivy Cloudsmith
Grype
Snyk Manual (Dependabot for automation)Package InformationLanguage Package Format Package Manager Public Registry Config File Dependancy File Java JAR (Java Archive) Maven 

 pip.conf requirements.txt .Net (C#) NuGet NuGet 

 NuGet.config packages.config JavaScript/Node npm npm 

 package.json package-lock.json C/C++ No standardized format
vpkg and Conan are popular No standardized pm
vpkg and Conan are popular 

 conanfile.txt (for Conan), CMakeLists.txt (for CMake), vcpkg-configuration.json for vcpkg conanfile.txt (for Conan), CMakeLists.txt (for CMake) Rust Crates Cargo 

 .gemrc Gemfile Go Go Module go Go doesn't have a centralized registry go.mod go.sum PHP Composer Composer 

By prioritizing ingestion, inventory management, and scanning, you'll bolster your software supply chain's resilience against potential threats. Leveraging package managers, artifact repositories like Cloudsmith, and automated inventory tools enhances security and guarantees availability when consuming OSS.

What’s next from Cloudsmith? In future blogs, we’ll discuss how you can achieve the advanced S2C2F framework levels, offering actionable steps to further enhance your OSS consumption practices and fortify your software ecosystem. Subscribe below!

Register here for our upcoming webinar on S2C2F

 with the creator of S2C2F and leader of the Secure Software Supply Chain team at Microsoft, Adrian Diglio.

Cloudsmith blog

Native Signing Support In Cloudsmith Extended To Docker, NuGet, And Swift

Secure Open Source Consumption: Level 1 of S2C2F