Table of Contents

3.0.0 Consumer Verification Guide

This guide gives consumers and maintainers a conservative verification path for the 3.0.0 package family while NuGet package signing is deferred.

In this software project, ASI means Accountable Systems Infrastructure. This page describes package-source, metadata, Source Link, SBOM, and workflow-provenance checks. It does not convert AsiBackbone into a compliance product, a signed-package distribution, a production tamper-evident ledger, or a legal non-repudiation mechanism by itself.

Current verification boundary

For 3.0.0, consumers can verify release evidence in several layers:

  1. package source and expected package IDs;
  2. package version and target framework;
  3. NuGet repository metadata;
  4. Source Link repository commit metadata after packages are visible on NuGet;
  5. generated package SBOM files and sbom-manifest.json when produced by release workflows;
  6. package and SBOM provenance attestations when the workflow event supports GitHub artifact attestation.

NuGet package signing remains deferred unless a later release-preparation PR adopts, documents, and validates a reviewed package-signing process.

Confirm package source and package IDs

Use NuGet.org or the repository-produced package artifacts from the relevant GitHub Actions release workflow. Avoid mixing release-candidate artifacts from unrelated workflow runs with packages published from a different commit.

Expected stable 3.0.0 package IDs:

AsiBackbone.Core
AsiBackbone.DependencyInjection
AsiBackbone.Storage.InMemory
AsiBackbone.EntityFrameworkCore
AsiBackbone.AspNetCore
AsiBackbone.Testing
AsiBackbone.Templates
AsiBackbone.Analyzers
AsiBackbone.OpenTelemetry
AsiBackbone.Signing.LocalDevelopment
AsiBackbone.Signing.ManagedKey

Future Event Hubs, Purview, Azure-specific SDK adapters, Aspire runtime packages, robotics, immutable-storage, and additional provider packages are outside the 3.0.0 stable contract unless a later release explicitly ships them.

Confirm package version and target framework

For each consumed package, confirm:

  • package ID matches the expected AsiBackbone.* ID;
  • package version is 3.0.0;
  • package target assets include net10.0;
  • the consuming host uses a .NET 10 SDK/runtime or later.

The 3.0.0 package family intentionally targets net10.0. It does not provide net8.0 package assets. See the Target Framework Support Decision Record for the support-boundary decision and revisit criteria.

Confirm NuGet repository metadata

For each consumed package, confirm:

  • license metadata points to the project license;
  • project URL and repository URL point to the AsiBackbone repository or documentation;
  • repository type is present when NuGet metadata exposes it;
  • repository commit metadata is non-empty when available after publication.

Repository metadata helps connect a NuGet package to the source commit used for the package. It is release evidence, not package signing.

After 3.0.0 packages are published and visible on NuGet, maintainers should run:

./scripts/Validate-Source-Link-commit-metadata.ps1 -Version 3.0.0

This validation downloads the published NuGet packages and checks the expected repository type, repository URL, and non-empty repository commit metadata. Consumers can use the same script or mirror the same checks in their own release-intake process.

If Source Link metadata is missing or wrong after publish, document the failure and prepare a follow-up patch or advisory. Published NuGet package metadata for a version should be treated as immutable rather than overwritten by hand.

Confirm package SBOM and provenance artifacts

Package-producing workflows generate SPDX JSON SBOM files for produced .nupkg files and a sbom-manifest.json that maps package files to SBOM files and hashes.

Where the workflow event supports GitHub artifact attestation, package and SBOM provenance attestations may be attached to:

  • generated .nupkg files;
  • generated package SBOM JSON files.

These artifacts should come from the same workflow run that built and validated the package artifacts under review.

What provenance and SBOMs do prove

Package SBOMs and provenance artifacts can help show:

  • which workflow produced a package or SBOM artifact;
  • which package files and SBOM files were generated by that workflow run;
  • which package hashes were recorded in the package SBOM manifest;
  • which declared NuGet dependencies were recorded from package metadata;
  • whether a release process produced supporting supply-chain evidence for downstream review.

What provenance and SBOMs do not prove

Package SBOMs and provenance artifacts do not prove by themselves that:

  • the package is maintainer-signed;
  • the package is repository-signed;
  • the package is Authenticode-signed;
  • the package is production tamper-evident after download;
  • the package provides legal non-repudiation;
  • the package is vulnerability-free;
  • the package is approved for a consumer's compliance boundary;
  • the package source has been independently reviewed by the consumer.

Consumers should still perform normal source review, dependency scanning, package-cache controls, vulnerability review, and organization-specific approval.

NuGet package signing is deferred

The historical 3.0.0 packages should be described as having NuGet metadata, Source Link metadata, package SBOMs, and package/SBOM provenance artifacts where supported by the workflow event. They should not be described as maintainer-signed, repository-signed, Authenticode-signed, tamper-evident, or legally non-repudiable by default.

If package signing is adopted in a later release, update SECURITY.md, stable release validation guidance, the active release-readiness record, release notes, supply-chain documentation, and this consumer verification guide before publishing public wording that claims signed package artifacts.

Consumer copy/paste validation checklist

AsiBackbone 3.0.0 package verification checklist

[ ] Package source is NuGet.org or the expected GitHub Actions release artifact set.
[ ] Package ID is one of the expected AsiBackbone.* package IDs.
[ ] Package version is 3.0.0.
[ ] Package target framework assets are net10.0.
[ ] Consumer host uses a .NET 10 SDK/runtime or later.
[ ] Package license, project URL, repository URL, and repository type metadata are present and expected.
[ ] Repository commit metadata is present after NuGet publish / Source Link validation.
[ ] Package SBOM exists for the consumed .nupkg when produced by the workflow event.
[ ] sbom-manifest.json maps the package to the expected SBOM and package hash when produced.
[ ] Package/SBOM provenance attestation exists when the workflow event supports it.
[ ] SBOM/provenance evidence comes from the same workflow run or release event as the package artifact under review.
[ ] NuGet package signing is understood as deferred for 3.0.0.
[ ] No internal release notes describe the package as maintainer-signed, repository-signed, Authenticode-signed, tamper-evident, or legally non-repudiable by default.
[ ] Consumer-specific source review, vulnerability scanning, package-cache controls, and compliance approval are complete.

Release notes copy/paste checklist

3.0.0 consumer verification posture:

- Confirm package source, expected AsiBackbone.* package IDs, package version 3.0.0, and net10.0 target assets.
- Confirm the consumer host uses a .NET 10 SDK/runtime or later.
- Confirm NuGet package metadata, including license, project URL, repository URL, repository type, and repository commit metadata where available.
- After publish, run Source Link metadata validation:
  ./scripts/Validate-Source-Link-commit-metadata.ps1 -Version 3.0.0
- Review package SBOMs and sbom-manifest.json when generated by the workflow.
- Review package/SBOM provenance attestations when supported by the workflow event.
- Treat SBOM/provenance as release evidence, not as maintainer package signing, Authenticode signing, production tamper-evidence, legal non-repudiation, vulnerability clearance, or compliance approval.
- NuGet package signing remains deferred unless a reviewed signing process is adopted and documented before release.
Edit this page