How to Choose a SAST Tool: Criteria and Checklist

The right SAST tool is not the one with the longest list of languages and rules, but the one that performs best on your own code: how many real vulnerabilities it finds, how much noise it creates, and how easily it fits into your build pipeline. The short path: write a list of requirements based on the six to seven criteria below, shortlist 2–3 candidates, and compare them on the same set of repositories.

What SAST should do and what it will not do

Static application security testing (SAST) analyses source or binary code without running the application and looks for paths along which untrusted data reaches dangerous functions: SQL injection, XSS, path traversal, insecure cryptography, hardcoded secrets. It works early, in the IDE or on the pull request, and points to the exact line. The OWASP DevSecOps Guideline recommends running SAST on pull requests, combining it with SCA for dependencies, and choosing a tool that matches the stack you use.

What SAST does not do: it does not see misconfigurations of the runtime environment, does not check vulnerabilities in third-party libraries (that is what SCA is for), and does not replace dynamic testing. For more on the boundaries between tool classes, see SAST, DAST, SCA and MAST: what is the difference.

Criteria for choosing a SAST analyser

1. Languages and frameworks of your own stack

A claim of “30+ languages supported” says nothing about depth. Some languages get support at the level of simple patterns, others get full data-flow analysis. Even the Semgrep documentation states plainly that support maturity differs from language to language. List the languages, frameworks and versions that are actually used in production systems, and test the analyser on them, not on the vendor’s demo projects. Also clarify whether you need analysis of mobile code, SQL dialects, 1C scripts, or legacy languages used in the core banking systems.

2. Accuracy: false positives and misses

This is the main criterion. An analyser that produces many false positives will be ignored by developers within a month. An analyser with misses creates a false sense of security. The depth of analysis affects both indicators: the Semgrep documentation notes that cross-file analysis yields fewer false and more true positives but takes longer, and that the Community edition analyses only within a function or file. Ask the vendor: is there inter-procedural and cross-file analysis, does the tool confirm vulnerabilities (for example, with a test request), and can you mark and suppress findings with a comment?

3. Integration into the development process

Check that the analyser works where your teams work:

• Version control and CI/CD: GitLab, GitHub, Bitbucket, Jenkins, TeamCity; availability of a CLI and REST API.
• Issue trackers: passing findings to Jira or an equivalent without manual copying.
• Pull request mode: incremental scanning of only the changed code, otherwise checks will take hours.
• IDE: plugins are useful but secondary to pull request integration.

For practical guidance on embedding these tools, read “DevSecOps: where to start”.

4. Deployment model and data handling

For banks, telecoms and the public sector in Central Asia, source code often cannot be sent to an external cloud. Find out whether there is a full on-premise installation (not a stripped-down version), whether it works in a closed network without internet access, and how rule updates are delivered. Some international platforms have a cloud product as their core offering, while on-premise is offered separately or in a limited form: for example, the Checkmarx One page presents the cloud platform as the main product and mentions on-premise SAST separately. Do not assume; request written confirmation.

5. Type of analysis: source code, binary code, composite analysis

If you have a lot of contractor code or legacy software without sources, binary analysis will be useful. If you need the full AppSec stack, check whether the platform offers SCA and DAST in the same interface. This simplifies reporting and licensing, although it is not always the best option for each class of analysis. Full-cycle platforms such as DerScanner combine SAST, SCA, DAST, mobile and binary analysis.

6. Reporting and compliance

Ask whether there are reports against the OWASP Top 10, PCI DSS and other standards that your auditors check, and whether results can be exported to SARIF or another machine-readable format. Some Russian solutions on the market hold FSTEC certification and are listed in the registry of Russian software. For companies in Kazakhstan and Uzbekistan these statuses are not mandatory in themselves, but they affect procurement requirements if you work with Russian partners.

7. Extensibility: custom rules

Your code contains internal frameworks and wrappers that the analyser does not know about. It is good if you can describe your own sources, sinks and sanitisers without involving the vendor. This substantially reduces noise on a mature project.

8. Total cost of ownership

Licensing models (per developer, per line of code, per project, per scanning server) behave very differently as you grow. Not all vendors publish prices; for many enterprise solutions the cost is quoted on request. Count not only the licence but also the infrastructure, the effort to triage findings, and support. For more, see open-source or commercial AppSec tools.

Checklist for comparing candidates

• Languages: all your languages and versions are tested on real code.
• Accuracy: the share of confirmed vulnerabilities among findings is calculated on a reference sample.
• Misses: on a repository with known vulnerabilities (from past penetration tests), it is verified that the known defects are found.
• CI/CD: pull request scanning completes within an acceptable time.
• Deployment: on-premise or cloud operation is confirmed in documentation.
• Reports: the format suits both auditors and developers.
• Rules: you can write your own.
• Support: the language, time zone and response times of technical support are acceptable.
• Cost: a commercial offer has been received with a three-year calculation.

How to test the analyser on your own code

Practice shows that vendor presentations and online reviews do not replace a pilot. The algorithm is simple:

1. Choose 3–5 repositories: different languages, different teams, and one project with known vulnerabilities.
2. Scan them with every candidate using default settings, then with tuned settings.
3. Review a random sample of findings together with developers and mark true and false positives.
4. Measure the scanning time for a full repository and for a pull request.
5. Assess the effort required for installation, configuration and updates.

How to organise such a check week by week is described in the article “How to run a SAST and SCA pilot in 30 days”. If you are comparing specific products, see the SAST tools comparison.

Common mistakes when choosing

• Choosing by the number of rules or languages. What matters is not the quantity but the quality on your stack.
• Testing on the vendor’s demo project. It is deliberately selected to show the product’s strengths.
• Ignoring developers. If they do not take part in the choice, they will work around the tool.
• Enabling all rules at once. Start with the critical vulnerability classes and widen the set gradually.
• No owner of the process. Someone must triage findings and assign fixes, otherwise the scanner becomes a source of noise.

Roles in the choice: who is responsible for what

Choosing a SAST tool is a team task, and each role has its own set of questions. The information security specialist is responsible for coverage of vulnerability classes, reporting and compliance. The head of development looks at scanning speed, convenience for developers and the impact on release timelines. The DevOps engineer checks pipeline integration, server requirements and the update procedure. The finance director is interested in the licensing model and the total cost. If any of these people are missing from the process, problems will surface after the purchase: developers will refuse to work with the tool, and the infrastructure will not cope with the load.

It helps to agree in advance who makes the final decision and on which criteria. A simple weighted table, where each criterion from the list above gets a weight, prevents disputes: scores are assigned based on the pilot results, not on an impression from a presentation.

Frequently asked questions

Sources

• OWASP DevSecOps Guideline: Static Application Security Testing
• Semgrep Docs: Semgrep Code overview
• Semgrep on GitHub
• Checkmarx One: platform overview
• Anti-Malware.ru: review of PT Application Inspector 4.0