feat(security): supply-chain security — SBOM, dependency pinning and provenance verification

📌 Overview

Nester's code is a small fraction of what actually runs in production — the rest is dependencies: Go modules, npm packages, Rust crates, Python packages, and the base images and CI actions that build and ship everything. Each is code Nester did not write but fully trusts, and the supply chain is one of the most actively exploited attack surfaces in modern software: a compromised package version, a typosquatted dependency, a malicious update to a transitive dependency, or a poisoned CI action can inject code that steals keys or drains funds, and it does so through the front door of the build where ordinary code review never looks. Issue #794 re-enables Dependabot for update automation, which is necessary but addresses only staying current — it does not address knowing exactly what is in the build, verifying it is what it claims to be, or preventing a malicious dependency from entering.

This issue builds supply-chain security: a Software Bill of Materials (SBOM) for every artifact, strict dependency pinning and integrity verification, provenance checks on dependencies and CI actions, and automated scanning that blocks known-vulnerable or suspicious dependencies before they ship. It hardens the part of the attack surface that code review cannot see.

🎯 Objectives

• Generate a complete SBOM for every build artifact so what ships is fully known.
• Pin dependencies and verify integrity so builds are reproducible and tamper-evident.
• Verify provenance of dependencies and CI actions to resist supply-chain injection.
• Scan for known-vulnerable and suspicious dependencies and block on policy.
• Cover every ecosystem in the monorepo: Go, npm, Rust, Python, and CI/containers.

🧩 Requirements

Generate an SBOM (CycloneDX or SPDX format) for each deployable artifact — the Go API, the frontend, the intelligence service, and the contracts — enumerating every direct and transitive dependency with versions and hashes. The SBOM is produced in CI on every build and retained, so for any deployed version there is an exact, queryable record of its contents. When a new vulnerability is disclosed in some package, the SBOM answers "are we affected, and where?" in seconds instead of a frantic manual audit.

Pin and verify. Dependencies are pinned to exact versions with integrity hashes (Go's go.sum, npm lockfile with integrity, Cargo.lock, Python hashes), and the build verifies those hashes so a dependency whose content changed for a pinned version is rejected — this is what makes a build reproducible and tamper-evident. CI actions must be pinned to a commit SHA, not a mutable tag: a @v4 tag can be repointed to malicious code by whoever controls the action, while a SHA cannot. Audit the workflows (.github/workflows/) and pin every third-party action to a SHA.

Provenance verification where available: prefer dependencies and actions that publish build provenance/attestations, and verify them. For the highest-value dependencies, this raises assurance that the artifact was built from the claimed source. Document which dependencies have verified provenance and which are trusted on hash-pinning alone.

Automated scanning with policy gates: integrate vulnerability scanning across all ecosystems into CI (there is a security workflow at .github/workflows/security.yml and gitleaks config to build on), and define a policy — a known critical/high vulnerability in a production dependency blocks the merge/release until remediated or explicitly, auditably waived (a .vulnignore exists; ensure waivers are justified and time-bounded, not permanent silent suppressions). Add typosquat/suspicious-package detection for new dependencies so a malicious lookalike is caught at introduction.

Introduction control: adding a new dependency is a security decision. Require that new dependencies pass the scans and, for significant additions, a brief review of the package's provenance and health. This is process backed by CI gates, not a manual hope.

⚙️ Technical Notes

SBOM generation, scanning and provenance checks are primarily CI work in .github/workflows/ — extend .github/workflows/security.yml and the main CI (.github/workflows/ci.yml) and contract audit (.github/workflows/contract-audit.yml). Use ecosystem-appropriate tooling (document the chosen scanners/SBOM generators) covering Go modules, the frontend npm tree, the Rust contracts (Cargo), the Python intelligence service, and container base images. Pin all third-party actions to SHAs across every workflow. Coordinate with Dependabot (#794) so automated updates and this gating work together — Dependabot proposes updates, these gates verify them. The existing .gitleaks.toml/.gitleaksignore and .vulnignore are the starting policy surface; ensure ignore entries are justified and reviewed.

Document the supply-chain policy — SBOM retention, pinning rules, action-SHA requirement, scan gates, waiver process, and new-dependency review — in SECURITY.md.

Because most of this is CI/config, "tests" here means verifiable CI behavior: a build produces an SBOM artifact; a seeded known-vulnerable dependency fails the gate; an unpinned or SHA-mismatched action is flagged; a typosquat-shaped new dependency is caught; and a waiver requires justification. Validate these on a branch before merging.

📦 Expected Outcome

Every Nester build produces a complete, retained SBOM, so the exact contents of any deployed version are known and vulnerability exposure is answerable instantly. Dependencies across all ecosystems are pinned with verified integrity, CI actions are pinned to SHAs, and provenance is verified where available. Automated scanning blocks known-vulnerable and suspicious dependencies before they ship, with auditable, time-bounded waivers. Adding a dependency is a gated decision. The invisible supply-chain attack surface is brought under the same scrutiny as the code itself.

✅ Acceptance Criteria

• An SBOM (CycloneDX/SPDX) is generated in CI for the API, frontend, intelligence service and contracts, and retained per build.
• Dependencies are pinned with integrity hashes across Go, npm, Rust and Python, and builds verify them.
• All third-party CI actions are pinned to commit SHAs, not mutable tags, across every workflow.
• Provenance/attestations are verified where available, with the coverage documented.
• CI vulnerability scanning covers all ecosystems and container base images and blocks on a known critical/high in a production dependency; a seeded-vulnerable-dependency test fails the gate.
• Typosquat/suspicious-package detection flags a malicious lookalike on introduction.
• Waivers (.vulnignore etc.) require justification and are time-bounded, not permanent silent suppressions.
• The supply-chain policy is documented in SECURITY.md, and the CI behaviors above are verified on a branch.

🚨 Contribution Rule

• All PRs MUST target the dev branch
• PRs opened against main will be automatically rejected
• Ensure your branch is created from dev