Dependency management policy

This policy covers the framework's Nix inputs, the minimal consumer fixture, documentation tooling, and GitHub Actions references.

Inventory and selection

  • Every tracked flake has a committed flake.lock; nested consumer fixtures are reviewed as independent dependency surfaces.
  • Inputs are selected for maintained upstream support, a compatible license, and a clear source. Lock entries use immutable revisions and hashes.
  • A dependency update records its compatibility impact, security impact, and any required migration in the pull request. Updates that change the public framework contract include a consumer fixture or contract test.
  • Actions and reusable workflows use full commit-SHA references. Dependabot keeps those references and the lockfiles current.

Automated evaluation

Pull requests run flake-lock validation, dependency review, CodeQL, repository hooks, and the native test matrix. Dependency review is configured to fail on low-or-higher severity findings when GitHub can analyze the repository's manifests. CodeQL findings and Nix evaluation failures block the merge queue.

Remediation and release gate

Malicious dependencies, known exploited vulnerabilities, high or critical SCA findings, and prohibited licenses block release. Low and medium findings are also resolved before release unless a maintainer records a time-bounded, non-exploitable exception in security/vex.json and links the analysis in the release notes. Exceptions name an owner, affected versions, compensating controls, and an expiry or review date.

Before tagging a release, review every changed lock entry, run the documented flake and consumer checks, and confirm that no unresolved SCA or license violation is included in the source archive.

Maintenance

Maintainers review dependency updates through pull requests. A stale or unmaintained dependency is replaced when a supported alternative exists; an unavoidable exception is documented with its operational and security risk.