I ran a dependency scan on Commitizen while looking at tools that are commonly used in developer and release workflows.
For context, I’m the maintainer of an OWASP-adopted CLI called CVE Lite CLI. It focuses on scanning lockfiles locally and surfacing actionable fixes rather than just listing advisories.
The CLI uses the existing package-lock.json, so no setup or API keys are needed.
What stood out:
- 48 findings in total
- includes critical and multiple high severity issues
- some vulnerabilities are in direct dependencies, not just transitive ones
- a few issues have clear upgrade paths, others are harder to resolve
The tool was able to suggest a concrete fix plan:
npm install minimist@1.2.6 lodash@4.18.0 semver@7.5.2 @octokit/request@5.6.3 npm@10.9.6 @babel/traverse@7.23.6
A couple of examples:
minimist@1.2.5 has a critical vulnerability, fix available at 1.2.6lodash@4.17.21 requires upgrading beyond the advisory hint (validated safe version is 4.18.0)semver shows up in multiple vulnerable versions across the tree
One thing I found interesting is that advisory “fixed versions” are not always reliable. In a few cases, versions marked as fixed were still vulnerable, so the safe upgrade required additional validation.
CVE Lite CLI also has a GitHub Action, so this kind of scan can run locally during development or in CI as a lightweight dependency security check.
I’m not raising this as a strict issue to fix everything, more sharing the findings and the approach. Since Commitizen is used directly in developer workflows, this felt like a useful data point.
For reference, here’s a snapshot of the report view highlighting the findings and suggested fix paths:
Curious how you currently think about dependency security here, whether this kind of pre-release/local check would be useful alongside existing tooling.
Happy to share more details if helpful.
I ran a dependency scan on Commitizen while looking at tools that are commonly used in developer and release workflows.
For context, I’m the maintainer of an OWASP-adopted CLI called CVE Lite CLI. It focuses on scanning lockfiles locally and surfacing actionable fixes rather than just listing advisories.
The CLI uses the existing
package-lock.json, so no setup or API keys are needed.What stood out:
The tool was able to suggest a concrete fix plan:
A couple of examples:
minimist@1.2.5has a critical vulnerability, fix available at1.2.6lodash@4.17.21requires upgrading beyond the advisory hint (validated safe version is4.18.0)semvershows up in multiple vulnerable versions across the treeOne thing I found interesting is that advisory “fixed versions” are not always reliable. In a few cases, versions marked as fixed were still vulnerable, so the safe upgrade required additional validation.
CVE Lite CLI also has a GitHub Action, so this kind of scan can run locally during development or in CI as a lightweight dependency security check.
I’m not raising this as a strict issue to fix everything, more sharing the findings and the approach. Since
Commitizenis used directly in developer workflows, this felt like a useful data point.For reference, here’s a snapshot of the report view highlighting the findings and suggested fix paths:
Curious how you currently think about dependency security here, whether this kind of pre-release/local check would be useful alongside existing tooling.
Happy to share more details if helpful.