You have three practical options: generate an SBOM with another tool and import it, keep a manual inventory with proper identifiers, or add a second scanner for that ecosystem. Whichever you choose, document the gap so no one reads an empty result as a clean one.
First, confirm it is really unsupported
Check the documentation and run a canary, as described in plant a known vulnerable package to test scanner coverage. Sometimes the ecosystem is supported through lockfiles but not through raw manifests, or only in newer versions of the tool.
Option 1: import an SBOM
Many package managers and build tools can emit an SBOM in CycloneDX or SPDX. If your scanner accepts SBOM input, import it and the platform can match advisories against the components, even without native parsing.
What this needs: components with correct Package URL identifiers. The Package URL specification defines a standard identifier format that works across ecosystems, which is what makes cross tool matching possible. See SCA supplier SBOM import: what to test.
Option 2: a manual inventory
For small or niche dependency sets, a reviewed text file can be enough.
- List each dependency with name, exact version and source.
- Give each a purl where one exists.
- Convert the list into a minimal SBOM file.
- Review it on every release, and when an advisory lands, search it first.
This costs effort but works for a handful of components. It fails at scale.
Option 3: a second tool for that ecosystem
If the ecosystem is a major part of your code, a specialised tool may serve it better. The cost is extra reports. Mitigate by merging output, for example through SARIF, as covered in bring results from many scanners together with SARIF.
Choosing between them
| Situation | Best fit |
|---|---|
| Build tool already emits an SBOM | Import |
| Fewer than a few dozen dependencies | Manual inventory |
| Large codebase in that ecosystem | Second tool |
| Short term gap while vendor adds support | Import or manual |
Whatever you pick
- Write the gap into your coverage statement with the date.
- Assign an owner for the workaround, since it will not run itself.
- Retest when the scanner updates.
Try it yourself
Click through it at your own pace, or open it full screen. Notice that the inventory is just components with names and versions, which any source can supply.
Safeguard offers SBOM and dependency scanning and a free scan at gold.safeguard.sh/scan. Check supported ecosystems for your stack before relying on any result.
Quick check
Is an SBOM import as good as native scanning?
It can match advisories well if the SBOM has exact versions and identifiers. It will not find code the SBOM omits.
Should I wait for the vendor to add support?
Do not leave the code unmeasured meanwhile. Use a workaround and revisit.
Sources
Last reviewed: 19 October 2026.
