Packagist processes about 100 million package installations per day across roughly 400,000 packages. Until now, a package ownership transfer, repository URL change, maintainer removal, or altered release could happen without a durable public trail that downstream teams could inspect.
The planned transparency log records events that affect the PHP dependency supply chain. It covers package ownership, repository URLs, maintainers, releases, removed versions, and changes to underlying Git tags. Account events such as two-factor authentication changes and password resets are also part of the design.
The log will be available through a web interface and an API. Researchers can investigate incidents with historical evidence, while companies can monitor the packages they actually install. The PHP Foundation coordinates the work with funding from Germany's Sovereign Tech Agency, following Level 3 of the OpenSSF package repository security principles.
Without a subscriber, the log is a dead file
The announcement describes a web interface and an API. Implementation proceeds in stages: remaining events and public interfaces arrive incrementally. Value for a product team does not appear on post day. It appears when someone subscribes to the slice that matters and answers an event.
Define that slice from composer.lock, not from 400,000 packages. Direct and transitive packages you actually install. Ownership, source URL, maintainer, and Git tag for those names. A famous maintainer's account you do not use can stay out. Noise volume on a public register is what kills alert adoption.
Name an owner. Security, platform, or the team that already watches Dependabot. Without an owner, the webhook lands in the open team channel and becomes wallpaper. With an owner, the event becomes a queue: triage, a ticket, or justified silence.
Third-party tools will show up. Treat them like any other sensor: the public log is the source, the vendor is the filter. If the filter disappears, you still need to query the API. Do not outsource the only copy of the policy.
Owner and URL changes deserve priority
A new release is the most common event and the least informative on its own. Composer already shows the bump in the PR lockfile. What the transparency log adds is what the lockfile does not say: the package changed hands, the pointed GitHub moved, a maintainer left, a tag was rewritten, 2FA on the publishing account was turned off.
Those events carry higher risk density. A classic supply-chain compromise takes the account, points source at a fork, and publishes a version semver will accept. If your alerts treat "new tag 1.4.3" the same as "ownership transferred," the channel explodes on the first weekday and someone mutes the rest.
Write the policy in two layers. Layer A, wake someone: ownership transfer, URL change, maintainer removal, alteration of an already published tag, 2FA disabled on the publishing account. Layer B, keep for audit: releases and version removals, so you can rebuild a timeline later. Layer B can go to an index. Layer A goes to a pager or the PR checklist.
Password resets and 2FA are account events, not package events. Correlate them with the packages that account controls. Without that join, the signal stays abstract.
Pipeline alerts need to filter routine releases
The natural operational place is the CI that already reads composer.lock. On a PR that updates a dependency, query the log for that package in the interval since the last known lock. If a layer-A event exists, the PR does not mix "patch bump" with "the source moved." The reviewer sees the fact next to the diff.
Outside the PR, a daily job on the production lock catches what nobody updated. An abandoned package that changes owner without a bump is the case classic Dependabot misses. The log exists for that silence.
Calibrate volume. If the job emits dozens of lines a day, the rule is too wide or the slice includes dev packages that never reach production. Split require from require-dev. Production first.
Packagist says coverage grows in increments. The job must tolerate an event that is not emitted yet, without treating absence as "nothing happened in the world." An incomplete log is better than total silence; still, document what is already covered.
Pins and hashes remain the install defense
A public register does not stop composer update from fetching the tarball. Version pins, a committed composer.lock, composer audit, and diff review remain the controls the build machine obeys. The log feeds the question "should we install this now?" and the later question "when did this package change hands?"
Incident investigation gains history. Instead of a screenshot of a package page, the team can ask the API for events between two dates. That is what OpenSSF level 3 asks of repositories: the ability to see what changed. npm and PyPI already moved in this direction. PHP arrives with Sovereign Tech Agency funding and PHP Foundation coordination. The next announced block, organizational ownership, attacks the shared account that today blocks real 2FA.
None of that replaces the habit of not running a blind update on a package that authenticates users. The log makes the habit verifiable. Without a subscriber, a slice, and a distinction between a bump and an owner change, the public record stays available to researchers and invisible to the team that, in aggregate, installs 100 million times a day, and in this project installs zero times with an alert.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
