Add dependency review workflow

[znrac137]

Summary

Adds a GitHub dependency review workflow for pull requests.

This workflow checks dependency changes introduced through PRs using GitHub's dependency-review-action. It fails when a PR introduces a dependency with a known high or critical vulnerability across runtime, development, or unknown scopes.

This is separate from the existing Grype workflow. Grype scans the broader repository dependency/security state, while dependency review focuses on new dependency changes introduced by pull requests.

Changes

• Added .github/workflows/ci.dependency-review.yml
• Added docs/DevSecOps/dependency-review.md
• Kept .github/workflows/ci.grype.yml unchanged
• Configured the workflow to run on pull requests
• Added high/critical severity gating
• Added PR failure summary support where token permissions allow

Testing

• Local actionlint validation passed
• Git diff whitespace check passed
• Configured inputs were verified against dependency-review-action v5
• Dependency Review check passed on the clean implementation PR
• A temporary DO NOT MERGE test PR was created in my fork with lodash 4.17.18
• The test PR failed as expected after Dependency Review detected high severity vulnerabilities and showed patched versions
• Grype was not modified

[znrac137]

Dependency Review check is passing on this PR.

The two current failing checks appear unrelated to this change:

• Gitleaks Secret Scan (Full History) is scanning repository history and reports existing findings outside the two files changed in this PR.
• Preview Instructions appears to fail with a 403 permission issue when trying to post preview instructions from a fork PR.

This PR only adds:

• .github/workflows/ci.dependency-review.yml
• docs/DevSecOps/dependency-review.md

Grype was not modified.

[akshitpatel1732]

Nicely configured - using pull_request rather than pull_request_target avoids the usual security trap for this kind of workflow, the fail-on-severity/scopes coverage is complete, and testing this against a real vulnerable lodash version in your fork rather than just trusting the config is exactly the right way to verify it.

One small thing: docs/DevSecOps/dependency-review.md's "Testing" section still says live pass/fail and PR-comment behavior haven't been tested yet, but your PR description describes exactly that test having been done. Looks like the doc wasn't updated after that later commit - could you update it?

Approving once that's fixed.

[znrac137]

Thanks for catching that. I have updated the Testing section in docs/DevSecOps/dependency-review.md to reflect the completed live testing.

It now mentions that the Dependency Review workflow passed on the clean implementation PR, and that a separate temporary DO NOT MERGE test PR in my fork introduced lodash 4.17.18 and failed as expected with high severity vulnerability findings and patched versions.

I also clarified that PR comment behaviour is permission-dependent, so the Actions job summary and check logs are the consistent source of results.

[akshitpatel1732]

Thanks for updating the docs with the real test results - that's exactly what was needed.

One more thing to fix: zizmor (from #414) is flagging line 18 - actions/dependency-review-action@v5 isn't pinned to a commit hash, which our blanket policy now requires. Worth knowing why this matters here specifically: @v5 is a floating branch on that action's repo, not a fixed tag, so it can move without any version bump - pinning to a hash is what actually locks it down.

Could you change it to:

uses: actions/dependency-review-action@a1d282b # v5.0.0

That's the current commit behind the v5 branch, in the same style as the SHA-pinning already used elsewhere (see #414's workflow for the pattern).

Approving once that's in.

[znrac137]

Thanks for explaining that. I have pinned actions/dependency-review-action to the fixed commit SHA for v5.0.0 as requested.

The workflow behaviour has not changed; this only locks the action reference to the commit hash to match the repository’s SHA-pinning policy.