Top 5 Open Source Tools to Scan Your Code for Vulnerabilities

When you write code, bugs are expected. But security vulnerabilities? Those can cost you.

Security issues open the door to exploits, data leaks, and even complete system breaches.

The good news is, you don’t need to spend a fortune to secure your code. Open source tools can do the job well — and they’re free.

I’ve picked five of the best ones you can start using right now. Let’s break down what each one does, why it matters, and how it fits into your workflow.

Semgrep — Fast, Flexible Static Analysis

GitHub: https://github.com/returntocorp/semgrep

Think of Semgrep like a security-aware search engine for your code.

It scans source files quickly, and checks them against rules that look for common bugs, misconfigurations, and vulnerable patterns.

What makes Semgrep stand out is how easy it is to customize. You can write your own rules in YAML. These rules are readable, even for folks who don’t know formal parsing systems.

For example, usingeval() in Python is dangerous because it can execute arbitrary code, making it a major security risk. Want to flag use of eval() in Python? You can write a rule for that in minutes.

Semgrep supports many languages: Python, JavaScript, Go, Java, and more. You can plug it into your CI/CD pipeline using a simple command-line interface.

Semgrep is also blazing fast. This matters when you’re pushing code several times a day.

Here’s a quick example of a Semgrep rule that looks for hardcoded passwords in Python:

rules:
  - id: hardcoded-password
    pattern: password = "$SECRET"
    message: "Avoid hardcoded passwords."
    severity: ERROR
    languages: [python]

Why does this matter? Because catching these mistakes before production can stop a security breach before it starts.

CodeQL — Deep Query-Based Code Analysis

GitHub: https://github.com/github/codeql

CodeQL is a bit different from the rest. Instead of scanning your code with predefined patterns, it lets you write queries about how your code behaves.

You can think of CodeQL like a database, but your tables are made of code elements — functions, variables, and data flows.

That makes it powerful. You can ask questions like, “Are there any functions where user input reaches a SQL execution call without sanitisation?” and get precise answers.

Here’s a simple CodeQL query that finds functions in JavaScript code that have too many parameters (e.g., more than 3), which can be a sign of poor design.

/**
 * @name Functions with too many parameters
 * @description Finds functions that take more than 3 parameters.
 * @kind problem
 */

import javascript

from Function f
where f.getNumberOfParameters() > 3
select f, "This function has too many parameters."

It works with languages like JavaScript, Python, Java, C++, and C#. GitHub uses CodeQL to scan public repositories for vulnerabilities, and security researchers use it to find zero-day vulnerabilities.

CodeQL takes more effort to learn, but once you get the hang of it, you can find deep, complex bugs — ones that attackers rely on slipping past normal static analyzers.

OWASP Dependency-Check — Know Your Libraries

GitHub: https://github.com/dependency-check/DependencyCheck

Most modern codebases pull in third-party libraries. That’s fine — until one of those libraries has a known security issue.

Attackers often target these weak spots because they’re easier to exploit than your own code.

OWASP Dependency-Check helps with this. It scans your project’s dependencies and flags ones with known vulnerabilities, using data from CVE (Common Vulnerabilities and Exposures) databases.

This tool works across ecosystems. It supports Java (Maven, Gradle), .NET (NuGet), Node.js, and more.

You can run it as a CLI tool or integrate it into your build process. That way, you can fail builds that use insecure packages before they reach production.

Here’s what a basic usage might look like in a Maven project:

dependency-check --project my-app --scan ./ --format HTML

The tool will generate a report that lists every vulnerable dependency, along with links to CVE entries. That gives you a clear picture of your project’s risk level.

Gitleaks — Secrets Scanner for Git Repos

GitHub: https://github.com/gitleaks/gitleaks

Hardcoded API keys, passwords, tokens — these can all end up in your Git history by mistake.

Once they’re committed, they’re hard to remove and can expose you to serious risks. That’s where Gitleaks comes in.

Gitleaks scans your Git repositories for secrets. It looks through commits, branches, and file changes to spot sensitive data.

You can run it before pushing code or hook it into your CI to block dangerous commits.

Using it is simple. Run a command like this:

gitleaks detect --source . --report-path gitleaks-report.json

It works across any language, since it’s looking at raw files and commit messages, not specific syntax. And it’s fast. You can scan big repos in seconds.

Gitleaks is an extremely useful tool to make sure that your secret keys or password don't end up in the github repository for everyone to view.

Bandit — Python-Specific Security Scanning

GitHub: https://github.com/PyCQA/bandit

If you write Python, Bandit is for you.

It’s built to catch security issues in Python code, like the use of weak cryptography, unsafe imports, or functions like os.system()(runs shell commands directly, leading to command injection attacks)

It’s lightweight and easy to use. You can run it on a file or a full project:

bandit -r my_project/

Bandit checks for common Python security issues by walking your code’s abstract syntax tree.

That gives it a deeper understanding than a basic regex scanner. You get a report showing which files are risky, what issues they contain, and how severe they are.

Bandit is ideal for small and medium Python projects. You can even combine it with pre-commit hooks to catch issues before you commit.

Conclusion

Semgrep and Bandit help you scan your own code. CodeQL lets you ask deep questions about how your code behaves. OWASP Dependency-Check focuses on third-party libraries. And Gitleaks watches for secrets that slip into your repo.

You don’t need to use all five. Pick what fits your workflow. If you use Python, start with Bandit. If you depend on a lot of open source libraries, run Dependency-Check. Want full coverage? Combine two or three.

Security doesn’t have to be complicated. These tools make it easier. And they’re free. So there’s no excuse to ship insecure code.