Software Bill of Materials
Controlled release builds generate CycloneDX SBOM evidence for native and OCI artifacts.
Hexjack Lens · Software assurance
Know what you're deploying.
Lens uses a controlled release pipeline that builds native and OCI artifacts from one source revision, generates software-supply-chain evidence alongside them, and provides a defined verification path for customer engineering and security teams.
Engineering CI
Every change is gated before release.
Pull-request and main-branch CI run deterministic module checks, formatting, vet and tests, reachable Go vulnerability analysis, dependency and secret scanning, native build, OCI build, deployment-baseline verification and a fail-closed HIGH/CRITICAL vulnerability scan of the built OCI image.
Deployment evidence
The release artifact is exercised as a deployment artifact, not only compiled.
The controlled path verifies non-root runtime identity, external configuration, read-only-root operation, local health/readiness, same-image/different-config behaviour and graceful termination before SBOM, signing and provenance stages complete.
Cross-cutting verification
Security controls are exercised together, not only feature by feature.
The repository maintains executable evidence across the exact public tool contract, configured destination enforcement, authentication failure safety, secret non-disclosure, hostile evidence handling, investigation isolation, traversal protection, resource bounds, hardened OCI runtime assumptions, supply-chain assurance and metadata-only audit behaviour.
Vulnerability assessment
The controlled path runs Go vulnerability checks, dependency and artifact vulnerability assessment, and source secret scanning with blocking policy for required findings.
Immutable identity
The release workflow captures the pushed OCI image by immutable digest rather than relying only on a mutable tag.
Signing
The controlled workflow includes keyless OCI signing through GitHub OIDC and signed Sigstore bundles for native artifacts and assurance evidence, so exact release artifacts can be verified rather than trusted by filename or tag.
Build provenance
The workflow records controlled build inputs and generates an in-toto provenance statement so source revision, build process, evidence and resulting artifacts can be traced together.
Customer verification
Release manifests, immutable OCI identity, checksums, Sigstore bundles, SBOMs, scan evidence and provenance support online, restricted-network and native-artifact verification within an organisation's own approval process.
Evidence, not theatre
The aim is not to ask customers to trust a security claim.
It is to give their engineering and security teams useful evidence with which to assess the software themselves. Assurance claims should never exceed the evidence produced for the artifact concerned.
Release acceptance
Assurance follows the exact artifact into deployment.
Release acceptance ties the tested source revision to immutable OCI digest and native checksums, then verifies the standalone MCP surface across independent research contexts. The same release identity carries through signatures, provenance, SBOMs and scan evidence, so engineering and security teams can assess the exact software entering their estate.
Connected, restricted-network and native deployments use the same release evidence model. A locally rebuilt binary or mutable image tag is not treated as equivalent to the controlled release artifact.
Lifecycle
Useful after release too.
A software inventory remains useful when new vulnerability information appears. The assurance model is designed so released artifacts can be assessed against later findings rather than reconstructing their contents from memory.
Artifact identity also supports controlled replacement and rollback when required. When new vulnerability information appears, exact OCI digests or native checksums can be mapped back through retained SBOM, provenance and build evidence to determine affected releases without reconstructing them from memory.