feat: dependency-check-plugin-revision

[RichardUri]

Description

Revises and addresses review feedback on #799, adding dependency vulnerability scanner plugin.

The plugin is intended to intercept pushes and scans changed dependency files against the OWASP Vuln database. If a vulnerability is found at or above a severity threshold, the push will be held for review.

Made changes according to reviewer comments on original PR.
General changes:

• Severity threshold configured via DEPENDENCY_VULN_THRESHOLD environment variable (default: HIGH) rather than a top-level config schema entry
• Fixed git diff argument order (Previously showed removals instead of additions)
• Fixed git show using HEAD instead of the pushed commit SHA
• Fixed missing parent directory creation for nested file paths (e.g. src/lib/foo.json)
• deleteTempRepo now deletes the entire .tempRepo/ directory instead of only the current push's subdirectory
• Added exit code check for dependency-check to prevent silent false negatives on failure
• Replaced spawnSync for the clone operation with async spawn to avoid blocking
  the Node.js event loop
• Removed dead variables and unneeded aliases.
• Added Basic auth credential forwarding on the clone URL, similar one used in pullRemote processor
• Blocked message now includes CVE ID, severity, and description
• 'temporaryRepo.js' removed and is now directly included into the main file.
• Added exports entry and README documentation for the new plugin

Related Issue

Revises #799

Checklist

General

• I have read the CONTRIBUTING.md guidelines
• Commit messages follow Conventional Commits format
• I have a FINOS CLA on file

Documentation

• Documentation has been added/updated for any new features

Configuration

• If configuration schema (config.schema.json) was modified:
  • TypeScript types regenerated (npm run generate-config-types)
  • Schema reference docs regenerated (npm run gen-schema-doc)

Tests

• Tests have been added/updated for new functionality
• Unit tests pass (npm test)
• Linting and formatting pass (npm run lint and npm run format:check)
• Type checks pass (npm run check-types)

[netlify]

✅ Deploy Preview for endearing-brigadeiros-63f9d0 canceled.

Name	Link
🔨 Latest commit	7405dd1
🔍 Latest deploy log	https://app.netlify.com/projects/endearing-brigadeiros-63f9d0/deploys/6a00e521255cd40008d8f1aa

[kriswest]

It seems odd to have a plug-in to a complete extra clone of the repository and compute its own diff in order to run scanning tools on it, when when the built-in scanners already do both of these things... Can this not be written to use the data from the existing clone and diff operations?

[RichardUri]

@kriswest Yes, I thought it was strange in the original PR too. I believe it was structured this way because plugins are inserted at position 1 in the processor chain after parsePush so when the plugin executes, neither the bare clone nor the diff step exist yet. To reuse that data, I believe the plugin insertion point would need to move to later in the chain, after pullRemote and getDiff have run. I can take a look at changing that.

[jescalada]

LGTM - although as Kris mentioned, this seems more appropriate (and useful for the wider community) as a default processor rather than a plugin since we're pulling/scanning the diff. Is there a reason to keep it around as a plugin?

[jescalada]

We might want to check the result of spawnSync or wrap it in a try-catch. If unpacking silently fails then the subsequent diff would be empty and the plugin/processor would allow the push regardless of the actual contents.

[jescalada]

The code below mentions that we should set the dependencyVulnThreshold on the proxy.config.json, which I think is the cleaner solution. Should we perhaps replace the environment variable with the config entry (plugin array) for this plugin?