# Software supply chain

> How to verify a Neural Inverse release: checksums, signatures, build provenance, software bills of materials and machine-readable security advisories.

Source: https://neuralinverse.com/trust/supply-chain/

---

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.

Contents

1.  [What each release carries](https://neuralinverse.com/#summary)
2.  [Verifying Govern](https://neuralinverse.com/#govern)
3.  [Verifying the CLI](https://neuralinverse.com/#cli)
4.  [The Editor and the Agents app](https://neuralinverse.com/#desktop)
5.  [Software bills of materials](https://neuralinverse.com/#sbom)
6.  [Machine-readable advisories](https://neuralinverse.com/#advisories)
7.  [Closed networks](https://neuralinverse.com/#air-gapped)
8.  [Our security key](https://neuralinverse.com/#keys)

## 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

1.  Check each file against the release's SHA-256 checksums file.
2.  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.
3.  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.
4.  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](https://neuralinverse.com/docs/cli/install/).

## 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](https://neuralinverse.com/contact/?topic=security-docs) for any version.

## Machine-readable advisories

Our [security advisories](https://neuralinverse.com/trust/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](mailto:security@neuralinverse.com), use our PGP key at `/.well-known/pgp-key.txt`. Fingerprint: \[PGP fingerprint: to be confirmed\].