We’ve shipped two security improvements that make it easier to trust the plugins you download and run from us. Both are now live and will apply to all future releases.
Signed Release Archives
Every release archive on https://releases.monitoring-plugins.pro/
now ships with a detached OpenPGP signature — a small .asc file next to each .tar.gz. Publishing an archive without a matching signature is no longer possible, and we have retroactively signed every archive that was already available, so the complete release history is covered.
This lets you verify that an archive really comes from us and has not been tampered with in transit or at rest:
gpg --verify check-netapp-eseries-1.2.0.tar.gz.asc check-netapp-eseries-1.2.0.tar.gz
A successful check reports a Good signature from monitoring-plugins.pro Release Signing <releases@monitoring-plugins.pro>.
You can fetch our public signing key from the Docs-Server and we’ve added verification instructions to the release pages and the documentation site.
The fingerprint of the signing key is also available at https://docs.monitoring-plugins.pro/global-topics/release-signing/ . For an additional check, please contact us by phone or Signal using the number in our email signature.
We deliberately point to the phone number in our email signature rather than one published on a server: a server could in principle be compromised, so an out-of-band channel gives you an independent way to confirm the fingerprint.
Isn’t HTTPS enough on its own?
HTTPS already protected a download while it travels from our servers to you — nobody can alter the archive in transit without breaking the connection. What HTTPS cannot detect is tampering at the source: if an attacker managed to modify a file on our server itself, your browser would still see a perfectly valid HTTPS connection. A detached GPG signature closes that gap. Because the signature is created with a key that never touches the web server, you can confirm that an archive is exactly what we built — even in the unlikely event that the server hosting it was compromised.
Software Bill of Materials and Vulnerability Scanning
Every build pipeline now produces a Software Bill of Materials (SBOM) for the Go components that we actually ship to you, in the standard SPDX format. The same pipeline cross-checks each dependency against the OSV vulnerability database for known CVEs and security advisories.
The gate is intentionally strict: a build fails as soon as a single vulnerability of severity LOW or higher is detected. In other words, a release can only go out if it has no known open vulnerabilities in its shipped dependencies. As of this release the count is zero across all severity levels — and as part of this work we reviewed and remediated the findings that existed before the gate was introduced.
We also ship the SBOM itself: it is now part of every release package, bundled inside the .tar.gz, so you can use it directly in your own compliance or audit work.
There is a regulatory angle here, too. The EU Cyber Resilience Act (Regulation (EU) 2024/2847) will require manufacturers of products with digital elements to maintain a machine-readable SBOM, with the main obligations applying from December 2027 — so having one in every release keeps both us and you well ahead of that deadline.
In Short
- Every release archive is signed — you can verify authenticity and integrity yourself with
gpg --verify. - The public key and fingerprint are published, with an out-of-band phone/Signal check available for extra assurance.
- Every release is scanned for known vulnerabilities, with a strict zero-tolerance gate.
- You can feed the SBOM file included in each release package straight into your own compliance process.
These changes mostly happen behind the scenes, but the result is something you can check yourself: the software you run from us is signed, scanned, and accounted for.
Comments