Security and trust
Software supply chain
How to check that what you install is exactly what we built: checksums, signatures, build provenance, a bill of materials for every release, and security advisories your tools can read.
What each release carries
| Product | Checksums | Signatures | Build provenance | Bill of materials |
|---|---|---|---|---|
| Govern | SHA-256 checksums file | Binaries and container images signed with Sigstore cosign | SLSA level 3 | SPDX, signed |
| CLI | SHA256SUMS, checked by the installer | macOS binaries code-signed | Container image provenance | Container image SBOM |
| Editor and Agents app | [desktop app signing and SBOM: to be confirmed] | |||
Verifying Govern
- Check each file against the release's SHA-256 checksums file.
- Verify the signature on each binary and container image with cosign, against the signing identity we give you with the release. Signatures are keyless (Sigstore), so no long-lived signing key can leak.
- Verify the SLSA provenance: a signed statement of the source commit and the build that produced the binary, from an isolated build service the build steps cannot alter.
- Govern builds are reproducible: building the same commit with the published build script produces the same binary, so you can rebuild and compare.
Verifying the CLI
The installer downloads the release's SHA256SUMS, checks the binary against it, and refuses to install on a mismatch or a missing checksum. It does not edit your shell profile. macOS binaries are code-signed, and the container image is published with its build provenance and bill of materials. See installing the CLI.
The Editor and the Agents app
Your administrator provides the installers for your organisation. How they are signed for each platform: [desktop app signing: to be confirmed].
Software bills of materials
Every Govern release has a software bill of materials in SPDX format, signed so you can check it came from our build. Customers receive the bill of materials for each version they install; ask through the contact form for any version.
Machine-readable advisories
Our security advisories are also published as CSAF 2.0 documents, the OASIS standard that vulnerability-management tools read. Point your tool at /.well-known/csaf/provider-metadata.json on this site. Our security.txt lists it too.
Closed networks
Checksums can be checked offline. Keyless signature checks consult a public transparency log, so on a closed network verify signatures and provenance on a connected machine before you transfer the release, and check the checksums again inside. Your administrator can host the release files and checksums on an internal mirror.
Our security key
To encrypt a vulnerability report to security@neuralinverse.com, use our PGP key at /.well-known/pgp-key.txt. Fingerprint: [PGP fingerprint: to be confirmed].