Python security is gaining attention due to the still rising usage of Python. Python applications are not immune to common security flaws. So, security testing, especially static application security testing (SAST) on Python code, is recommended for everyone who shares code.
Both GitLab.com and GitHub.com offer the option to enable static application security testing (SAST) in your development environment.
The good news is that the largest code hosting platforms worldwide are aware of their responsibility to make our world a bit more secure and offer SAST scanning on code repositories. Some even for no cost. But should you use this?
Static application security testing (SAST) tools for Python find weaknesses in Python code so you can improve the code if needed. When integrated into a CI/CD pipeline, good SAST tools identify security issues before releasing a product. SAST security testing is cheap and very effective to prevent security disasters from a ‘shift-left‘ perspective.
Security issues found late in the development phase mean costly delays and potential vulnerabilities in released software. SAST scans integrated in a CI/CD happen automatically with each commit, giving you direct feedback.
Since I am always looking for ways to improve Python Code Audit(https://github.com/nocomplexity/codeaudit), I did a quick scan on the SAST service offered by GitLab.com . My observations:
- GitLab.com SAST capability is based on Semgrep. They call it a “Semgrep-based analyzer.” Semgrep is a large company that long ago started with a FOSS scanner, but they abandoned the FOSS philosophy, and now Semgrep is a typical VC-funded company. So closed source, high prices, and embraced ‘AI’ in their marketing jargon. Since most code is not public anymore, no one can inspect how the product works nowadays.
- Since the SAST scanning is sort of a ‘Semgrep’ clone, it is not engineered specifically for Python code. Every programming language is different when it comes to detecting weaknesses, and creating a tool requires deep insights into how a programming language works to do detection well.
- The basic ‘rules’ for Python that are enabled by default are one-to-one copies of the FOSS SAST tool Bandit. So old rules, not maintained, and certainly not complete for checking your Python code against the Python Standard Library (PSL).
- Running the SAST tests is not easy to set up. Fortunately, there is extensive documentation with examples on how to enable SAST scanning for your Python code that is in your CI/CD workflow when your code is hosted on GitLab.com .
- Scan reports in JSON are, to put it mildly, quite meaningless. See e.g., this sample report. Cyber security is already complex enough, so why not provide meaningful, readable reports that can be shared, discussed, and acted upon?
- Cloud-based: So you have no control over many aspects. And all investments you make mean that a transition to another hosting platform gets more difficult and expensive.
- Creating your own SAST scan rules is possible, but not in the ‘free’ tier. Also, adding custom rules for SAST scanning is time-consuming and results in more maintenance work. Sharing SAST rules with other companies or with FOSS communities, which should be the norm, is not possible. So, transparency is lacking when companies use this kind of proprietary SAST scanning.
- GitLab.com offers all kinds of capabilities that you may want to use for your SAST scanning as premium features. So, you have to pay more to be more secure. This should not be the way security products work in 2026! The security of your Python code should not depend on your budget!
Based on these observations:
I would not recommend anyone to use the SAST scanning product of GitLab.com for Python code!
So consider using Python Code Audit (https://github.com/nocomplexity/codeaudit); it has many default scan rules and is 100% open source and free to use. You can integrate Python Code Audit easily into your CI/CD pipeline, but you keep full control at no cost. Check the documentation.