Go software supply-chain evidence laboratory
A Go laboratory that connects an artifact to its SBOM, SLSA provenance, signature, source revision, builder, policy, and reproducible-build evidence.
Project definition
Problem statement
A software release may include hundreds of direct and transitive components. A version number or checksum alone does not explain what was included, how the release was built, or whether its evidence still matches the distributed artifact.
The engineering problem is to collect component inventories in standard formats, connect artifacts to build provenance and signatures, verify the evidence consistently, and demonstrate exactly which checks detect a controlled supply-chain change.
Project objectives
- Generate controlled fixtures and import CycloneDX 1.7 and a documented SPDX 3.0 subset.
- Verify artifact hashes, signatures, provenance statements, and declared source revisions.
- Compare two releases and explain component additions, removals, and version changes.
- Apply a configurable evidence policy without presenting it as a universal security guarantee.
- Measure detection accuracy, verification time, evidence completeness, and reproducibility.
Project structure
Project components
Prepared bundle catalogue
Selects local release bundles by restricted identifier and contains every evidence path beneath the selected bundle.
Component normaliser
Parses SPDX and CycloneDX records into a common component and relationship model while preserving original evidence.
Evidence verifier
Checks hashes, signatures, provenance subjects, source revisions, builder identity, and required fields.
Release comparator
Explains component, licence, digest, dependency, and evidence changes between two selected releases.
Policy evaluator
Runs explicit rules for missing evidence, unapproved components, unsigned artifacts, and provenance mismatches.
Experiment runner
Executes prepared clean and tampered scenarios and records the result, duration, and supporting evidence for every check.
Methodology
Project workflow
- 01Prepare release evidence
A controlled build produces an artifact, source revision, SBOM, signature, and provenance statement.
- 02Import and normalise
The laboratory stores the original evidence and converts supported formats into a comparable model.
- 03Verify
Hashes, signatures, provenance links, component records, and selected policy rules are checked.
- 04Introduce a controlled change
A dependency, artifact, or provenance field is altered in a documented test fixture.
- 05Compare results
The laboratory explains which checks changed, why they changed, and which evidence supports the result.
Demonstration scenario
A clean prepared release passes all ten configured checks. A tampered artifact then fails its SBOM digest, provenance digest, and signature relationships. A separate comparison against an untrusted-builder candidate shows that the artifact and source are unchanged while the builder identity differs.
Engineering
Tools and method
- Verification engine
- Go packages for streaming artifact hashing, standard-format parsing, signature verification, policy evaluation, and structured results.
- Evidence interface
- Vue and TypeScript for release selection, dependency graphs, verification results, and side-by-side evidence comparison.
- Evidence store
- PostgreSQL for release records, components, relationships, checks, policies, and experiment history.
- Cryptographic fixtures
- Local Ed25519 fixture signatures demonstrate digest verification while keeping production identity, certificates, and transparency logs outside the stated scope.
- Isolation
- Prepared Docker build targets and fixed inputs keep experiments reproducible and avoid scanning arbitrary external infrastructure.
- Standards
- A documented subset of SPDX, CycloneDX, and in-toto provenance fields defines exactly what the prototype supports.
Testing
Evaluation
Evaluation measures
- Exact agreement between expected and observed failed-check sets across eight scenarios
- Thirty verification trials for every prepared scenario
- Separate median and P95 verification timing for each scenario
- CycloneDX normalisation scaling from 11 to 5,001 components
- Release comparison tests for artifact, builder, source, and component deltas
- Go race tests, API tests, Vue tests, type checks, builds, and dependency scans
Project boundaries
- The project evaluates supplied release evidence and does not prove that an entire organisation is secure.
- All signing identities, artifacts, repositories, and tampering scenarios used in the demonstration are local fixtures.
- The initial implementation supports documented subsets of the selected evidence standards.
- A passing policy result is evidence for the configured checks, not a guarantee that the release has no vulnerabilities.
Included
- 01Go command-line verifier and HTTP verification service
- 02SBOM, provenance, signature, and release comparison interface
- 03Eight prepared clean and controlled-failure release bundles
- 04Ten verification checks with 30 trials per scenario
- 05Scaling results from 11 to 5,001 normalised components
- 06Complete source code in a private GitHub repository
- 0771-page project documentation in PDF and editable Word formats
- 089-page setup and usage guide
Project record
No information is collected on this page.
- Permanent project ID
- GP-CS-1IYY9ME
- Catalogued
- 21 Aug 2026
- Completed
- 23 Aug 2026
- Verified
- 23 Aug 2026
- Demonstration
- Included in repository
Handover
After purchase
- 01Payment is confirmed
The project is marked unavailable and cannot be purchased again.
- 02Repository access is granted
The buyer's submitted GitHub account receives access to the private repository.
- 03The purchase record is delivered
The certification sheet is prepared from the reviewed buyer details and sent privately by email.