Behind the Scenes of SAST — The Challenges of Code Scanning

Process 1. Find Dangerous Code Patterns

XSS

SSRF

  1. Function names. Some functions are inherently dangerous by design, like the “open” in Ruby, or any function that allows you to execute shell commands.
  2. Pattern matching and Regexes. Some frameworks, like Semgrep, heavily rely on pattern matching for known code patterns

Process 2. Understand the Code Flow

Safe vs. unsafe input — Taint Analysis

SQLi from config

Identifying unreachable areas in the code

Process 3. Identify Input Validation

Not all input validations are born the same

Input validation can be done in different places

  • The validation happens on the API Gateway, based on a swagger file. The scanner knows only the code, with no idea what an API gateway or a swagger file is.
  • In microservices. The vulnerable code is written in Java, and the input validation happens in a microservice written in Python. The SAST supports only Java.

The Final Showdown: SAST

The Advantages of SAST

  • High coverage. SAST provides better code coverage per application than DAST and IAST (Interactive application security testing). SAST solutions can test many different flows without the need to generate traffic to trigger each one of them.
  • Easy to launch. Most SAST tools don’t require much configuration before you launch a scan.
  • Safe to use. Since SAST tools are passive by nature, you can casually run them without worry they will break your application.

The Challenges of SAST

  • False positives. This is the main reason why security engineers struggle with SAST tools. Sometimes a simple scan leaves you with more questions than answers — an overwhelming report with many “vulnerabilities” that actually can’t be exploited because of input validation or unreachable code.
  • Non-generic. If you use multiple programming languages and frameworks, more than one tool is probably needed. For a SAST company, the process of supporting a new language is long and cumbersome. It’s almost like building a new product.
  • Library dependent. SAST tools can detect dangerous code patterns only in libraries and functions they are familiar with. An example: If your code uses less common or customized libraries for HTML rendering, there’s a good chance the tool won’t be able to identify XSS vulnerabilities.
  • Lack of business logic context. SAST tools can’t find business logic vulnerabilities in the code itself, such as broken access control.
  • Lack of production context. Some vulnerabilities can be found only when testing a running instance of the system, with all the components running in parallel.

--

--

--

I love to learn, build and break things. Head of Security Research @ Traceable.ai; Security Consultant @ Tangent Logic

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Why Cyber Security Needs New Imagery

{UPDATE} 释义成语 - 天天猜成语,全民学汉语 Hack Free Resources Generator

We are under attack: A primer in mobile apps security

Official $ANM address on BSC (BEP20): 0x7470ff44a57fce4b7413f31fdc9b625ff58dbb9c

How to use VPN during trips

{UPDATE} Zombi Defensa vs Mago Juegos de disparos Hack Free Resources Generator

Top Data Security Practices Every CISO Needs to Know in 2021

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Inon Shkedy

Inon Shkedy

I love to learn, build and break things. Head of Security Research @ Traceable.ai; Security Consultant @ Tangent Logic

More from Medium

Authentication Basic in 3 minutes

Transporting malware in google links.

Linux Privilege Escalation Resources

Hack The Box — Remote Write-up