HELM AI Kernel
Release and Security Evidence
Open-source execution kernel, CLI, MCP, conformance, verification, and compatibility.This page collects the public release, vulnerability disclosure, supply-chain, fuzzing, OpenSSF, VEX, SBOM, Cosign, and reproducibility material for HELM AI Kernel.
Audience
This page is for developers installing release artifacts, security reviewers, package maintainers, and organizations validating HELM AI Kernel before adoption.
Outcome
You should know how a release is produced, how to verify it, where to report vulnerabilities, and which evidence files support supply-chain review.
Release Evidence Chain
flowchart TD
subgraph Ingestion["1. Ingestion & Context Plane"]
tag["Version tag"]
ci["Release workflow"]
binaries["Binaries and packages"]
sbom["SBOM"]
attestation["Release metadata / attestation when present"]
optional["Optional Cosign / OpenVEX assets"]
end
subgraph Ledger["4. Tamper-Evident Ledger Plane"]
verify["Artifact verification"]
end
%% Operational Flow Edges
tag --> ci
ci --> binaries
ci --> sbom
ci --> attestation
ci --> optional
binaries --> verify
sbom --> verify
attestation --> verify
optional --> verify
%% Premium Styling Rules
style verify fill:#2f855a,stroke:#276749,stroke-width:2px,color:#fffMermaid source
flowchart TD
subgraph Ingestion["1. Ingestion & Context Plane"]
tag["Version tag"]
ci["Release workflow"]
binaries["Binaries and packages"]
sbom["SBOM"]
attestation["Release metadata / attestation when present"]
optional["Optional Cosign / OpenVEX assets"]
end
subgraph Ledger["4. Tamper-Evident Ledger Plane"]
verify["Artifact verification"]
end
%% Operational Flow Edges
tag --> ci
ci --> binaries
ci --> sbom
ci --> attestation
ci --> optional
binaries --> verify
sbom --> verify
attestation --> verify
optional --> verify
%% Premium Styling Rules
style verify fill:#2f855a,stroke:#276749,stroke-width:2px,color:#fffCurrent source release target: v0.5.6:
https://github.com/Mindburn-Labs/helm-ai-kernel/releases/tag/v0.5.6. The
release is complete only when GitHub shows Darwin/Linux/Windows binaries,
SHA256SUMS.txt, sbom.json, v0.5.6.openvex.json,
release-attestation.json, evidence-pack.tar, release.high_risk.v3.toml,
sample-policy-material.tar, helm-ai-kernel-launchpad-data.tar,
helm-ai-kernel.mcpb, helm-ai-kernel.rb, v0.5.6.json,
version-status.json, and matching *.cosign.bundle files for each primary
asset.
Public Release Material
| Need | Source path | Public route |
|---|---|---|
| Release preparation | RELEASE.md, VERSION, CHANGELOG.md |
/helm-ai-kernel/publishing, /helm-ai-kernel/changelog |
| Vulnerability reporting | SECURITY.md |
This page and /helm-ai-kernel/publishing |
| OpenSSF mapping | BEST_PRACTICES.md |
This page |
| SBOM and release metadata | release/README.md, scripts/ci/generate_sbom.sh, release asset sbom.json, release asset release-attestation.json |
This page |
| OpenVEX policy source | release/vex.openvex.json, release/vex/policies.yaml |
This page; only claim published VEX when attached to the GitHub release |
| Cosign and reproducible binaries | .github/workflows/release.yml, scripts/release/, docs/VERIFICATION.md |
/helm-ai-kernel/verification, /helm-ai-kernel/publishing; Cosign verification requires attached *.cosign.bundle files |
| Fuzzing | oss-fuzz/, Go fuzz tests under core/pkg/ |
This page and /helm-ai-kernel/execution-security-model |
Verification Commands
make release-binaries-reproducible
make release-smoke
make release-assets
make verify-cosign
make verify-fixtures
make docs-coverage docs-truth
Release artifacts should not be treated as trustworthy only because they are downloaded from a release page. Verify checksums, release metadata, receipt/evidence material, reproducible-build behavior, and signatures when signature bundles are attached.
For tag-triggered releases, the workflow requires the tag ref to match the
checked-in VERSION file, requires an exact v<version>.openvex.json, exports
the audit EvidencePack, verifies the staged evidence-pack.tar, and only then
writes final checksums. A failed EvidencePack verification blocks release asset
publication.
For v0.5.6, use checksum verification, SBOM inspection, OpenVEX inspection,
release metadata inspection, offline EvidencePack verification,
reproducible-build validation, and Cosign verification against the attached
bundles.
Source Truth
SECURITY.mdRELEASE.mdBEST_PRACTICES.mdrelease/README.mddocs/PUBLISHING.mddocs/VERIFICATION.md
Troubleshooting
| Problem | Check |
|---|---|
| Signature verification fails | Confirm the release actually includes *.cosign.bundle files, then check the expected workflow identity and Rekor entry documented in SECURITY.md. |
| Reproducible build hashes differ | Confirm SOURCE_DATE_EPOCH, -trimpath, and build-id settings match the release workflow. |
| VEX status is unclear | Inspect release/vex/policies.yaml; only rely on a release VEX file when it is attached to the GitHub release. |
| Kubernetes Helm validation runs the HELM AI Kernel CLI | Set KUBE_HELM_CMD to a Kubernetes Helm v3 binary or run make helm-chart-smoke, which uses a pinned containerized Helm runner when needed. |
| A security issue needs disclosure | Use security@mindburn.org; do not open a public issue. |
Release Verification Path
A release security page should let a developer verify an artifact without trusting prose. Include the expected version, checksum file, SBOM location, signature or provenance command, and the receipt/verifier compatibility note for that release. If a release artifact is missing, mark the verification mode as unavailable rather than implying Cosign, SBOM, or reproducible-build coverage. The minimum public acceptance path is: download release artifact, verify checksum, inspect SBOM/provenance when present, run the binary or container health check, create one receipt, and verify that receipt offline.