I take security bugs in Binacle.Net seriously. I appreciate your efforts to responsibly disclose your findings.
To report a security issue, please use GitHub's Security Advisory "Report a Vulnerability" tab.
I will send a response indicating the next steps in handling your report. After the initial reply, I will keep you informed of the progress towards a fix and full announcement.
I release security patches for the latest version only. Please ensure you are using the most recent release.
| Version | Supported |
|---|---|
| latest | ✅ |
| < latest | ❌ |
Images published from 3.0.0 onward are signed, and carry an SPDX software bill of materials and SLSA
build provenance. Replace <version> with the release you pulled.
cosign verify binacle/binacle-net:<version> \
--certificate-identity-regexp '^https://github\.com/binacle-labs/Binacle\.Net/\.github/workflows/release-docker-image\.yml@refs/heads/main$' \
--certificate-oidc-issuer https://token.actions.githubusercontent.com
docker buildx imagetools inspect binacle/binacle-net:<version>Both flags on cosign verify matter. Without the identity you are only asking whether anyone signed the
image, and anyone can - Sigstore is open to every GitHub account. The two flags together are what say it came
from this repository's release workflow.
The identity ends @refs/heads/main, the branch the release workflow is dispatched on, and the $ anchors it
there. Without the anchor the check accepts a signature made from any branch in this repository, and pushing a
branch is not a release.
Use cosign 2.6.0 or later, or 3.0.1 or later. Sigstore is moving the public transparency log its signatures are recorded in, and older cosign builds cannot read entries in the new one. An out-of-date binary fails the check the same way a tampered image would.
The signature covers the image digest, so it holds for the 3.0 and latest tags as well as the exact
version - verifying any of them verifies the same artifact.
Releases before 3.0.0 cannot be verified. 2.1.1 and everything earlier were published before the
signing pipeline existed, so cosign verify answers no signatures found against them. That is history
rather than a failed check, and it applies to a moving tag like latest for as long as it still points at
one of those releases.
A passing verify means the image came from this repository's release workflow. It does not mean the image is free of vulnerabilities. For that, read the bill of materials.
For security issues in third-party dependencies, please refer to:
- NOTICE - Direct dependencies and their licenses
- Dependencies - Complete Software Bill of Materials
Report security bugs in third-party modules to the respective maintainers or through their security channels.