Only the latest released version of sitespeed.io receives security fixes. If you're on an older release, please upgrade before reporting — the issue may already be fixed on main.

Every published release of sitespeed.io ships with cryptographic attestations you can check yourself. They confirm that the artefact you have was built and published by this repository's GitHub Actions release workflow — nothing more, nothing less. They are evidence of origin and integrity, not of correctness: a verified release can still contain bugs.

The npm tarball carries a Sigstore provenance attestation generated by the release workflow. To check it on a fresh install:

mkdir verify-sitespeed && cd verify-sitespeed
npm init -y
npm install sitespeed.io
npm audit signatures

You should see one signed package and zero unverified entries. The package page on npmjs.com also shows a "Provenance" badge linking to the exact workflow run that built the tarball.

Each release image pushed to Docker Hub is signed with cosign using GitHub Actions' OIDC identity — there is no long-lived signing key. The same image ships with a SLSA provenance attestation and a SPDX SBOM, both attached as OCI artefacts in the same Docker Hub repository. To verify the signature on a tag you've pulled (replace <version> with e.g. 41.4.0):

cosign verify sitespeedio/sitespeed.io:<version> \
  --certificate-identity-regexp \
    'https://github\.com/sitespeedio/sitespeed\.io/\.github/workflows/building-docker-release\.yml@refs/tags/v.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

A successful verification confirms the image was built and pushed by sitespeed.io's release workflow running on a vX.Y.Z tag of this repository. The -slim and -plus1 variants are signed the same way — substitute the tag and re-run.

To inspect the SBOM and the provenance attached to a Docker image:

docker buildx imagetools inspect sitespeedio/sitespeed.io:<version> --format '{{ json .SBOM }}'
docker buildx imagetools inspect sitespeedio/sitespeed.io:<version> --format '{{ json .Provenance }}'

If you would rather store a SBOM file alongside your own audit records, every release page at github.com/sitespeedio/sitespeed.io/releases has sbom.spdx.json and sbom.cdx.json as downloadable assets. These are the SBOMs npm sbom produces against the resolved dependency tree at release time, in SPDX and CycloneDX format respectively.

Please don't open a public GitHub issue for security problems. Use GitHub's private vulnerability reporting to file a confidential report; only the project maintainers see it, and we can coordinate a fix and a disclosure from there.

If GitHub's private reporting isn't an option for you, email Peter at peter@soulgalore.com and we'll work it out.

We need an exploitation scenario, not just a finding. Please tell us:

• Who the attacker is. sitespeed.io is a CLI you run against URLs you control or have permission to test. The realistic adversary is a target site or HAR file trying to pivot from being measured into compromising the host running sitespeed.io. If your scenario assumes a different attacker (a network attacker hitting sitespeed.io as if it were a server, an attacker who already has filesystem or shell access on the host), say so explicitly — it changes whether the impact is real for our users.
• What the attacker controls. A URL? The HTML / JS / response headers of a tested page? A HAR file fed back in? A config flag? An environment variable on the host?
• What they gain. Code execution on the host? Reading a file outside the result directory? Leaking a credential into a report or upload? A crash, an error, or noisy output isn't a vulnerability on its own — explain the impact.
• A minimal reproducer, ideally a sitespeed.io <args> invocation against a test URL or HAR you can share. We can't prioritise an issue we can't reproduce.

A working chain of "what the attacker controls → the vulnerable code path → an impact a sitespeed.io user would feel" is what turns a finding into a security report we can act on.

sitespeed.io is maintained by a small team on a volunteer / sponsor-funded basis, so we can't promise a fixed response SLA. In practice you'll get an acknowledgement within a few days. We'll keep you updated as we investigate, agree on a disclosure timeline, and ship the fix.

Things we want to know about:

• Issues that let untrusted data from a tested page or HAR escape into the host running sitespeed.io — e.g. code execution via the HTML report, the docs site, or a plugin's input handling.
• Credentials or secrets leaking into the report, the log, or an upload destination by accident.
• Privilege or supply-chain issues in the published Docker image or npm package.

This is the most common case, and it's worth a clear answer up front: an automated scanner flags a CVE in one of sitespeed.io's (often transitive) dependencies, and someone files a report saying we need to upgrade urgently. We'll usually look at it and reply that the issue isn't exploitable in sitespeed.io's threat model, and that the upstream patched version will land in a normal dependency bump. That reply isn't dismissal — it's the actual answer. Here's the reasoning:

A CVE has three parts: a vulnerable code path in the library, an attacker capability needed to reach that code path (usually attacker-controlled input of a specific shape), and an impact. For the CVE to matter to sitespeed.io users, all three need to apply in how sitespeed.io actually uses the library. The most common reasons that doesn't hold:

• sitespeed.io doesn't call the vulnerable code path. Many libraries do many things; the CVE may be in a function we never invoke.
• The attacker-controlled input doesn't exist in our flow. A regex DoS that needs an attacker to send arbitrary strings to a server endpoint doesn't apply when sitespeed.io is a CLI and the inputs are URLs the user themselves chose.
• The impact requires capabilities the attacker doesn't have in our context. If exploiting it requires already running code on the host, and our threat model is "a measured page trying to escape into the host", the chain is broken before it starts.

If you can show a concrete chain from "data flowing through sitespeed.io" → "the vulnerable code in the dependency" → "an impact a sitespeed.io user would feel", we'll treat it as a real vulnerability and ship a fix on the project's normal timeline. Without that chain, we'll close the report and pick up the upstream patch when it lands as a normal dependency bump.

• A site sitespeed.io is testing is slow, broken, or returns malformed HTML. That's the site under test — file it with them.
• A dependency CVE that's already patched on main or in the latest release. Please upgrade first and re-check.

Thanks for helping keep sitespeed.io safe.

Peter