Artifact integrity for Packagist and Composer

Funding from Alpha-Omega is enabling us to work on a new level of artifact integrity for Packagist and Composer. Rather than just providing JSON metadata pointing at download URLs, Packagist.org will provide immutable artifact files, publish checksums and signatures. Composer will verify the packages it installs originate from the right publishers (build provenance attestations), and future new functionality requiring stable artifacts will become possible. Maintainers will be able to publish artifacts to Packagist.org through Trusted Publishing.

Throughout our work on this project we will publish quarterly updates. This first post explains why these changes are needed, what we plan to build, and who will benefit.

Composer security challenges and artifact limitations

Packagist.org currently hosts metadata only. The metadata of each package version contains a download URL, in more than 99% of cases a zip archive that GitHub dynamically generates from the git repository. Consequently it’s usually easier to trust that PHP library artifacts match their source code than in other ecosystems, but in principle Composer downloads the artifact from any given URL and installs it without further verification.

Composer supports verifying artifacts against a checksum, but in practice the checksum has to be left empty for most packages. GitHub generates archives on demand. They differ based on the server you happen to download from and GitHub does not guarantee they stay byte-identical over time. So checksums regularly mismatch without anything being wrong.

Without verifiable artifacts, several attacks are hard to detect:

• A compromised maintainer account can point a package at a different repository. Packagist.org requires manual approval for packages with more than 50,000 installs, but smaller packages can be moved freely, and the artifacts served from the new location are not checked against the original contents.
• A compromised Git repository can be used to tag new versions where a composer.json overrides the download URL. Packagist.org accepts any URL there, including one on GitHub under an only slightly different repository name. Composer writes the URL to the lock file, but minor changes are easy to miss in a review.
• Companies mirroring packages in an internal repository have no practical way to verify that the artifacts they store match what the maintainer published, because there is no stable checksum to compare against.

Even worse, packages referencing artifact URLs outside a source code host have no mechanism at all to verify the artifact is generated from the given source code URL rather than from an attacker’s machine.

Dynamically generating artifacts from Git limits Packagist.org to publish only one package per Git repository. Today it is not possible to maintain multiple packages in a single repository. Projects work around the limitation to one package per repository in ways that make verification harder and usage riskier:

• Repositories with many packages, such as the Symfony framework or the Google Cloud SDK, are split into many read-only Git repositories. Publishers have to run and maintain infrastructure to synchronize these repositories with their main repository, and the integrity of the partially copied repositories with modified history is hard to verify.
• Packages that need a build step, most often PHP tools shipped as PHAR files such as PHPStan, store the built artifacts in a second Git repository. There is no standard way to verify where these files came from or how they were built. Repositories containing many revisions of large binary artifacts scale poorly and are hard to work with for users.

Earlier this year we made stable version metadata on Packagist.org immutable, so a published package version always points at the same Git commit. As we wrote then, the downloaded artifacts themselves are not immutable yet. Artifact integrity is the next step.

Alpha-Omega funds five project phases

The funding from Alpha-Omega allows the team at Packagist Conductors, the company operating Packagist.org and maintaining Composer, to work on the project over the coming months. Alpha-Omega protects society by funding and catalyzing sustainable security improvements across open source software.

The funded work is split into five phases:

1. Artifact storage. Packagist.org downloads the artifacts of every tagged version from GitHub, GitLab or Bitbucket and stores them permanently, on infrastructure provided by AWS and Bunny CDN. Checksums of the stored artifacts are published in the package metadata and in the public transparency log. Existing versions are backfilled wherever their artifact can still be downloaded. Current Composer versions already verify SHA-1 checksums, and new Composer releases will verify SHA-256 checksums.
2. Signatures and attestations. Every stored artifact gets a Sigstore signature and a build provenance attestation. Composer verifies them when it downloads packages, and the repository metadata and composer.lock format are extended to carry the information.
3. API token security. Packagist.org currently only offers one regular full access API token and one limited access API token per user, with access to every package the user maintains. New tokens can be limited to specific packages and permissions, expire, and are revoked automatically when they are found in a public repository.
4. Trusted Publishing infrastructure. Maintainers can configure which CI workflows are allowed to publish their packages. The workflow exchanges its OIDC token for a short-lived Packagist.org API token, so no long-lived secrets need to be stored in CI at all.
5. Publishing. Packagist.org accepts uploaded artifacts, and a new composer publish command signs, uploads and publishes them. Packagist.org will offer multiple release stages to allow uploading multiple artifacts before publication, and approving releases for publication with a hardware key.

Uploading artifacts and trusted publishing will only become available together with mandatory signing and attestations. We do not want to offer a publishing process that is less secure than the one that exists today. We want to maintain the strong link between source code and downloaded artifacts, which PHP benefits from.

Additional work is planned following these five phases, but has yet to be scoped and funded: verification and selection policies in Composer, a PHP library for creating and verifying Sigstore signatures, a hardened build environment that creates artifacts for packages not using Trusted Publishing. Throughout this project we will be looking to provide enough resources and information to help bring the same capabilities to other Composer repositories in the PHP ecosystem.

Who benefits from artifact integrity?

• Composer users get checksums for stable versions on Packagist.org, even for existing older artifacts. Current Composer versions already verify them without any change on the user's side. Newer Composer versions additionally verify SHA-256 checksums, signatures and attestations.
• Package maintainers will be able to publish multiple packages from one repository, and packages that need a build step beyond archiving, without maintaining additional git repositories. Scoped, expiring API tokens and Trusted Publishing reduce the damage a leaked credential can do.
• Companies and public sector organizations that mirror dependencies in an internal artifact repository can verify that the mirrored artifacts match what was published, as described in the draft SLSA Dependency Track.
• Security researchers and other third parties can monitor the checksums in the transparency log and detect if an artifact served for a published version ever changes.

Following and implementing industry standards

Our design follows what some other package registries already do. PyPI, for example, lets Python packages be published through Trusted Publishing, and the OpenSSF has published guidance on how registries should implement it.

The OpenSSF Securing Software Repositories Working Group published Principles for Package Repository Security, defining four security maturity levels in a number of tracks. The Authorization track covers who may publish a package and how they prove their authorization. Until now, this track did not apply to Packagist.org, because it only stores metadata and never receives package artifacts. With this project and our ongoing work on organization ownership and user permissions, we aim to immediately offer the highest security level on this track: short-lived tokens instead of long-lived secrets, automatic revocation of leaked tokens, and verifiable build provenance for published packages.

Non-goals and problems artifact integrity cannot solve

Artifact integrity hardens the steps between a maintainer publishing a version and a user installing it. It does not cover the following:

• Repository compromise. TUF, which the Drupal project adopted for packages.drupal.org, protects clients against a compromised repository server or signing key and against outdated metadata. It solves different problems and is not part of this project.
• Malicious or compromised maintainers. A maintainer acting in bad faith, or an attacker who has taken over a maintainer’s source code access, can still publish malware. The archive will carry a valid checksum, signature and attestation. However staged releases requiring an additional authentication factor, e.g. a hardware key, can help prevent publishing bad releases from accounts taken over by attackers.
• Code review. Hardening the path between maintainers and users cannot replace reviewing third-party code for malware, security issues and other vulnerabilities.

Project work already started

We already started on the project by adding FIDO2 hardware security keys (WebAuthn) as a second factor on Packagist.org, next to authenticator apps. Security keys are resistant to phishing, which makes maintainer accounts harder to take over. The groundwork is merged: Packagist.org now tracks which second factor a user verified and how recently, so sensitive actions can ask for a fresh verification. Later in the project, maintainers will use security keys to approve new releases before they are made available to users, as discussed in our Update on Composer & Packagist supply chain security blog post in May, 2026.

We’re planning the artifact storage phase: setting up storage and the CDN, downloading artifacts for new versions, publishing checksums in the metadata and the transparency log, and backfilling existing versions. The next update will cover the progress on artifact storage and the start of the work on signatures.

We want other Composer repositories in the PHP ecosystem to benefit from the work as early as possible. We will document the metadata format and the Composer changes in the open as we build them, so other repositories can adopt them early. If you run a Composer package repository and want to follow the work or get involved, contact us at contact@packagist.org.

Funding Composer and Packagist

Our sponsorship program does not yet bring in enough regular funding to finance security projects of this size. If your business relies on Composer and Packagist, please seriously consider becoming a sponsor. More information on sponsoring is available on our sponsorship website.