Supply Chain Policy

This document defines the minimum dependency and release-hardening policy for corsa-bind.

Rust Dependency Gates

  • cargo deny check advisories bans licenses sources is the required CI gate for Rust dependencies.
  • Pull requests should not merge while cargo-deny is failing.
  • Releases should not proceed unless the same cargo-deny gate is green.

Advisory Handling

When a Rust advisory or policy violation appears:

  • prefer upgrading or replacing the dependency first
  • if a temporary exception is necessary, record it in deny.toml with a short comment and an issue or upstream reference
  • remove temporary exceptions as soon as the dependency graph allows it

Releases should be blocked for unresolved critical advisories unless there is a documented and reviewed exception.

npm Dependencies

The repository publishes public npm packages and uses npm Trusted Publishing from GitHub Actions rather than long-lived automation tokens.

npm dependency hygiene is handled through:

  • lockfile review in pull requests
  • Dependabot updates
  • pnpm pack plus npm publish --dry-run validation during release checks
  • npm Trusted Publishing with provenance generated by npm for public releases

After Trusted Publishing is enabled for a package, token-based publishing should be disabled in that package's npm settings.

Release Hardening

Before publishing public Rust crates, the manual publish workflow is expected to pass:

  • workspace checks and linting
  • cross-surface test coverage
  • pinned upstream verification
  • benchmark guards
  • cargo-deny
  • release dry-run validation

Before publishing public npm packages, the npm trusted publish workflow is expected to pass the same release dry-run validation and use GitHub-hosted runners with OIDC enabled.

Release workflows generate SPDX 2.3 JSON SBOMs with scripts/generate_sbom.ts:

  • publish-rust uploads rust-sbom for the crate dependency inventory
  • publish-npm uploads npm-sboms, including npm package metadata and each native binding target SBOM
  • the Supply Chain workflow uploads a workspace-sbom artifact on PRs, default-branch pushes, scheduled runs, and manual runs

Downstream users should download the SBOM artifacts from the GitHub Actions run that produced the release and compare the workflow run, tag, and GitHub provenance metadata before importing the inventory into vulnerability tooling.

OpenSSF Scorecard Monitoring

The OpenSSF Scorecard workflow runs weekly on the default branch and can also be run manually when repository settings change. It is intentionally not a required pull-request status check, because it monitors repository posture over time rather than validating an individual code change.

The workflow uses explicit job-level permissions and pinned action SHAs. Scheduled runs publish results to the public Scorecard API through GitHub OIDC. Manual runs generate the same SARIF artifact, but do not publish over the experimental manual Scorecard path.

For this public repository, SARIF is uploaded to GitHub Code Scanning. If this workflow is reused in a private repository, enable GitHub Advanced Security and Code Scanning first, then set the repository variable CORSA_ENABLE_SCORECARD_SARIF_UPLOAD=true. Without that setup, the SARIF artifact remains available from the workflow run for short-term inspection, but the Code Scanning upload step stays disabled.