Taming the Beast: Practical Code Review with Security Tools

Table of contents

Hi everyone!

Over the past few weeks, I've been working on a large and complex code review project. Along the way, I came across a few tools and tips that proved really valuable during a pentest. In this edition, I'd like to share them with you. Hopefully, you'll find them just as useful in your own work 😄

Know the architecture

The most important step is to understand what you're up against. I usually start by asking for any architecture or design diagrams the team can provide. The clearer the picture, the better. From there, I can begin building a threat model, asking myself questions such as:

• Are they encrypting sensitive data in the database?
• Are secrets hardcoded in the codebase?
• What possible edge cases could exist?

Nowadays, most developers rely on CI/CD tools to catch common security issues in code. That means your best chance to add value is by looking for business logic vulnerabilities and that's why understanding the full architecture is so important.

Codeql

Once you have a basic understanding of the architecture and threat model, it's a good idea to run tools that check for common issues. One of my favorites is CodeQL.

CodeQL works by running queries against a repository you define, looking for vulnerabilities in a specific programming language. You can do this with the CodeQL CLI in two main steps:

1. Create a database from the repository
2. Run queries against the database

Here's a minimal example:

# Step 1: Create the CodeQL database
codeql database create my-database \
  --language=javascript \
  --source-root=/path/to/repo

# Step 2: Analyze the database with the experimental query pack
codeql database analyze my-database \
  codeql/javascript-experimental-queries \
  --format=sarifv2 \
  --output=results.sarif

The query packs such as codeql/javascript-experimental-queries come from the official CodeQL GitHub repository. They often include checks that are not part of the default query suite but can highlight interesting edge cases or experimental rules.

Once you have your results in .sarif format, you can open them locally in Visual Studio Code using Sarif Viewer extension, which provides a clear interface to explore findings directly from your editor.

The cool thing about CodeQL is that it lets you trace issues back through the code flow, so you can understand why they were introduced.

⚠️ Note: CodeQL’s free use is limited to open source projects. For private repositories, you’ll need a GitHub Advanced Security license.

Semgrep

This is the second tool that I use the most. In my opinion, it's not as strong as CodeQL, but it's still very effective. Semgrep relies on pattern matching (regex-like rules) to identify issues in code, and it's much more straightforward to set up and run.

Here's a simple example of how to use it:

# Install Semgrep (if not already installed)
pip install semgrep

# Run Semgrep against a Go project using the Golang ruleset
semgrep --config p/golang /path/to/repo

You can explore the available rules directly on their website: https://semgrep.dev/p/golang

TruffleHog

Now that we have a basic understanding of the possible issues in the code, the next step is to try to detect secrets that may be hardcoded in the target's GitHub repo. For this, the best tool in my opinion is TruffleHog. It's quite straightforward to run. Since I'm usually testing private repos, the only command I run is the following:

$ trufflehog git file://test_keys --results=verified,unknown

Another interesting thing you can do, if you have the binary of the code you are auditing, is run the strings command-line tool to search for secrets as well.

Trivy

The last tool you may want to use, if the deployment of your target is in scope, is Trivy. Trivy allows you to find misconfigurations in things like Dockerfiles or Kubernetes, so it's quite useful. You can run it directly using:

trivy fs --scanners vuln,secret,misconfig myproject/

Wrapping up

That's all for now! I hope you picked up something useful in this chapter. Code review isn't exactly my idea of a fun Friday night, most projects come with thousands of lines of code that look like they were written by caffeinated squirrels, but with the right tools, the whole process becomes a lot less painful (and maybe even survivable).

See you in the next one.
Stay sharp,
Ruben

Chapters

Bypassing Cloud Firewalls: Size Does Matter

Previous Issue

The Day an Email Broke Single Sign-On

Next Issue

arrow_upward