Welcome to the first lesson of our course on SAST tools. Static Application Security Testing, commonly known as SAST, is a method of security testing that analyzes source code to find security vulnerabilities that make your application susceptible to attacks. It is often referred to as white-box testing because the tester has full access to the internal structure and code of the application.

Unlike other forms of testing that require the application to be compiled and running, SAST works on the code while it is "at rest." This means you can run these tests while writing code in your editor or as soon as you push your code to a repository. In this lesson, we will explore the core concepts of SAST, understand its strengths and weaknesses, and introduce the specific toolset we will use to secure our applications.

At its core, SAST works by parsing your source code and looking for specific patterns that match known vulnerabilities. Think of it as a very advanced spell-checker; instead of looking for spelling errors, it looks for security errors. The tool reads your code line by line and compares it against a database of rules. If a piece of code violates a rule — for example, by using a dangerous function or handling user input unsafely — the tool flags it as an issue.

This process matters because it automates the discovery of common mistakes developers make. Humans are prone to error, and it is easy to forget to validate user input or to accidentally leave a password in a file. By automating this search using Pattern Matching, we can catch these mistakes instantly without requiring a human to manually review every single line of code.

Here is a simple example of code that a SAST tool would flag:

// Example of code with a security flaw
function getUser(userId) {
    // This line constructs a SQL query by combining strings directly
    const query = "SELECT * FROM users WHERE id = " + userId;
    execute(query);
}

In the example above, a SAST tool would detect that userId is being directly concatenated into a database SQL query string. It recognizes this pattern as a SQL Injection risk. The tool knows that if userId comes from an untrusted source, it should not be pasted directly into a command. The SAST report would alert you to this line and often suggest using "parameterized queries" instead.

One of the primary benefits of using SAST is the ability to find vulnerabilities very early in the software development process. In the security industry, we call this Shifting Left. The idea is that the earlier you find a bug, the cheaper and easier it is to fix. If you find a security hole while you are still typing the code, fixing it takes only five minutes. If you find that same hole after the application has been released to thousands of users, fixing it could take days and lead to significant costs in emergency updates and potential data breaches.

SAST also offers incredible speed and coverage compared to manual review. A human security expert might take weeks to read through a large codebase consisting of millions of lines of code. A SAST tool can scan that same codebase in minutes. It provides 100% code coverage, meaning it looks at every single file, including obscure back-end administrative scripts that might otherwise be ignored during a manual test.

There are specific types of issues that SAST is excellent at catching:

• Injection Flaws: Such as the SQL injection example we looked at earlier.
• Hardcoded Secrets: Detecting passwords, API keys, or cryptographic tokens left inside the code files.
• Weak Cryptography: Identifying the use of outdated algorithms like MD5 or SHA1.
• Buffer Overflows: Finding areas in lower-level languages where data might overwrite memory.

While SAST is powerful, it is not a perfect solution and comes with distinct limitations. The most common complaint developers have with SAST is the high rate of False Positives. A false positive occurs when the tool flags a piece of code as vulnerable, but it is actually safe. Because SAST tools analyze code without running it, they lack context. They might see that you are using a "dangerous" function, but they might not realize that the input to that function is hardcoded and perfectly safe. This creates "noise" that developers must filter through, which can be time-consuming.

The opposite problem also exists: False Negatives. A false negative occurs when a SAST tool fails to flag code that is genuinely vulnerable. This happens because SAST rules are only as good as the patterns they are written to detect. A vulnerability that uses an unfamiliar coding pattern, or one that spans multiple files in a non-obvious way, may go completely undetected. False negatives are arguably more dangerous than false positives because they give developers a false sense of security — the tool reported no issues, so the code must be safe.

Another major limitation is that SAST cannot detect Runtime Issues or environment misconfigurations. Since SAST only looks at the source code files, it cannot see how the server is configured, how the database permissions are set, or how different microservices communicate over a network. It effectively has "tunnel vision" focused only on the code you give it.

Finally, SAST often struggles with complex Business Logic flaws. A business logic flaw isn't a coding error; it is a flaw in the design of the application's rules. For example, if your code allows a user to buy an item for $0 because of a logical loophole in the checkout process, the code itself might be syntactically correct. A SAST tool will likely pass this code because there is no obvious "security error" like a bad function call, even though the logic creates a security risk.

To build a secure application, it is important to understand the difference between SAST and Dynamic Application Security Testing (DAST). While SAST looks at the code from the inside (White-box), DAST looks at the running application from the outside (Black-box). DAST interacts with the application just like a user (or a hacker) would, sending requests to web pages and analyzing the responses.

You should use SAST during the development phase. It is best for ensuring code quality and catching syntax-related security flaws before the code ever leaves your computer. On the other hand, you use DAST after the application is deployed to a test server. DAST is necessary to catch issues that only appear when the application is running, such as authentication errors or server configuration leaks.

Here is a quick comparison:

Both techniques matter in a Secure Development Lifecycle. Relying on just one leaves you with blind spots. In this course, we are focusing exclusively on the SAST side of this equation.

Throughout this course, we will get hands-on experience with several industry-standard tools. We have selected these tools because they are widely used, powerful, and cover different aspects of static analysis. Note that in the CodeSignal environment, these tools come pre-installed, so you won't need to configure your own environment, but it is good to know what they are.

ESLint with eslint-plugin-security

• ESLint is the most popular linter for JavaScript. By itself, it identifies style and syntax errors. However, by adding the eslint-plugin-security, we turn it into a lightweight SAST tool that scans JavaScript code for logic resembling security risks, such as potentially dangerous regular expressions or the use of eval().

Semgrep

• A modern, fast, and "polyglot" static analysis tool that supports many languages (Python, Go, Java, JavaScript, etc.). It allows us to write custom rules very easily; if you want to ban a specific function in your codebase that causes problems, you can write a simple Semgrep rule to find it.

gitleaks

• A specialized SAST tool designed to find "secrets." It scans your git history and source files looking for items that resemble API keys, passwords, and tokens. This prevents you from accidentally pushing sensitive credentials, like AWS keys, to a repository.

npm audit

• A tool that performs Software Composition Analysis (SCA). It doesn't look at your code; it looks at your package.json file to see which third-party libraries you are using and checks a central database to see if any of those libraries have known vulnerabilities.

By using these tools in combination, we can address security from multiple angles: the code we write, the secrets we manage, and the third-party dependencies we rely on. This multi-layered approach is essential for building a robust security posture in modern software development.

In this lesson, we established that SAST is the practice of analyzing source code for security vulnerabilities without executing the program. We learned that it is excellent for finding injection flaws and hardcoded secrets early in the development cycle ("Shifting Left"). However, we also acknowledged that SAST can generate false positives and cannot see runtime or business logic issues, which is why it complements Dynamic Analysis (DAST).

We also introduced the toolset for this course: ESLint for JavaScript patterns, Semgrep for custom rules, gitleaks for secret detection, and npm audit for checking dependencies. In the next lesson, we will move from theory to practice. We will start by running our first scan using ESLint to find and fix common security issues in code.