На проверке SAST или как понять, что разработчик навайбкодил?

Всем привет, это моя первая статейка на Codeby, потому попрошу не кидаться камнями в мою сторону =)

В статье рассмотрим как базовое ПО по типу SonarQube, которое проверяет на соответствие стандартов, так и специализированное ПО для анализа кода на уязвимости с примерами POC или exploit

Начало
Для начала давайте поймем, что же такое SAST. SAST (Static Application Security Testing) — это метод статического анализа безопасности приложений, который сканирует исходный код, байт-код или бинарный код для выявления уязвимостей. Тут я бы сказал, что можем выделить 2 основных группы тулз, которые подходят под эту задачу:
1) Анализаторы кода, на соответствие стандартам. Почему я это отношу к SAST? Как бы мы сильно не ругались на тот же PyLance, который ругается чуть ли не на все методы и требует порою лишних вещей в коде, подходит не только для улучшения читаемости кода, но и для предотвращения unintended поведения у программы
2) Полноценные скрипты для тестирования. Тут пояснять что-то и далеко за примерами ходить не надо - PT Application Inspector. Довольно хороший плагин для VSCode, который прост в настройке и по итогам тестирования выдает примеры эксплоитов под многие уязвимости в коде.

SonarQube

Честно говоря, это не совсем SAST, скорее это просто скрипт для проверки соответствия вашего кода стандартам. Почему же это можно отнести к SAST? Все до удивительного просто: более 700 правил проверяют твой код, из которых 100 отдельно выделены как "Security Hotspot" и "Vulnerability", то есть как правила, для обнаружения потенциальных уязвимостей в коде. Рассмотрим одно из таких правил:
RSPEC-5659 "JWT should be signed and verified with strong cipher algorithms"
Правило обнаруживает создание JWT токенов без использования алгоритмов шифрования в подписи. Честно говоря, у SonarQube даже несколько правил на JWT токены, что даже радует

// Кодирование
import io.jsonwebtoken.Jwts;

public void encode() {
    Jwts.builder()
        .setSubject(USER_LOGIN)
        .compact();
}
// Декодирование
import io.jsonwebtoken.Jwts;

public void decode() {
    Jwts.parser()
        .setSigningKey(SECRET_KEY)
        .parse(token)
        .getBody();
}

На такой код анализатор сразу поругается. Чем же это помешает нашкодить в коде? Ну, если мы живем с мыслью, что всем безралично качество кода, то ничем. Если живем в мире, где хотя бы пайплайны настроены корректно, то SonarQube всего по 1 кнопке на сайте может заблокировать слитие MR'а, если есть уязвимости, качество кода ниже какой-то планки и так далее. Окей, мы показали, что код не самый лучший и требует фикса, а что делать то? Тут тоже все просто, анализатор сам предложит корректный фикс. Для примера выше он будет выглядеть следующим образом:

// Кодирование
import io.jsonwebtoken.Jwts;

public void encode() {
    Jwts.builder()
        .setSubject(USER_LOGIN)
        .signWith(SignatureAlgorithm.HS256, SECRET_KEY)
        .compact();
}
// Декодирование
import io.jsonwebtoken.Jwts;

public void decode() {
    Jwts.parser()
        .setSigningKey(SECRET_KEY)
        .parseClaimsJws(token)
        .getBody();
}

Я хоть и не разработчик, а специалист ИБ, но думаю, что блокировка пайплайна + предложение исправления уязвимости автоматикой SonarQube позволит быстро исправлять базовые уязвимости разработчикам. Плюс, это не какой-то супер специфичный плагин для ИБ специалистов, это в первую очередь плагин для улучшения стиля кода и исправления нарушений стандартов. К сожалению, тут не может идти речи о полном доверии SonarQube в плане статического анализа кода на уязвимости, ибо он для этого не предназначен и покрывает правилами далеко не все уязвимости из того же OWASP

PT Application Inspector

Тут в первую очередь важно отметить, что у продукта есть 2 версии: бесплатная и платная (кто бы мог подумать). Поговорим про платную версию, дабы оценить полный функционал, рассмаривать будем опять же на примере кода на Java. Довелось впервые попользоваться анализатором на одном из ивентов PHDays в 2025 году. Если сказать кратко, то по ощущениям, фолзит просто ужасно на Python и PHP коде, а вот на Java показывает себя довольно хорошо.

import java.sql.*;
import java.util.Scanner;

public class VulnerableDB {
    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);
        System.out.print("Enter username: ");
        String user = scanner.nextLine();

        String sql = "SELECT email FROM users WHERE user = '" + user + "'";

        try (Connection conn = DriverManager.getConnection("jdbc:sqlite:userData.db");
             Statement stmt = conn.createStatement();
             ResultSet rs = stmt.executeQuery(sql)) {

            while (rs.next()) {
                System.out.println("Email: " + rs.next());
            }
        } catch (SQLException e) {
            System.out.println("Error: " + e.getMessage());
        }
    }
}

Рассмотрим простую программу, которая по введенному user, должна возвращать его email. Если вы не совсем ленивый, то можно сразу понять, что у нас есть SQL Injection, так как нет обработки поля user, которое потом подставляется в строку с SQL запросом. Анализатор от PT сразу это заметил и вывел возможный эксплоит:

' UNION SELECT user,phone,money,email FROM users --

И он оказался прав, его эксплоит и правда отработал, и программа вывела лишние данные из нашей БД. К сожалению, в отличие от SonarQube он не предложил варианта с исправлением уязвимости, ну и описания подробного тоже не выдал, единственное что мы видим - это строка "SQL Injection in 'user' field". Ну, ладно, спасибо хоть за это. Главное, что ИБ специалисты поняли где тут конкретно косяк, и поругали разработчиков, либо сами поправили уязвимость (кто знает как процесс SAST выстроен в каждой компании). У вас может сложиться впечатление, что вот он, как говорят "blue gem всего мира SAST, даже эсклоит вывел", но придется вас огорчить: пока что PT Application Inspector предоставляет эксплоиты лишь на базовые уязвимости, но это вопрос времени, в будущем думаю добавят еще больше информации в свою базу и нам останется лишь нажать на 1 кнопку и получить сразу уязвимость, место где она есть, идеальный POC

Итоги
Ну что друзья, подытожим! Использовать только один анализатор - это прямой путь к слепым зонам. SonarQube отлично ловит стандарты кода и базовые недостатки безопасности типа JWT без подписи, но серьезные уязвимости типа SQL injection пропустит. PT Application Inspector наоборот - может эксплоит выдать, но будет фолзить в специфичных местах и фиксов не предложит
Главный вывод: один анализатор не закроет все векторы атак, но их комбинация даст мощное покрытие. SonarQube блочит MR'ы по качеству + PT пугает разработчиков реальными эксплоитами = идеальная связка для пайплайна. Вместе они то, что не видит один по отдельности, находят гарантированно.
Так что не выбирайте "или-или", а стройте связку анализаторов - меньше дырок в коде, а значит и меньше инцидентов по ночам!