// HackTricks · Network Services

Source Code Review / SAST Tools

Source Code Review / SAST Tools

Guidance and tool lists

C/C++ Manual Review Gotchas

When reviewing C/C++ manually, look for APIs and patterns that appear safe in isolation but become exploitable when their outputs are reused later in the control flow.[1][2]

Non-reentrant libc return buffers breaking security checks

Some legacy networking/string helpers return pointers to static internal storage. A classic example is inet_ntoa(): storing the returned pointer and calling the function again usually means the second call overwrites the same buffer.

char *user_ip = inet_ntoa(addr_from_user);
char *allowed_ip = inet_ntoa(addr_from_policy);

if (strcmp(user_ip, allowed_ip) != 0) {
    return DENY;
}

This kind of code can silently collapse an allowlist / equality check because both pointers may reference the same final string. During review, treat these APIs as suspicious whenever the returned pointer is:

  • stored for later comparison
  • reused across branches
  • relied on for policy decisions such as SSRF prevention or host allowlists

Prefer APIs that write into a caller-provided buffer (inet_ntop, snprintf, explicit copies with fixed bounds).

Validated input reused later in system() / shell-outs

A frequent review failure is validating input with a parser and later reusing the original raw string in a shell command:

if (!inet_aton(ip_addr, &parsed)) {
    return 1;
}

snprintf(cmd, sizeof(cmd), "ping '%s'", ip_addr);
system(cmd);

Parsing the data does not make the original string safe. If execution reaches system(), popen(), execl("/bin/sh", ...), or similar shell-backed helpers, metacharacters in the original input can still become command injection / RCE.

During review, check for this sequence:

  1. Input is parsed or normalized into a structured object.
  2. A security decision is made using the parsed form.
  3. The original string is later passed to a shell.

Safer patterns:

  • avoid the shell entirely
  • use execve()/posix_spawn() with a fixed argv array
  • derive the executed argument from the validated canonical form instead of the original input

User-controlled registry/config source steering kernel control flow

In Windows driver code, a user-chosen registry path or similar configuration source should not directly influence privileged control flow. Review patterns such as:

  • WdfRequestRetrieveInputBuffer or IOCTL input supplying a registry path
  • RtlQueryRegistryValues(..., RTL_QUERY_REGISTRY_DIRECT, ...) writing directly into stack/local variables
  • queried values selecting callbacks, operation modes, or other security-sensitive branches

If the attacker controls the key path, they often control not only the data but also the value type, size, and presence/absence semantics. That can turn a “read config and choose a callback” workflow into reliable DoS and sometimes a kernel code execution primitive.

Red flags during review:

  • absolute registry paths accepted from user mode
  • no allowlist of trusted hives/keys
  • no strict type/length validation before copying into integers/structs
  • registry-derived values stored globally and later used as function pointers, dispatch selectors, or capability flags

Windows path handling footguns worth checking

For Windows usermode reviews, explicitly audit for:[1][2]

  • unquoted path issues in CreateProcess* call sites and service definitions
  • ANSI/Wide-char mismatches that let Unicode characters transform during path canonicalization
  • WorstFit / Best-Fit style issues where ANSI APIs reinterpret Unicode into separators or traversal primitives[3]

These are especially relevant when a path passes through validation in wide-char form but is later consumed by an ANSI API or command line builder.

Multi-Language Tools

Naxus - AI-Gents

There is a free package to review PRs.

Agentic SAST pipelines

Modern AI-assisted code review works better as a staged pipeline than as a single scan this repo prompt. A practical pattern used by tools such as Visa Vulnerability Agentic Harness (VVAH) is:[4][5]

Large defensive initiatives such as Project Glasswing also illustrate the growing use of frontier models for vulnerability discovery, but model output still needs evidence-based human validation before remediation.[7]

  1. Threat-model first: inventory entrypoints, assets, trust boundaries, API boundaries, authz paths, taint candidates and reachable components before deep review. If available, enrich this with CMDB / known-CVE / control data so the model prioritizes realistic attack paths instead of isolated code smells.
  2. Split research by lens: run separate passes for access control, business logic, crypto, deserialization, IaC, batch/ETL, or language-specific sinks instead of trusting one generic review.
  3. Require deterministic gates: only promote a finding if it survives policy checks such as evidence completeness, majority voting, or repeated independent review.
  4. Add adversarial verification: force a second pass that tries to prove the trust-boundary crossing and exploitability: attacker-controlled input, source-to-sink reachability, missing authorization, privilege boundary crossed, and realistic impact.
  5. Report chains, not only single bugs: deduplicate related findings, map them to CWE/CVSS, and emit SARIF so the output can be ingested by code-scanning and vuln-management platforms.

This usually produces fewer but higher-signal triage candidates and is especially useful in large repos where the bottleneck is analyst triage time rather than raw finding count.

Quick start example with vvaharness

python3 -m venv .venv
source .venv/bin/activate
pip install .
vvaharness doctor
vvaharness estimate --repo /path/to/target
vvaharness scan --repo /path/to/target --application-id 12345

Useful operational details:

  • vvaharness scan --resume skips completed checkpoints after an interruption.
  • Per-target output is written under <target>/security-scan/ as Markdown reports, *.sarif, and *_errors.jsonl.
  • Treat results as triage candidates, not confirmed vulns: this kind of pipeline is best at prioritising manual review, not replacing it.

Semgrep

It’s an Open Source tool.

Supported Languages

CategoryLanguages
GAC# · Go · Java · JavaScript · JSX · JSON · PHP · Python · Ruby · Scala · Terraform · TypeScript · TSX
BetaKotlin · Rust
ExperimentalBash · C · C++ · Clojure · Dart · Dockerfile · Elixir · HTML · Julia · Jsonnet · Lisp ·

Quick Start

# Install https://github.com/returntocorp/semgrep#option-1-getting-started-from-the-cli
brew install semgrep

# Go to your repo code and scan
cd repo
semgrep scan --config auto

You can also use the semgrep VSCode Extension to get the findings inside VSCode.

SonarQube

There is an installable free version.

Quick Start

# Run the platform in Docker
docker run -d --name sonarqube -e SONAR_ES_BOOTSTRAP_CHECKS_DISABLE=true -p 9000:9000 sonarqube:latest
# Install cli tool
brew install sonar-scanner

# Go to localhost:9000 and login with admin:admin or admin:sonar
# Generate a local project and then a TOKEN for it

# Using the token and from the folder with the repo, scan it
cd path/to/repo
sonar-scanner \
  -Dsonar.projectKey=<project-name> \
  -Dsonar.sources=. \
  -Dsonar.host.url=http://localhost:9000 \
  -Dsonar.token=<sonar_project_token>

CodeQL

The CodeQL CLI is available for research and open-source use; review the current GitHub CodeQL terms before using it for private or commercial analysis.

Install

# Download your release from https://github.com/github/codeql-action/releases
## Example
wget https://github.com/github/codeql-action/releases/download/codeql-bundle-v2.14.3/codeql-bundle-osx64.tar.gz

# Move it to the destination folder
mkdir ~/codeql
mv codeql-bundle* ~/codeql

# Decompress it
cd ~/codeql
tar -xzvf codeql-bundle-*.tar.gz
rm codeql-bundle-*.tar.gz

# Add to path
echo 'export PATH="$PATH:/Users/username/codeql/codeql"' >> ~/.zshrc

# Check it's correctly installed
## Open a new terminal
codeql resolve qlpacks #Get paths to QL packs

Quick Start - Prepare the database

[!TIP] The first thing you need to do is to prepare the database (create the code tree) so later the queries are run over it.

  • You can allow codeql to automatically identify the language of the repo and create the database
codeql database create <database> --language <language>

# Example
codeql database create /path/repo/codeql_db --source-root /path/repo
## DB will be created in /path/repo/codeql_db

[!CAUTION] This may report an error when more than one language is specified or automatically detected. Use one of the following options.

codeql database create <database> --language <language> --source-root </path/to/repo>

# Example
codeql database create /path/repo/codeql_db --language javascript --source-root /path/repo
## DB will be created in /path/repo/codeql_db
  • If your repo is using more than 1 language, you can also create 1 DB per language indicating each language.
export GITHUB_TOKEN=ghp_32849y23hij4...
codeql database create <database> --source-root /path/to/repo --db-cluster --language "javascript,python"

# Example
export GITHUB_TOKEN=ghp_32849y23hij4...
codeql database create /path/repo/codeql_db --source-root /path/to/repo --db-cluster --language "javascript,python"
## DBs will be created in /path/repo/codeql_db/*
  • You can also allow codeql to identify all the languages for you and create a DB per language. You need to give it a GITHUB_TOKEN.
export GITHUB_TOKEN=ghp_32849y23hij4...
codeql database create <database> --db-cluster --source-root </path/to/repo>

# Example
export GITHUB_TOKEN=ghp_32849y23hij4...
codeql database create /tmp/codeql_db --db-cluster --source-root /path/repo
## DBs will be created in /path/repo/codeql_db/*

Quick Start - Analyze the code

[!TIP] Now it’s finally time to analyze the code

If you selected several languages, CodeQL creates one database per language under the specified path.

# Default analysis
codeql database analyze <database> --format=<format> --output=</out/file/path>
# Example
codeql database analyze /tmp/codeql_db/javascript --format=sarif-latest --output=/tmp/graphql_results.sarif

# Specify QL pack to use in the analysis
codeql database analyze <database> \
    <qls pack> --sarif-category=<language> \
    --sarif-add-baseline-file-info --format=<format> \
    --output=/out/file/path>
# Example
codeql database analyze /tmp/codeql_db \
    javascript-security-extended --sarif-category=javascript \
    --sarif-add-baseline-file-info --format=sarif-latest \
    --output=/tmp/sec-extended.sarif

Quick Start - Scripted

export GITHUB_TOKEN=ghp_32849y23hij4...
export REPO_PATH=/path/to/repo
export OUTPUT_DIR_PATH="$REPO_PATH/codeql_results"
mkdir -p "$OUTPUT_DIR_PATH"
export FINAL_MSG="Results available in: "

echo "Creating DB"
codeql database create "$REPO_PATH/codeql_db" --db-cluster --source-root "$REPO_PATH"
for db_path in "$REPO_PATH"/codeql_db/*; do
    db=$(basename "$db_path")
    echo "Analyzing $db"
    codeql database analyze "$db_path" --format=sarif-latest --output="${OUTPUT_DIR_PATH}/$db.sarif"
    FINAL_MSG="$FINAL_MSG ${OUTPUT_DIR_PATH}/$db.sarif ,"
    echo ""
done

echo $FINAL_MSG

You can visualize the findings in https://microsoft.github.io/sarif-web-component/ or using VSCode extension SARIF viewer.

You can also use the VSCode extension to get the findings inside VSCode. You will still need to create a database manually, but then you can select any files and click on Right Click -> CodeQL: Run Queries in Selected Files

Snyk

There is an installable free version.

Quick Start

# Install
sudo npm install -g snyk

# Authenticate (you can use a free account)
snyk auth

# Test for open source vulns & license issues
snyk test [--all-projects]

# Test for code vulnerabilities
## This will upload your code and you need to enable this option in: Settings > Snyk Code
snyk test code

# Test for vulns in images
snyk container test [image]

# Test for IaC vulns
snyk iac test

You can also use the snyk VSCode Extension to get findings inside VSCode.

Insider

It’s Open Source, but looks unmaintained.

Supported Languages

Java (Maven and Android), Kotlin (Android), Swift (iOS), .NET Full Framework, C#, and Javascript (Node.js).

Quick Start

# Check the correct release for your environment
$ wget https://github.com/insidersec/insider/releases/download/2.1.0/insider_2.1.0_linux_x86_64.tar.gz
$ tar -xf insider_2.1.0_linux_x86_64.tar.gz
$ chmod +x insider
$ ./insider --tech javascript  --target <projectfolder>

DeepSource

Free for public repos.

NodeJS

  • yarn
# Install
brew install yarn
# Run
cd /path/to/repo
yarn install
yarn audit # In lower versions
yarn npm audit # In 2+ versions

npm audit
  • pnpm
# Install
npm install -g pnpm
# Run
cd /path/to/repo
pnpm install
pnpm audit
# Install & run
docker run -it -p 9090:9090 opensecurity/nodejsscan:latest
# Go to localhost:9090
# Upload a zip file with the code
  • RetireJS: The goal of Retire.js is to help you detect the use of JS-library versions with known vulnerabilities.
# Install
npm install -g retire
# Run
cd /path/to/repo
retire --colors

Electron

  • electronegativity: It’s a tool to identify misconfigurations and security anti-patterns in Electron-based applications.

Python

  • Bandit: Bandit is a tool designed to find common security issues in Python code. To do this Bandit processes each file, builds an AST from it, and runs appropriate plugins against the AST nodes. Once Bandit has finished scanning all the files it generates a report.
# Install
pip3 install bandit

# Run
bandit -r <path to folder>
  • safety: Safety checks Python dependencies for known security vulnerabilities and suggests the proper remediations for vulnerabilities detected. Safety can be run on developer machines, in CI/CD pipelines and on production systems.
# Install
pip install safety
# Run
safety check
  • Pyt: Unmaintained.

.NET

# dnSpy
https://github.com/0xd4d/dnSpy

# .NET compilation
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe test.cs

Rust

# Install
cargo install cargo-audit

# Run
cargo audit

#Update the Advisory Database
cargo audit fetch

Java

# JD-Gui
https://github.com/java-decompiler/jd-gui

# Java compilation step-by-step
javac -source 1.8 -target 1.8 test.java
mkdir META-INF
echo "Main-Class: test" > META-INF/MANIFEST.MF
jar cmvf META-INF/MANIFEST.MF test.jar test.class
TaskCommand
Execute Jarjava -jar [jar]
Unzip Jarunzip -d [output directory] [jar]
Create Jarjar -cmf META-INF/MANIFEST.MF [output jar] *
Base64 SHA256sha256sum [file] | cut -d’ ’ -f1 | xxd -r -p | base64
Remove Signingrm META-INF/.SF META-INF/.RSA META-INF/*.DSA
Delete from Jarzip -d [jar] [file to remove]
Decompile classprocyon -o . [path to class]
Decompile Jarprocyon -jar [jar] -o [output directory]
Compile classjavac [path to .java file]

Go

https://github.com/securego/gosec

PHP

Psalm and PHPStan.

Wordpress Plugins

https://www.pluginvulnerabilities.com/plugin-security-checker/

Solidity

JavaScript

Discovery

  1. Burp:
    • Spider and discover content
    • Sitemap > filter
    • Sitemap > right-click domain > Engagement tools > Find scripts
  2. WaybackURLs:
    • waybackurls <domain> |grep -i "\.js" |sort -u

Static Analysis

Unminimize/Beautify/Prettify

Deobfuscate/Unpack

Note: It may not be possible to fully deobfuscate.[6]

  1. Find and use .map files:
    • If the .map files are exposed, they can be used to easily deobfuscate.
    • Commonly, foo.js.map maps to foo.js. Manually look for them.
    • Use JS Miner to look for them.
    • Ensure active scan is conducted.
    • Read ‘Tips/Notes
    • If found, use Maximize to deobfuscate.
    • For webpack chunk structure, runtime injection, React/Vue/Angular internals, and DevTools workflows, consult the webpack reverse-engineering notes and related JavaScript research gists.[11][12]
  2. Without .map files, try JSnice:
    • References: http://jsnice.org/ & https://www.npmjs.com/package/jsnice
    • Tips:
      • If using jsnice.org, click on the options button next to the “Nicify JavaScript” button, and de-select “Infer types” to reduce cluttering the code with comments.
      • Ensure you do not leave any empty lines before the script, as it may affect the deobfuscation process and give inaccurate results.
  3. For some more modern alternatives to JSNice, you might like to look at the following:
  1. Use console.log():
    • Find the return value at the end and change it to console.log(<packerReturnVariable>); so the deobfuscated JavaScript is printed instead of executed.
    • Then, paste the modified (and still obfuscated) js into https://jsconsole.com/ to see the deobfuscated js logged to the console.
    • Finally, paste the deobfuscated output into https://prettier.io/playground/ to beautify it for analysis.
    • Note: If you are still seeing packed (but different) js, it may be recursively packed. Repeat the process.

Tools

References