Plumb

Open security advisories

Checks whether the newest release of this package has a known, unfixed security vulnerability.
category
security
weight
10
veto
when it fails, the Security score is capped at 30/100

How Plumb checks this

What is inspected, and how the result is decided.

A security advisory is a public notice that a specific range of package versions has a known vulnerability. When the newest release still falls inside that range, everyone who installs the package today is installing a known problem. This is the most concrete risk Plumb can detect.

Plumb reads two independent advisory feeds: GitHub Security Advisories and the Packagist security advisories database. The two feeds are merged and duplicates are removed by CVE id, so a delay or outage in one feed cannot hide an advisory the other one knows about.

The check passes when no advisory covers the latest released version. It fails when at least one advisory does: either no fixed version has been published yet, or the fix is not newer than the latest release. Failing also caps the Security score at 30 out of 100. The check is not applicable when the package has no stable release to evaluate. If one feed is unreachable the other still produces a verdict and the failure is noted in the evidence; if every feed is unreachable the check reports an error instead of guessing.

This is a veto check. When it fails, the Security score is capped at 30/100 no matter how the other checks do. Learn how vetoes work.

Doing it well

Why this matters

A security advisory is a public notice that certain versions of a package have a known vulnerability. Once it is published, anyone can read it, including people looking for targets. Every project that installs an affected version is exposed to a problem that is already documented in public.

For a package maintainer, an open advisory against your newest release means every new install is a vulnerable install. Fixing it quickly protects every project that depends on you.

What good looks like

  • Your newest release is not covered by any published advisory.
  • When a vulnerability is reported, a fixed release goes out and the advisory records the fixed version.
  • Security fixes are released for every version line you still support, not only the newest one.

How to do it

Find out whether you are affected

Advisories about PHP packages are published in two main places: the GitHub Advisory Database and the Packagist security advisories database, which also feeds composer audit. Search both for your package name.

You can also check from the command line inside any project that depends on your package:

composer audit

Fix and release

  1. Fix the vulnerability on every branch you still support.
  2. Tag a new release for each of those branches. A patch release such as 2.4.1 is enough; the fix does not need to wait for other changes.
  3. Make sure the advisory names the fixed versions. On GitHub, edit the advisory in your repository's Security tab and fill in the patched versions. If the advisory was filed by someone else, request a change through the GitHub Advisory Database, or open a pull request against the FriendsOfPHP/security-advisories repository, which Packagist reads.

Publish your own advisories

If you discover a vulnerability yourself, publish an advisory rather than fixing it quietly. Users cannot upgrade away from a problem they do not know about. GitHub lets you draft an advisory privately, work on the fix in a temporary private fork, and publish both together.

Keep old lines honest

If you no longer fix a version line, say so in your README so users know to upgrade. An old line with an open advisory and no fix is a trap for anyone still on it.

Things to watch for

  • An advisory with no fixed version listed. Tools cannot tell users what to upgrade to. Always fill in the patched versions.
  • A fix that only lands on the main branch. Users on older lines stay vulnerable. Backport the fix or mark those lines unsupported.
  • A fix that was merged but never tagged. Composer installs tags, not branches. Until you tag, nobody gets the fix.
  • Duplicate advisories. The same issue can appear under a CVE id and a GHSA id. That is normal; make sure both list the same patched versions.

Further reading