A language on a vendor's supported list does not prove the tool understands your framework. Build an inventory of languages, versions and frameworks you actually ship, then test each on a real repository. OWASP lists framework understanding as a separate selection criterion from language support for this reason.
Why the list is not enough
Most modern applications are written in a language and then shaped by a framework. The framework decides how requests arrive, how input is bound, how templates render and how queries are built. A static tool that parses the language but not the framework may not know where untrusted data enters, or which calls clean it.
The result is either missed findings or a pile of false alarms. OWASP's source code analysis tools page names language support as the stated prerequisite and framework understanding as its own check.
Step 1: build an inventory
List every repository with:
- Primary language and version.
- Frameworks and major libraries, including the web framework and the data access layer.
- Build system.
- Whether it contains generated code.
- Whether it is deployed, a library, or a script.
Count repositories per language so you can weigh coverage by what matters. Ninety services in one language and two scripts in another make for an easy decision.
Step 2: mark the must-haves
Decide which stacks need first-class support and which can be covered later or by another tool. Mixed estates often end up with a main tool plus a lightweight option for odd corners. That is acceptable if you plan for it and know who owns the gaps.
Step 3: test each stack
For every must-have stack, pick a real repository and ask the vendor, or test yourself:
- Does the scan complete without special setup?
- Does the tool recognize where input enters in our framework, such as controller parameters or request objects?
- Does it recognize our standard sanitization or encoding helpers?
- Are findings explained in framework terms?
You can use planted test cases to check this. A safe, framework-standard query next to an unsafe one tells you a lot about whether the tool understands the idiom.
Step 4: ask about versions and updates
Frameworks change quickly. Ask how soon the vendor adds support for new major versions and how rules are updated. If your stack is moving to a new framework next year, put that in the evaluation now.
Step 5: keep the inventory current
Review the inventory every quarter. New services creep in with new languages. Track the share of repositories actually covered by a successful scan. It is a clearer measure than the list of supported languages.
Quick check
What if one stack is unsupported?
Decide whether to cover it with another tool, manual review or acceptance of the gap, and record the decision with an owner.
Do I need to test every repository?
No. One representative repository per must-have stack is enough for the evaluation.
Sources
Last reviewed: 19 October 2026.
