When an organization deploys software to govern its AI agents, a natural question follows: how do you know the governance software itself is trustworthy? How do you know the version you installed is the version the developers built and signed? How do you know it does not contain a vulnerable dependency that an attacker could exploit? How do you know the build process was not tampered with?
These questions belong to the domain of software supply chain security – the practice of verifying not just what a software package does, but where it came from, how it was built, and whether that provenance can be demonstrated. coding-ethos, the open-source enforcement engine behind Ethosure, takes supply-chain security seriously enough to be one of its public trust signals. This article explains the mechanisms in plain language.
What an SBOM is
An SBOM – Software Bill of Materials – is a structured list of every component in a software package: every library, every dependency, every open-source module that the software incorporates. Think of it as the ingredient list on a food product, but for software.
Without an SBOM, an organization installing a software package has to trust the vendor’s word that the package is clean. With an SBOM, the organization can check each listed component against vulnerability databases (such as OSV, the Open Source Vulnerability database), confirm that dependency versions are current, and verify that no known-malicious packages are included.
Ethosure’s coding-ethos generates SPDX JSON SBOMs as part of its release process. SPDX (Software Package Data Exchange) is an ISO/IEC standard for SBOMs maintained by the Linux Foundation. Each release includes an SPDX SBOM that can be inspected, ingested by vulnerability scanners, and verified against the release artifacts.
What attestations are
An attestation is a cryptographically signed statement about a software artifact: “I, GitHub’s CI system, built this artifact from this source commit at this time, using this build pipeline.” Because it is cryptographically signed, an attestation can be independently verified – you can check that the artifact you downloaded was produced by the claimed build process, not substituted in transit or after release.
coding-ethos’s release process includes:
- GitHub artifact attestations: generated automatically by GitHub’s attestation infrastructure at release time. These can be verified with the GitHub CLI: `gh attestation verify <artifact>`.
- Offline `.intoto.jsonl` attestation bundles: `in-toto` is an open framework for supply chain integrity. `.intoto.jsonl` attestation bundles attached to the GitHub release provide portable, offline-verifiable proof of build provenance that does not require trusting GitHub’s attestation API.
- SHA-256 checksums: simple hash verification for every release artifact, so you can confirm the downloaded file matches what was published.
- PyPI Trusted Publishing: when coding-ethos is published to PyPI (the Python package index), it uses PyPI’s Trusted Publishing feature, which means PyPI generates its own attestation that the package was uploaded by the project’s official CI workflow – not by a credential that could be stolen.
Together, these attestation mechanisms answer the question: “Did the thing I installed actually come from the project’s official build process, unmodified?”
The OpenSSF Best Practices badge
The Open Source Security Foundation (OpenSSF) runs a Best Practices Badge program. Projects that earn this badge have demonstrated, through a human-reviewed checklist, that they follow security and quality practices across areas including security policy, vulnerability reporting, dependency management, testing, documentation, and contribution processes.
Ethosure’s coding-ethos currently holds the OpenSSF Best Practices Silver badge (project #12737, publicly verifiable at bestpractices.dev/en/projects/12737). The project is actively tracking toward Gold.
Silver is not the easiest tier to obtain. It requires demonstrating practices such as:
- A documented security policy and vulnerability reporting process.
- Automated testing with coverage reporting.
- Signed releases with provenance documentation.
- Dependency update management.
- Static analysis in CI.
- Governance and contribution process documentation.
For organizations evaluating a security tool, the Silver badge is a meaningful signal: an independent body has verified that the project applies rigorous practices to its own development.
Continuous scanning: CodeQL, OSV-Scanner, Zizmor
Beyond the release-time attestations and badge, coding-ethos runs continuous supply-chain security scanning on every pull request and scheduled basis:
- CodeQL: GitHub’s code analysis engine scans the Go and Python source code for vulnerabilities, security misconfigurations, and code quality issues.
- OSV-Scanner: scans dependencies against the OSV vulnerability database for Go modules, Python packages (via uv), and GitHub Actions dependencies.
- Zizmor: a specialized GitHub Actions security scanner that checks for workflow misconfigurations, injection risks, and permission issues.
- actionlint: validates GitHub Actions workflow syntax and logic.
SARIF output from all these tools is uploaded to GitHub’s code-scanning interface, providing a continuous, queryable vulnerability record for the project itself.
Dogfooding: the project enforces its own rules on itself
An unusual and significant trust signal: coding-ethos is dogfooded. The project enforces coding-ethos policy on its own development workflow. The same hooks, CEL policies, SARIF enforcement, and managed toolchain that users deploy for their AI agents are in active use on the coding-ethos repository itself.
This matters because it means the enforcement rules are continuously tested in real conditions. A policy that generates too many false positives, or that is too cumbersome to follow in practice, would create friction in the project’s own development – creating immediate pressure to improve it. The dogfooding practice is noted explicitly in the project’s trust signals documentation.
What this means for regulated buyers
For a procurement team at a regulated organization evaluating governance software, supply-chain trust is not a checkbox – it is a requirement. Using software to govern AI agents whose provenance cannot be verified creates a circular trust problem: you are relying on unverified software to provide verification.
coding-ethos’s supply-chain practices – SPDX SBOMs, GitHub and PyPI attestations, offline `.intoto.jsonl` bundles, SHA-256 checksums, OpenSSF Silver badge, and continuous vulnerability scanning – provide an auditable provenance chain from source commit to installed package. That chain is publicly inspectable and does not require trusting Ethosure’s word that the software is clean.
