DependencyTrack / DependencyTrack/dependency-track
OSV npm vulnerability not matched: MAL-2022-1471 for pkg:npm/bats-file@0.2.0
- Dominant language
- Java
- Stars
- 4.2k
- Forks
- 811
- Avg merge
- 8h 39m
- Merged PRs (30d)
- 237
Description
## Description
DependencyTrack 4.13.6 is not matching OSV npm vulnerabilities to components when the vulnerability uses SEMVER range notation with `"introduced": "0"`.
## Environment
- **DependencyTrack Version**: 4.13.6 (apiserver)
- **Deployment**: Kubernetes (Helm chart 0.40.0)
- **Database**: PostgreSQL (Cloud SQL)
- **OSV Mirroring**: Enabled with npm ecosystem
- **Internal Analyzer**: Enabled
## Steps to Reproduce
1. Enable OSV vulnerability source with npm ecosystem in Administration → Vulnerability Sources → Google OSV Advisories
2. Wait for OSV npm download to complete (or restart apiserver)
3. Add component `pkg:npm/bats-file@0.2.0` to a project via SBOM upload
4. Trigger vulnerability analysis (re-analyze project or upload new SBOM)
5. Check component vulnerabilities
## Expected Behavior
The component `pkg:npm/bats-file@0.2.0` should show vulnerability **MAL-2022-1471** from OSV.
OSV vulnerability data:
- **ID**: MAL-2022-1471
- **Package**: pkg:npm/bats-file
- **Range**: `{"type": "SEMVER", "events": [{"introduced": "0"}]}`
- **Source**: https://osv.dev/vulnerability/MAL-2022-1471
This range should match ALL versions including 0.2.0.
## Actual Behavior
The component shows **zero vulnerabilities**.
**API Evidence:**
Vulnerability exists in database:
\`\`\`bash
GET /api/v1/vulnerability/source/OSV/vuln/MAL-2022-1471
\`\`\`
Response shows:
\`\`\`json
{
"vulnId": "MAL-2022-1471",
"source": "OSV",
"affectedProjectCount": 0,
"affectedComponents": [
{
"identityType": "PURL",
"identity": "pkg:npm/bats-file"
}
]
}
\`\`\`
Component exists with correct PURL:
\`\`\`bash
GET /api/v1/component/{uuid}
\`\`\`
Response shows:
\`\`\`json
{
"name": "bats-file",
"version": "0.2.0",
"purl": "pkg:npm/bats-file@0.2.0",
"vulnerabilities": null
}
\`\`\`
## Root Cause
DependencyTrack's version matching logic cannot properly parse OSV's SEMVER range notation `{"introduced": "0"}` to match it against component version `0.2.0`.
## Logs
OSV npm download completes successfully:
\`\`\`
2026-01-18 13:31:01,452 INFO [OsvDownloadTask] Updating datasource with Google OSV advisories for ecosystem npm
\`\`\`
Analysis runs but only shows Internal and OssIndex analyzers, no separate OSV analyzer:
\`\`\`
2026-01-19 12:59:56 INFO [InternalAnalysisTask] Internal analysis complete
2026-01-19 13:00:24 INFO [OssIndexAnalysisTask] Sonatype OSS Index analysis complete
\`\`\`
## Related Issues
This appears to be related to #2826 (Add support for \`vers\` version ranges and ecosystem-specific version comparisons), which mentions:
> "The version comparison logic DT has today is generic and is struggling to deal with versioning schemes that are specific to certain ecosystems."
## Impact
OSV is a critical data source for detecting malicious npm packages, supply chain attacks, and other vulnerabilities not covered by traditional CVE databases. Without proper version range matching, OSV integration is severely limited for npm ecosystems.
## Workaround
None identified. Re-uploading SBOMs and re-analysis do not resolve the matching issue.
Contributor guide
Assessment
This issue has not been assessed yet.