The usual line is that you cannot trust what you cannot read, so closed source and transparency are incompatible.
That folds two questions into one. Source access answers what the code does. Provenance answers a different question: is the thing I am about to run the thing that was built, from which commit, by which workflow, and what is inside it? You can answer the second without the first, and it is the one a security team has to answer before a deploy.
The Transparency Exchange API (TEA) is an OWASP standard that turns the second question into a lookup. A vendor publishes a product, its releases, and for each release the SBOMs, attestations and places to download it. A consumer starts from one identifier and walks to the exact artifact. Nothing in the model cares whether the source is open.
Open source: two tools, one signed statement per release
The Vulnetix CLI and Belai are public repositories under open licences. Their release workflows publish to TEA and sign the same shape of provenance, so you can check a download against the build that made it.
- Vulnetix CLI, licensed AGPL-3.0: github.com/Vulnetix/cli. One binary for SCA, SAST, secrets, IaC, containers and licences, with reachability, malscan and quality gates. Open in TEA Explorer.
- Belai, licensed Apache-2.0: github.com/Vulnetix/belai. A safer LLM coding harness with sealed context, a security classifier on every untrusted tool result and fail-closed posture gates. It is the agent that runs inside every Pix Sandbox. Open in TEA Explorer.
What happens on every release
1. Build and hash
The release job builds every binary and writes checksums.txt, one SHA-256 line per file.
2. Sign one statement
A separate job signs an in-toto SLSA v1 provenance statement. Its subjects are every line of checksums.txt plus checksums.txt itself, signed keyless with Sigstore, so no long-lived signing key exists to leak.
3. Verify before naming it
cosign checks the signature, the signing workflow's identity, the transparency log entry, and that every checksum line is a subject. Only a bundle that passes is called provenance.sigstore.json.
4. Publish
The bundle goes to the GitHub release and to TEA, beside the SBOM and a distribution entry for every binary, each with its digest.
One reusable workflow, Vulnetix/cli/.github/workflows/slsa-provenance.yml, does the signing for both repositories, and Belai pins it by commit. The signing identity is that file, so there is one workflow to read for both tools.
| A release as published | cli v3.126.8 | belai v0.163.0 |
|---|---|---|
| Licence | AGPL-3.0 | Apache-2.0 |
| Signed provenance subjects | 10 | 32 |
| Rekor transparency log entry | Yes | Yes |
| TEA artifacts | SBOM, provenance | SBOM, provenance |
| TEA distributions | 14 | 35 |
Counts are read from those two releases as published: the TEA record for the distributions, the signed bundle for the subjects. The subjects are every line of the release's checksums.txt plus checksums.txt itself.
Closed source: Pix Sandbox, where you cannot read the source but you can read everything else
Pix Sandbox is a managed machine, and its image and worker are closed source. That is a normal commercial position, and it is the case people say transparency cannot reach. For every image we build, these records are public:
CycloneDX and SPDX SBOMs
Every package in the image, in both formats, pinned by a lock file. Diff one image against the next.
A signed SLSA v1 bundle
Signed over the exact registry digest a sandbox launch runs, and verified with cosign in CI before it is published.
A record of the check
attestation.json states the source commit, the bundle's own hash and that the verification passed in CI.
Named by digest
Each image is its own TEA release, image- followed by the first 12 characters of its digest, so a running sandbox maps to one record.
The image is built with Nix on GitHub-hosted runners, built twice, and shipped only when both builds give the same hash. A sandbox also hashes every binary before Belai starts. An image that is the same twice, listed in full and signed over its digest is a claim you can test, whatever the licence on the source.
The Belai and Vulnetix binaries pinned inside the image are the release binaries from the open source section. Their hashes are subjects of the signed open source provenance, so the open and closed halves of the product verify against each other.
Open Vulnetix/pix-sandbox in TEA Explorer or list every image release via the TEA API.
More control over your supply chain than you would otherwise have
A security page asks you to believe. A TEA record gives your own tooling something to check. That moves the decision from the vendor to you, and it is why transparency matters more for closed source, not less.
Start from an identifier, not a web page
A product is a TEI or a package URL. You resolve it to a server and walk to the artifact you need, instead of hunting a vendor's security page for a PDF.
Check before you run
Hash what you are about to deploy and require that digest to be a subject of a statement signed by the workflow you expect. No match, no deploy. The policy is yours and it lives in your pipeline.
See what changed before you adopt it
SBOMs are machine-readable per release. Compare image N with image N+1 and know which packages moved before you pin the new one.
History the vendor cannot quietly edit
On our server a public release cannot be unpublished, and the open source bundles carry a public Rekor entry. A claim made in October is still checkable in March.
Evidence your tooling can read
The data is JSON over HTTP. Feed it to your asset inventory, your VEX workflow or your admission controller, and stop re-keying answers into questionnaires.
Follow the chain across products
The Belai and Vulnetix binaries inside a Pix Sandbox image are the same release binaries whose hashes are subjects of the open source provenance. One chain, three records.
Check it yourself
No login is needed to read our catalogue. Use the Vulnetix CLI, any HTTP client, or the TEA Explorer in the console. List the products with vulnetix tea products, read one with vulnetix tea product and the artifacts of a release with vulnetix tea collection.
To verify a downloaded binary, fetch provenance.sigstore.json from the release and run cosign verify-blob-attestation with --type slsaprovenance1, the GitHub Actions OIDC issuer and the certificate identity ^https://github.com/Vulnetix/cli/\.github/workflows/slsa-provenance\.yml@, naming the binary by its SHA-256 digest. Change one byte of the download and verification fails.
What this does not prove
Evidence is only worth publishing if it states its own limits. These are ours.
The source is still closed
For Pix Sandbox you can verify what was built, what is inside it and which workflow signed it. You cannot read its logic, and provenance is not a code review or a penetration test.
Build Level 2, not Level 3
The open source builds run on our own runners and the statement says so in runner_environment. That is signed provenance of a build workflow, not an isolated builder, so we claim Level 2 and nothing higher.
No Rekor entry for Pix Sandbox
The repository is private, so its bundles are signed without a public log entry. You verify them with the certificate and the signed timestamp.
Verify the next release yourself
Resolve the product, download the bundle, run cosign. If anything we say here does not hold, the record will show it. Open the TEA Explorer · Our open source projects · Read about the Pix Sandbox