A supported languages page tells you what a vendor chose to list, not how well each item works. Treat it as a starting point. Check whether support means dependency scanning, code analysis or both, which frameworks and versions are covered, and test the scanner on your own repository.
Myth 1: Support means the same thing for every language
Fact: it rarely does. A vendor may analyse dependencies for twenty languages and run deep code analysis for five. The page may show one list with one tick. Ask for coverage broken out by capability.
| Capability | Question to ask |
|---|---|
| Dependency scanning | Which package managers and lockfile formats? |
| Static code analysis | Which rules exist for this language? |
| Secrets detection | Language independent or tuned? |
| Reachability | Which languages are covered? |
| Fix suggestions | Which languages get automated fixes? |
Myth 2: Listing a language means listing its frameworks
Fact: most real vulnerabilities in application code sit at the framework layer. A scanner may understand a language's syntax but know nothing about the web framework you use, so it misses injection paths through framework specific calls. Ask which frameworks have rules and how recently they were updated.
Myth 3: The newest language version is covered
Fact: language releases add syntax, and parsers lag. A scanner that fails to parse new syntax may skip files silently. Ask what the tool does with a file it cannot parse. The answer should be a visible warning with a count of skipped files, not nothing.
Myth 4: More languages means better coverage
Fact: breadth and depth trade off. If your estate is mostly two languages, the question is how deep the tool goes there. Compare your top languages by lines of code and put weight where your risk is. Our guide on checking scanner language and ecosystem support explains how.
Myth 5: Unsupported means unscanned
Fact: not always. A tool may still scan secrets, configuration files and container images in a repository for a language it cannot analyse. The reverse also holds, so ask for the exact behaviour.
Fact check procedure
- List every language and major framework you ship, with rough share of code.
- Mark which you must have and which you can live without. The knockout criteria post can help.
- For each must-have, ask the vendor to name the capabilities covered.
- Run the scanner on a real repository per language.
- Plant a known issue, such as a vulnerable dependency or an injection pattern, and confirm it is found.
- Check the report for skipped files and parse errors.
Write down the results for each language. That table becomes the real supported languages page for your team.
Quick check
Should I trust a vendor's language list?
Trust it as a claim to test. Ask for documentation and run a trial on your own code.
What if one niche language is unsupported?
Check whether dependency, secret and container scanning still work for it, and decide whether you can cover the gap another way.
Safeguard offers SBOM and dependency scanning and a free scan at gold.safeguard.sh/scan, which you can run on your own code to see coverage first hand.
Last reviewed: 19 October 2026.
