Verifying the authenticity and integrity of Sentinel releases before deploying to production.
Overview
Sentinel sits at the edge of your network and handles all inbound traffic. Verifying that the binary or container image you deploy is the exact artifact built by the Sentinel CI pipeline is a critical operational practice.
Examples on this page use CalVer release versions (e.g.,
26.01_0). Replace with your target version. See Versioning for the full versioning scheme and LTS windows.
Every release includes:
- SHA-256 checksums for integrity verification
- Sigstore cosign signatures (keyless, tied to GitHub Actions OIDC)
- SLSA v1.0 provenance attestations (Build Level 3)
- Software Bill of Materials in CycloneDX and SPDX formats
Verifying Binary Releases
SHA-256 Checksums
Every release archive has a corresponding .sha256 file. This is the simplest verification step.
# Download binary and checksum
VERSION="26.01_0"
# Verify checksum
Expected output:
sentinel-26.01_0-linux-amd64.tar.gz: OK
Cosign Signature Verification
Cosign keyless signatures prove the binary was built by the Sentinel GitHub Actions pipeline, not by a third party.
Install cosign
# Linux
# macOS
Verify a binary
VERSION="26.01_0"
Expected output:
Verified OK
What this proves:
- The binary was built by a GitHub Actions workflow in the
raskell-io/sentinelrepository - The signature is recorded in the Sigstore transparency log (Rekor) and is publicly auditable
- No private keys are involved — the signing identity is the GitHub Actions OIDC token
Verifying Container Images
Cosign Image Verification
Inspecting Container SBOM
The container SBOM is attached as a cosign attestation:
| | |
SLSA Provenance Verification
SLSA provenance proves the build was performed on GitHub-hosted runners from a specific source commit.
Install slsa-verifier
# Linux
# macOS
Verify provenance
VERSION="26.01_0"
What SLSA Level 3 guarantees:
- Build ran on GitHub-hosted infrastructure (not a developer laptop)
- Build script is defined in the repository (not injected)
- Provenance is non-forgeable (generated by the SLSA GitHub Generator, not the build itself)
Software Bill of Materials
Available Formats
Each release includes two SBOM formats:
| Format | File | Use Case |
|---|---|---|
| CycloneDX 1.5 | sentinel-VERSION-sbom.cdx.json | Preferred for vulnerability scanning |
| SPDX 2.3 | sentinel-VERSION-sbom.spdx.json | Preferred for license compliance |
Where to Find SBOMs
- Binary releases: Attached as GitHub release assets
- Container images: Attached as cosign attestations (see above)
Analyzing Dependencies
Scan SBOMs for known vulnerabilities using standard tools:
# Using grype (Anchore)
# Using trivy (Aqua Security)
# Using osv-scanner (Google)
License Analysis
# List all dependency licenses
|
Building from Source
You can independently verify that a release binary matches a build from source:
# Clone at the release tag
VERSION="26.01_0"
# Build
# Compare checksum
Note: Exact byte-for-byte reproducibility depends on the Rust compiler version, target triple, and build environment matching the CI pipeline. The release notes include the Rust version used.
CI/CD Integration
GitHub Actions
Verify the Sentinel container image before deploying:
- name: Install cosign
uses: sigstore/cosign-installer@v3
- name: Verify Sentinel image
run: |
cosign verify \
ghcr.io/raskell-io/sentinel:26.01_0 \
--certificate-identity-regexp "github.com/raskell-io/sentinel" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com"
Kubernetes Admission Control (Kyverno)
Enforce cosign verification on Sentinel images in your cluster:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: verify-sentinel-images
spec:
validationFailureAction: Enforce
rules:
- name: verify-cosign-signature
match:
any:
- resources:
kinds:
- Pod
verifyImages:
- imageReferences:
- "ghcr.io/raskell-io/sentinel*"
attestors:
- entries:
- keyless:
subject: "https://github.com/raskell-io/sentinel/*"
issuer: "https://token.actions.githubusercontent.com"
rekor:
url: "https://rekor.sigstore.dev"
Kubernetes Admission Control (OPA/Gatekeeper)
apiVersion: externaldata.gatekeeper.sh/v1beta1
kind: Provider
metadata:
name: cosign-verifier
spec:
url: https://cosign-gatekeeper-provider.cosign-system:8443/validate
timeout: 5
---
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
name: cosignverification
spec:
crd:
spec:
names:
kind: CosignVerification
targets:
- target: admission.k8s.gatekeeper.sh
rego: |
package cosignverification
violation[{"msg": msg}] {
container := input.review.object.spec.containers[_]
startswith(container.image, "ghcr.io/raskell-io/sentinel")
not external_data({"provider": "cosign-verifier", "keys": [container.image]})
msg := sprintf("Image %v failed cosign verification", [container.image])
}
Compliance Notes
Sentinel’s supply chain security practices align with the following standards and frameworks:
| Standard | Coverage |
|---|---|
| SLSA Level 3 | Build provenance, non-forgeable attestations |
| EO 14028 (US) | SBOM generation, software supply chain security |
| SSDF (NIST SP 800-218) | Secure software development practices |
| CIS Software Supply Chain | Signed artifacts, dependency management |
For organizations requiring specific compliance documentation, see the Enterprise Builds offering which includes CalVer-based LTS releases, early security advisories, and configuration stability guarantees.
See Also
- Versioning — CalVer/SemVer scheme, LTS windows, version mapping
- Security Hardening — Production security best practices
- Installation — Download and verify Sentinel