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 GitHub Actions vulnerability let attackers inject malicious code into artifacts, compromising CI/CD pipelines. Attacks on Maven proxy repositories 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.

Native Signing vs Third Party Tools

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:

Native signing – 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.
Non-native (third-party) signing – Uses external tools like GPG to sign artifacts, 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 and Compliance

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.

For 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.

Automated Signing for Docker Images

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.

Docker image signing works as follows:

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 cosign sign.

Native Signing of NuGet Packages

Cloudsmith now supports native signing for all NuGet packages using an X.509 certificate, 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.

NuGet signing works as follows:

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 service index.
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.

Native Signing of Swift Packages

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

Swift packages 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.

Swift has two signatures:

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.

Further Reading

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

Signing Nuget Packages

Docker and Cosign

signing

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