DEV Community: Vardan Matevosian

Is OpenAI really running ChatGPT on a single PostgreSQL instance?

Vardan Matevosian — Tue, 27 Jan 2026 09:12:10 +0000

The headline of OpenAI’s recent article https://openai.com/index/scaling-postgresql/ feels a bit clickbaity,
If they truly used only one database instance, ChatGPT would’ve been dead on arrival.

But the reality is far more impressive: they’re using the right tool for each layer of the persistent stack:

They push PostgreSQL to its absolute limits, with a single primary writer, yes, but backed by nearly 50 read replicas across global regions.
For write-heavy workloads, they’ve wisely migrated to sharded systems like Azure Cosmos DB.
They’ve added layers of resilience:
- connection pooling with PgBouncer,
- query rate limiting,
- caching with lock leasing,
- cascading replication (in testing),
- strict schema-change policies.

It’s not magic, it’s mature, thoughtful engineering at scale.

If you work with databases, this post is absolutely worth reading.

The second-highest salary: Why the simplest SQL query is often the smartest

Vardan Matevosian — Tue, 13 Jan 2026 09:51:22 +0000

Spoiler: That elegant two-line MAX() subquery? It’s not just clever—it’s correct, portable, and often faster than fancier alternatives.

When interviewing for backend or data roles, you’ve probably seen this classic problem: “Find the second highest salary from the Employee table. If there is no second highest salary, return NULL”.

It also appears in LeetCode #176 and similar coding challenge sites.

The solution seems trivial until you consider duplicates, performance, edge cases, and real-world database behavior.

In this deep dive, we’ll compare three common approaches, expose hidden pitfalls, and reveal why the simplest solution is frequently the best, especially when correctness and portability matter.

The problem and sample data

We’re given an employee table:

id	name	salary	department_id
1	Ivan	1000.1234	1
2	Anna	1500.1234	1
3	Oleg	2200.1234	2
4	Maria	2200.1234	2
5	David	2000.5678	2

Expected result: 2000.5678

Problem statement: Find the second highest distinct salary from the employee table.

Key requirement: Return NULL if fewer than two distinct salaries exist (e.g., all employees earn the same).

This isn’t about the “second row” — it’s about the second highest distinct value.

Three common solutions compared

METHOD 1: `MAX()` + Subquery

SELECT MAX(salary)
FROM employee
WHERE salary < (SELECT MAX(salary) FROM employee);

Why it works:

Inner query finds the global max.
Outer query finds the max among values strictly less than that.
Naturally returns NULL if no such value exists.
Handles duplicates implicitly—no extra logic needed.

Performance:

Scenario	Time Complexity
No index	O(N)
With index	O(log N + c)

c = small constant (rows scanned after max; usually 1–few)

PROS

Correct by design
Returns NULL as required
Works on any SQL database (even SQLite!)

CONS

Not easily extensible to “3rd highest” or “top 5”

Verdict: Best for this exact problem. Simple, safe, and scalable.

METHOD 2: `DISTINCT` + `ORDER BY` + `OFFSET`

SELECT DISTINCT salary
FROM employee
ORDER BY salary DESC
LIMIT 1 OFFSET 1;

Note: Without DISTINCT, this returns the second row, not the second distinct salary. So we must include DISTINCT.

Performance reality:

Database Version	Time Complexity
MySQL ≥ 8.0 / PostgreSQL ≥ 13	O(k log N)
Older versions	O(N)
No index	O(N log N)

O(k log N) - only if skip scan (MySQL) or index skip scan (PostgreSQL) is used

PROS

Clean syntax
Very fast on modern DBs with proper indexes

CONS

Fails silently on older databases (full scan!)
Returns empty result, not NULL—your app must handle it
Requires DESC index for best performance
DISTINCT can be expensive if skip scan isn’t available

Verdict: Great only if you control your DB version and handle empty results.

Method 3: `DENSE_RANK()` Window Function

SELECT salary
FROM (
  SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) AS place
  FROM employee
) AS emp
WHERE place = 2;

Flexible?

Note:

DENSE_RANK() properly handles ties (e.g., two people at rank 1 with the same salary, next is rank 2).
But returns an empty set, not NULL, so you’d need to wrap in MAX() to comply with requirements, or handle it in the application code.

Performance:

Always O(N log N) due to sorting, even with an index.
Most databases compute ranks for all rows, even if you only need rank=2.

Pros:

Highly flexible (easy to get 3rd, 10th, etc.)
Handles complex ranking scenarios

Cons:

Overhead for a simple task
Doesn’t return NULL natively
Not supported in older DBs (e.g., MySQL < 8.0)

Verdict: Save this for when you truly need ranking logic, not scalar results.

H2H comparison

Method	Correct?	Returns `NULL`?	Handles Duplicates?	Portable?	Best Use Case
<MAX() + Subquery	Yes	Yes<	Yes	Yes	Second highest (exact match)
DISTINCT + OFFSET	Yes	No	Yes	Modern DBs only	Top-N distinct (with skip scan)
DENSE_RANK()	Yes	No	Yes	Newer DBs	Flexible ranking with ties

Key takeaways

Favor correctness, clever code can wait

The MAX() subquery satisfies the specification exactly: it returns NULL when appropriate and naturally ignores duplicates.
Don’t trust OFFSET for “Nth highest”

Without DISTINCT, it’s wrong. Even with DISTINCT, it’s not portable and may be slow on older systems.
Index is not meant for automatic speed

A DESC index helps—but only if your database supports skip scans (MySQL 8.0+ or PostgreSQL 13+). Otherwise, you’re scanning millions of rows for two values.
Window functions aren’t always better

They’re powerful, but introduce unnecessary overhead for simple scalar problems.

Final recommendation

For the “second-highest salary” problem, use:

SELECT MAX(salary)
FROM employee
WHERE salary < (SELECT MAX(salary) FROM employee);

It’s:

Correct
NULL-safe
Portable
Efficient
Readable

Use DISTINCT, OFFSET, and DENSE_RANK() for problems that truly require their flexibility.

Remember: In SQL, a shorter query doesn’t always run faster, what really matters is writing one that’s clear, accurate, and does exactly what you intend.

Originally published on my personal blog: https://matevosian.tech/blog/post/database_sql_second_highest_salary

Application security: thinking backwards

Vardan Matevosian — Wed, 07 Jan 2026 12:25:24 +0000

📜 Developers often focus on what library or what tool they can use to secure their microservices. Modern tools are powerful nowadays, but you can’t be sure all doors are locked if you have never looked at them from the other side.
To truly protect an application, you must first learn how it can be attacked.

Thinking like an ethical hacker helps you understand:
🕵️‍♂️ How can your application be invaded?
🕵️‍♂️ Where sensitive data can be leaked?
🕵️‍♂️ What weak points can be exploited?
🕵️‍♂️ How attackers chain small issues into real threats?

The OWASP community plays a huge role here. The OWASP Top 10 list of grouped vulnerabilities provides clear explanations of the most common vulnerabilities, how to test for them, and, most importantly, how to mitigate them.

But theory alone is not enough.
There are excellent platforms where you can practice ethical hacking in a secure environment and understand how vulnerabilities behave in real-world scenarios. One of my favorites is PortSwigger Academy. You can choose a specific vulnerability, exploit it step by step, and then draw parallels to your own application.

This practical approach helps you see security not as an abstract concept, but as something that directly affects your users.
The main goals are:
🔦 prevent attacks before they happen
🔦 protect our users
🔦 let the users and us, not just go to sleep, but get some well-needed shut-eye 🏆🎬, knowing the doors are locked.

PortSwigger Academy - https://portswigger.net/web-security

PortSwigger also developed the BurpSuite DAST (Dynamic Application Security Testing) tool. Burp Suite is a set of tools used for penetration testing of web applications.

SAST, in combination with DAST tools, provides a more comprehensive security posture by identifying vulnerabilities in both the source code and the running application, enabling earlier detection, improved coverage, and reduced risk in production.

Application Security with OAuth 2.0 and OpenID

Vardan Matevosian — Sun, 28 Dec 2025 17:35:10 +0000

📜 After years of diving deep into application security, I wanted to share what I had learned with others.

That experience sparked an idea: why not create a course that brings together all the practical knowledge I wish I had when I started?

And that’s how my Udemy course “Application Security with OAuth 2.0 and OpenID” was born – a step-by-step guide for developers to understand security and get into these standards from a practical, hands-on perspective, and act like a hacker to see the other side.

The goal is simple: help others build safer applications, protect users, and understand the OAuth 2.0 and OpenID standards.

Security isn’t just a topic to learn; it’s a mindset. And I wanted to make that mindset accessible to every developer.

If you are interested, here is the course link: http://udemy.com/course/application-security-with-oauth-2-and-openid

Java Interface Evolution: Best Practices and Strategies

Vardan Matevosian — Sat, 27 Dec 2025 11:29:12 +0000

Introduction

In this post we will explore the evolution of Java interfaces, focusing on features introduced in Long-Term Support (LTS) releases since Java 8.
We will examine how these features have enhanced interface design.

Timeline navigation

Java 8 (March 2014)
Java 11 (September 2018)
Java 17 (September 2021)
Java 21 (September 2023)

📍 March 2014 - Java 8 The Functional Revolution

Java 8 revolutionized interfaces by allowing them to include non-abstract methods, enabling backward-compatible API evolution and supporting functional programming via functional interfaces.

New interface features:

Default methods (default keyword) – provide concrete implementations.
Static methods in interfaces.
Functional interfaces – interfaces with exactly one abstract method (used with lambdas).

Default methods

Java 8 introduced a significant change to interfaces: the ability to define method implementations directly within the interface using the default keyword. This feature addresses the "interface evolution problem", where adding a new method to an existing interface would break all implementing classes.

Before Java 8, any change to an interface required all implementing classes to be modified to provide an implementation for the new method. This was a major obstacle to evolving APIs, as it could lead to widespread code changes and potential compatibility issues. Default methods provide a way to add new functionality to an interface without breaking existing implementations.

public interface MyInterface {

    void existingMethod();

    default void newDefaultMethod() {
        System.out.println("This is a default method.");
    }

}

public class MyClass implements MyInterface {

    public void existingMethod() {
        System.out.println("Implementing existing method.");
    }

    // No need to implement newDefaultMethod() unless specific behavior is desired
    public void someMethod() {
        newDefaultMethod();
    }

}

Real JDK example of default method

Interface: java.util.List

Purpose: Sort the list in place using a Comparator.

public interface List<E> extends Collection<E> {
    default void sort(Comparator<? super E> c) {
        Collections.sort(this, c);
    }
}


// Usage:
List<String> list = new ArrayList<>(Arrays.asList("banana", "apple", "cherry"));
list.sort(Comparator.naturalOrder());

// Output: [apple, banana, cherry]
System.out.println(list);

Interface: java.lang.Iterable

Purpose: Enables concise iteration with lambdas.

public interface Iterable<T> {
    default void forEach(Consumer<? super T> action) {
        Objects.requireNonNull(action);
        for (T t : this) {
            action.accept(t);
        }
    }
}

List<String> list = Arrays.asList("apple", "banana", "cherry");
list.forEach(item -> System.out.println(item));

Interface: java.util.Map

Purpose: Java 8 added several useful default methods to the Map interface.

public interface Map<K, V> {
    default V getOrDefault(Object key, V defaultValue) {
        V v;
        return (((v = get(key)) != null) || containsKey(key)) ? v : defaultValue;
    }

    default V putIfAbsent(K key, V value) {
     V v = get(key);
     if (v == null) {
       v = put(key, value);
     }
     return v;
   }

   // Other default methods like remove, replace, compute, merge, etc.
}

Map<String, Integer> map = new HashMap<>();
map.put("apple", 1);
Integer i = map.getOrDefault("banana", 0);

// i will be 0 since "banana" is not in the map
System.out.println(i);

Static methods

Java 8 also introduced static methods in interfaces,
allowing developers to define utility methods that are related to the interface but do not require an instance of the implementing class to be invoked.
This feature helps organize code better and provides a way to group related functionality.

public interface MyInterface {
    static void utilityMethod() {
        System.out.println("This is a static method in the interface.");
    }
}

// Usage:

public class MyClass implements MyInterface {
    public void someMethod() {
        // Calling the static method
        MyInterface.utilityMethod();
    }
}

Real JDK example of static method

Interface: java.util.Collections

Purpose: Provides utility methods for collection operations.

public final class Collections {
    public static <T> List<T> emptyList() {
        return (List<T>) EMPTY_LIST;
    }
}

// Usage:

List<String> empty = Collections.emptyList();

// Output: []
System.out.println(empty);

Interface: java.util.Map

Purpose: Provides utility methods when using Map like "of()" method.

public interface Map<K, V> {
    static <K, V> Map<K, V> of() {
        return new HashMap<>();
    }

    static <K, V> Map<K, V> of(K k1, V v1) {
        Map<K, V> map = new HashMap<>();
        map.put(k1, v1);
        return map;
    }

// Additional overloaded of() methods for more key-value pairs
}


// Usage:

Map<String, Integer> map = Map.of("apple", 1, "banana", 2);

// Output: {apple=1, banana=2}
 System.out.println(map);

Functional interfaces

Java 8 introduced the concept of functional interfaces, which are interfaces that contain exactly one abstract method.
This feature is crucial for enabling lambda expressions and method references, allowing for more concise and expressive code.

@FunctionalInterface
public interface MyFunctionalInterface {
    void singleAbstractMethod();

}

// Usage:

MyFunctionalInterface func = () -> System.out.println("Lambda expression implementation.");

// Output: Lambda expression implementation.
func.singleAbstractMethod();

Real JDK example of functional interface

The java.util.function package was added in Java 8 and contains dozens of general-purpose functional interfaces.
Here are the most widely used ones—with real usage examples:

Interface: java.util.function.Predicate<T>

Purpose: Represents a boolean-valued function of one argument.

@FunctionalInterface
public interface Predicate<T> {
    boolean test(T t);
}

// Usage:

Predicate<String> isEmpty = str -> str.isEmpty();

// Output: true
System.out.println(isEmpty.test(""));

// Output: false
System.out.println(isEmpty.test("hello"));

Interface: java.util.function.Function<T, T>

Purpose: Represents a function that accepts one argument and produces a result.

@FunctionalInterface
public interface Function<T, R> {
    R apply(T t);
}

// Usage:

Function<String, Integer> stringLength = str -> str.length();

// Output: 5
System.out.println(stringLength.apply("hello"));

// Output: 0
System.out.println(stringLength.apply(""));

Interface: java.util.function.Consumer<T>

Purpose: Represents an operation that accepts a single input argument and returns no result.

@FunctionalInterface
public interface Consumer<T> {
    void accept(T t);
}

// Usage:

Consumer<String> print = str -> System.out.println(str);

// Output: hello
print.accept("hello");

// Output: world
print.accept("world");

Interface: java.util.function.Supplier<T>

Purpose: Represents a supplier of results.

@FunctionalInterface
public interface Supplier<T> {
    T get();
}

// Usage:

Supplier<Double> randomValue = () -> Math.random();

// Output: Random double value
System.out.println(randomValue.get());

// Output: Another random double value
System.out.println(randomValue.get());

Interface: java.util.function.UnaryOperator<T> (extends Function<T, T>)

Purpose: Represents a function that takes one argument and returns a result of the same type.

@FunctionalInterface
public interface UnaryOperator<T> extends Function<T, T> {
}

// Usage:

UnaryOperator<Integer> square = x -> x * x;

// Output: 25
System.out.println(square.apply(5));

// Output: 0
System.out.println(square.apply(0));

Interface: java.util.function. BinaryOperator<T> (extends BiFunction<T, T, T>)

Purpose: Represents an operation upon two operands of the same type, producing a result of the same type.

@FunctionalInterface
public interface BinaryOperator<T> extends BiFunction<T, T, T> {
}

// Usage:

BinaryOperator<Integer> add = (x, y) -> x + y;

// or

BinaryOperator<Integer> addWithMethodReference = Integer::sum;

// Output: 15
System.out.println(add.apply(5, 10));

// Output: 0
System.out.println(addWithMethodReference.apply(0, 0));

Some of the interfaces that was lunched before Java 8, updated to be functional interfaces:

Interface	Package	Abstract Method	Common Use
`Runnable`	`java.lang`	`void run()`	Threading, executors
`Callable<V>`	`java.util.concurrent`	`V call()`	Threading with return value
`Comparator<T>`	`java.util`	`int compare(T a, T b)`	Sorting
`ActionListener`	`java.awt.event`	`void actionPerformed(...)`	GUI events

Why These Matter

These features significantly enhanced Java's interface capabilities:
Backward compatibility: Millions of existing Map or List implementations (e.g., ArrayList, HashMap, or custom ones) automatically got these new methods without recompilation.
Cleaner code: Eliminated boilerplate (e.g., manual loops for filtering).
Functional style: Enabled fluent, declarative data processing.

📍 September 2018 - Java 11 Private methods - inherited from Java 9

Java 11 is an LTS release but did not add any new interface features.
However, it includes all interface enhancements from Java 9,
which introduced private methods in interfaces (standardized and fully supported in Java 11).

Private methods in interfaces allow developers to encapsulate common logic that can be reused by default methods within the same interface.


public interface DataProcessor {

  default void process(String data) {
    String cleaned = sanitize(data);
    System.out.println("Processed: " + cleaned);
  }

  private String sanitize(String input) {
    return input.trim().toLowerCase();
  }

  @SuppressWarnings("checkstyle:WhitespaceAround")
  static DataProcessor create() {
    return new DataProcessor() {
    };
  }
}

// Usage:

public class TestInterfacePrivateMethod {

    public static void main(String[] args) {
        DataProcessor processor = DataProcessor.create();

        // Output: Processed: hello world
        processor.process("  HELLO WORLD  ");
    }

}

📍 September 2021 - Java 17 Sealed interfaces

Java 17 introduces sealed interfaces (along with sealed classes),
allowing you to restrict which classes or interfaces can implement your interface.
This enhances domain modeling and works seamlessly with pattern matching.

New interface feature: Sealed interfaces with permits clause

Rules:

Subtypes must be listed in permits (or in the same file).
Each permitted subtype must have a class modifier: final, sealed, or non-sealed.

sealed: restricts who can extend/implement you.
final: cannot be extended.
non-sealed: can be extended, even though your parent is sealed.

Note: non-sealed is only allowed on classes (or interfaces) that directly extend
or implement a sealed type and are listed in its permits clause.


// Sealed interface. Can only be implemented by Circle, Rectangle, and Polygon.
public sealed interface Shape permits Circle, Rectangle, Polygon {}

// Final class. Cannot be extended further.
final class Circle implements Shape {
  public final double radius;
  public Circle(double radius) { this.radius = radius; }
}

// Sealed subclass (continues restriction)
sealed class Polygon implements Shape permits Quadrilateral {
  public final int sides;
  public Polygon(int sides) { this.sides = sides; }
}

// Can be extended further
non-sealed class Rectangle implements Shape {
  public final double width, height;
  public Rectangle(double w, double h) { width = w; height = h; }
}

📍 September 2023 - Java 21 Better Integration

Java 21 does not add new interface-specific features,
but it enhances how interfaces are used through: Pattern matching for switch
Simplifies type checks and casts when working with interface implementations.

sealed interface Expr permits Constant, Add {}

record Constant(int value) implements Expr {}
record Add(Expr left, Expr right) implements Expr {}

public static int eval(Expr e) {
  return switch (e) {
    case Constant c -> c.value;
    case Add a -> eval(a.left) + eval(a.right);
  };
}

// Usage:

Expr expr = new Add(new Constant(3), new Constant(5));

// Output: 8
System.out.println(eval(expr));

Best practices

Use default methods sparingly: Default methods should be used to add new functionality or provide optional implementations, not to fundamentally change the interface's contract.
Consider the impact on implementing classes: When adding default methods, carefully consider how they will affect existing implementations.
Use static methods for utility functions: Static methods should be used for utility functions that are closely related to the interface.
Document default and static methods clearly: Provide clear and concise documentation for all default and static methods, explaining their purpose and usage.
Avoid state in interfaces: Interfaces should generally not maintain state. Default methods should primarily operate on the state of the implementing class.

Conclusion

SAST remains one of the cornerstones of a mature SSDLC. It provides early, actionable insights into code security, reduces risk, empowers developers, and fortifies applications before deployment.
Implemented with care, SAST becomes more than just a detection tool; it becomes a catalyst for a long-term secure engineering culture.

Originally published on my personal blog: https://matevosian.tech/blog/post/Java-interface-evolution

Security isn’t just about code

Vardan Matevosian — Tue, 23 Dec 2025 10:48:46 +0000

📜 I didn’t get into security because it was a trendy field. It started back when I was a junior developer. At some point, I realized that being a developer isn’t just about writing code, seeing it work, and feeling satisfied.

Real people use the applications we build. That’s when I started asking myself questions:
🕵️‍♂️ These users have access to the application, but what exactly can they access?
🕵️‍♂️ What permissions do they have?
🕵️‍♂️ What if someone without proper rights could use a feature and harm other users?
🕵️‍♂️ And what if that incident damaged the company’s reputation?

From that moment, I began to delve deeper into application and user security, and over time, I realized that security isn’t about adding extra layers later; it’s about responsibility for the people who trust our code.

Today, I see security as part of software architecture itself. It’s something that should be considered from the first line of code, not after deployment.

That realization made me want to understand what “secure code” really means, and that’s where my journey into application security truly began…

Automating code security in CI/CD: SonarCloud SAST guide (Part 3)

Vardan Matevosian — Wed, 17 Dec 2025 18:29:13 +0000

Note: Click on the image to see a larger (original) version.

Introduction

In this part of our SAST series, we focus on practical steps to incorporate SAST using SonarQube.

You will receive a comprehensive step-by-step guide on how to integrate SonarQube into your CI/CD workflow and automate the process.

We will explore:

Integrating SonarQube scanning into the CI/CD pipeline using GitHub Actions
Failing the pipeline based on SonarQube's default Quality Gates for a free account
Adding unit tests and the JaCoCo plugin for code coverage

Tools:

SonarQube Cloud
GitHub Actions
JaCoCo
Spring Boot
IntelliJ IDEA
JUnit 5

By following this comprehensive guide, you will be able to seamlessly integrate SAST into your SSDLC process and improve your software’s security posture.

Integrating SonarQube scanning into the CI/CD pipeline using GitHub Actions

If you haven't created a Spring Boot project yet, then you can do so in this section. Create a Spring Boot project using IntelliJ IDEA or the Spring Boot Initializr at https://start.spring.io/. Click Next and generate the project without dependencies.

Update the “gradle.build” file to look like this. We will use Spring Boot 3 and Java 17, and will exclude tests for now.


plugins {
   id 'java'
   id "org.sonarqube" version "7.0.0.6105"
   id 'org.springframework.boot' version '3.0.0'
   id 'io.spring.dependency-management' version '1.1.7'
}


group = 'com.practice'
version = '0.0.1-SNAPSHOT'
description = 'sonarqube_actions_demo'


java {
   toolchain {
       languageVersion = JavaLanguageVersion.of(17)
   }
}


configurations {
   compileOnly {
       extendsFrom annotationProcessor
   }
}


repositories {
   mavenCentral()
}


dependencies {
   // Spring boot runtime
   implementation 'org.springframework.boot:spring-boot-starter-web'


   // Observability
   implementation 'ch.qos.logback:logback-classic:1.5.13'
   implementation 'ch.qos.logback:logback-core:1.5.19'
}




def localProps = new Properties()
def localFile = file("gradle-local.properties")
if (localFile.exists()) {
   localProps.load(localFile.newDataInputStream())
}


sonar {
   properties {
       property "sonar.projectKey", System.getenv("SONAR_PROJECT_KEY") ?: localProps["sonar.projectKey"]
       property "sonar.organization", System.getenv("SONAR_ORGANIZATION_KEY") ?: localProps["sonar.organization"]
       property "sonar.projectName", System.getenv("SONAR_PROJECT_NAME") ?: localProps["sonar.projectName"]
       property "sonar.token", System.getenv("SONAR_TOKEN") ?: localProps["sonar.token"]
       property "sonar.host.url", System.getenv("SONAR_HOST_URL") ?: localProps["sonar.host.url"]
   }
}




tasks.named('test') {
   useJUnitPlatform()
}

Create the “gradle-local.properties” file to run SonarQube locally:


systemProp.sonar.qualitygate.wait=true


sonar.projectKey=sonarqube_actions_demo_key
sonar.organization=local-organization
sonar.projectName=sonarqube_actions_demo
sonar.token=sqp_b7dc8e023b58eb785b11c6c468cda2b79eb6090b
sonar.host.url=http://localhost:9000
sonar.coverage.JaCoCo.xmlReportPaths=build/reports/JaCoCo/test/JaCoCoTestReport.xml

Add the “gradle-local.properties” file, build, and .gradle folders to the “.gitignore” file.


### Build ###
/build
/.gradle


### Custom file ###
gradle-local.properties

Create a build.yml file for the CI/CD workflow using GitHub Actions in the .github/workflows/ folder at the root of your project.


name: SonarQube




on:
 push:
   branches:
     - 'main'
 pull_request:
   branches:
     - main




jobs:
 branch-name-policy:
   name: branch-name-policy
   runs-on: ubuntu-latest
   steps:
     - name: Check PR source branch name
       shell: bash
       run: |
         if [ "${{ github.event_name }}" = "pull_request" ]; then
           BRANCH="${{ github.head_ref }}"
         else
           BRANCH="${{ github.ref_name }}"
         fi
         echo "PR head ref: $BRANCH"
         if [[ "$BRANCH" =~ ^(release/|hotfix/|feature/|bugfix/|test|main).* ]]; then
           echo "Allowed branch pattern: $BRANCH"
           exit 0
         else
           echo "::error ::Branch name '$BRANCH' is not allowed to merge into main. Allowed patterns: release/*, hotfix/*, feature/*, bugfix/*, test*"
           exit 1
         fi
 build:
   name: Build
   runs-on: ubuntu-latest
   container:
     image: eclipse-temurin:17-jdk
   steps:
     - name: Checkout source code to docker ubuntu container
       uses: actions/checkout@v4
       with:
         token: ${{ secrets.GITHUB_TOKEN }}
         fetch-depth: 0
     - name: Build project
       run: ./gradlew build -x test
 sast:
   needs:
     - build
   name: SonarQube Scan
   runs-on: ubuntu-latest
   steps:
     - name: Checkout source code to docker ubuntu container
       uses: actions/checkout@v4
       with:
         fetch-depth: 0




     - name: Cache SonarQube packages
       uses: actions/cache@v4
       with:
         path: ~/.sonar/cache
         key: ${{ runner.os }}-sonar
         restore-keys: ${{ runner.os }}-sonar




     - name: SonarQube Scan
       env:
         SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
         SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
         SONAR_ORGANIZATION_KEY: ${{ secrets.SONAR_ORGANIZATION_KEY }}
         SONAR_PROJECT_KEY: ${{ secrets.SONAR_PROJECT_KEY }}
         SONAR_PROJECT_NAME: ${{ secrets.SONAR_PROJECT_NAME }}
       run: ./gradlew sonar --info

Workflow name

This is the name that appears on the GitHub Actions UI.


name: SonarQube

Workflow trigger

This workflow runs on:

pushing changes to the main branch
pull requests that target the main branch


on:
 push:
   branches:
     - 'main'
 pull_request:
   branches:
     - main

Job Section

All jobs must be nested inside the job section.
The workflow contains three jobs:

branch-name-policy – validates branch naming
build – builds the application
sast (SonarQube scan) – performs the SonarQube scan


jobs:

branch-name-policy

Job branch-name-policy is the branch name policy validation. This job runs first. This ensures developers follow consistent branch naming patterns.
Advantages:

Keeps the repository clean
Improves automation
Prevents merging from incorrectly named branches


branch-name-policy:
   name: branch-name-policy
   runs-on: ubuntu-latest
   steps:
     - name: Check PR source branch name
       shell: bash
       run: |
         if [ "${{ github.event_name }}" = "pull_request" ]; then
           BRANCH="${{ github.head_ref }}"
         else
           BRANCH="${{ github.ref_name }}"
         fi
         echo "PR head ref: $BRANCH"
         if [[ "$BRANCH" =~ ^(release/|hotfix/|feature/|bugfix/|test|main).* ]]; then
           echo "Allowed branch pattern: $BRANCH"
           exit 0
         else
           echo "::error ::Branch name '$BRANCH' is not allowed to merge into main. Allowed patterns: release/*, hotfix/*, feature/*, bugfix/*, test*"
           exit 1
         fi

Steps inside the branch-name-policy job.

Step 1: Detect branch name.
GitHub uses different variables depending on the event. The script normalizes the variable so you always get the correct branch name.

Event	Branch variable
pull_request	${{ github.head_ref }}
push	${{ github.ref_name }}


 if [ "${{ github.event_name }}" = "pull_request" ]; then
           BRANCH="${{ github.head_ref }}"
         else
           BRANCH="${{ github.ref_name }}"
fi
         echo "PR head ref: $BRANCH"

Step 2: Validate Naming Convention

Allows only:

release/*
hotfix/*
feature/*
bugfix/*
test*
main Anything else fails with an error.


 if [[ "$BRANCH" =~ ^(release/|hotfix/|feature/|bugfix/|test|main).* ]]; then
           echo "Allowed branch pattern: $BRANCH"
           exit 0
         else
           echo "::error ::Branch name '$BRANCH' is not allowed to merge into main. Allowed patterns: release/*, hotfix/*, feature/*, bugfix/*, test*"
           exit 1
         fi

build

This job runs a build using Java 17 (Eclipse Temurin JDK).


build:
   name: Build
   runs-on: ubuntu-latest
   container:
     image: eclipse-temurin:17-jdk
   steps:
     - name: Checkout source code to docker ubuntu container
       uses: actions/checkout@v4
       with:
         token: ${{ secrets.GITHUB_TOKEN }}
         fetch-depth: 0
     - name: Build project
       run: ./gradlew build -x test

Build steps:

Step 1: Check out the code
Using fetch-depth: 0 ensures the full commit history is available. SonarQube requires this.


- name: Checkout source code to docker ubuntu container
  uses: actions/checkout@v4
  with:
    token: ${{ secrets.GITHUB_TOKEN }}
    fetch-depth: 0

Step 2: Build using Gradle.

This:

Compiles code
Packages artifacts
Skips tests (-x test) to keep the build fast.


 - name: Build project
   run: ./gradlew build -x test

sast

Job sast is for running SonarQube scan.


sast:
   needs:
     - build
   name: SonarQube Scan
   runs-on: ubuntu-latest
   steps:
     - name: Checkout source code to docker ubuntu container
       uses: actions/checkout@v4
       with:
         fetch-depth: 0




     - name: Cache SonarQube packages
       uses: actions/cache@v4
       with:
         path: ~/.sonar/cache
         key: ${{ runner.os }}-sonar
         restore-keys: ${{ runner.os }}-sonar




     - name: SonarQube Scan
       env:
         SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
         SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
         SONAR_ORGANIZATION_KEY: ${{ secrets.SONAR_ORGANIZATION_KEY }}
         SONAR_PROJECT_KEY: ${{ secrets.SONAR_PROJECT_KEY }}
         SONAR_PROJECT_NAME: ${{ secrets.SONAR_PROJECT_NAME }}
       run: ./gradlew sonar --info

sast job steps:

This job runs after the build. If the build fails, the sast job will not run.


sast:
   needs:
     - build

Step 1: Each job runs on a fresh machine.


     - name: Checkout source code to docker ubuntu container
       uses: actions/checkout@v4
       with:
         fetch-depth: 0

Step 2: Cache the scan. Caching speeds up your scans by reusing analyzer packages.
GitHub Actions reuses previously downloaded analyzers from a cache stored in your workflow runner.

Benefit::

Faster Sonar scans
Reduced network usage
More stable pipeline

SonarQube’s examples recommend caching for performance.


     - name: Cache SonarQube packages
       uses: actions/cache@v4
       with:
         path: ~/.sonar/cache
         key: ${{ runner.os }}-sonar
         restore-keys: ${{ runner.os }}-sonar

Step 3: Runs the SonarQube scan on your code.


 - name: SonarQube Scan
       env:
         SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
         SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
         SONAR_ORGANIZATION_KEY: ${{ secrets.SONAR_ORGANIZATION_KEY }}
         SONAR_PROJECT_KEY: ${{ secrets.SONAR_PROJECT_KEY }}
         SONAR_PROJECT_NAME: ${{ secrets.SONAR_PROJECT_NAME }}
       run: ./gradlew sonar --info

Authentication is done via GitHub secrets:

SONAR_TOKEN for authentication
SONAR_HOST_URL
SONAR_ORGANIZATION_KEY
SONAR_PROJECT_KEY
SONAR_PROJECT_NAME These are injected as environment variables:


       env:
         SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
         SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
         SONAR_ORGANIZATION_KEY: ${{ secrets.SONAR_ORGANIZATION_KEY }}
         SONAR_PROJECT_KEY: ${{ secrets.SONAR_PROJECT_KEY }}
         SONAR_PROJECT_NAME: ${{ secrets.SONAR_PROJECT_NAME }}

Create the “application.properties” file under the “sonarqube_actions_demo/src/main/resources” folder. Set the available port on your machine.


spring.application.name=sonarqube_actions_demo


server.port=8008

Create the “logback-spring.xml” logging configuration file under “sonarqube_actions_demo/src/main/resources” folder.


<configuration>
   <appender name="Console" class="ch.qos.logback.core.ConsoleAppender">
       <encoder>
           <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
       </encoder>
   </appender>


   <root level="INFO">
       <appender-ref ref="Console"/>
   </root>
</configuration>

Create a GitHub repository with the same name as the project.
Create a project in SonarQube Cloud at https://sonarcloud.io/projects/create

Select the project sonarqube_actions_demo and click “Set Up”

Select the new code definition as “Previous version” and click “Create project”.

Create repository secrets using GitHub Actions.
You can generate the SONAR_TOKEN value at https://sonarcloud.io/account/security

Click Github Actions

SonarQube will generate the SONAR_TOKEN for you. Click the Gradle button to view the project key and organization values. Copy and save these values so you can add them to your GitHub Actions repository secrets.

Create GitHub Actions at https://github.com/VardanMatevosyan/sonarqube_actions_demo/settings/secrets/actions

SONAR_HOST_URL = https://sonarcloud.io
SONAR_ORGANIZATION_KEY = sonar.organization
SONAR_PROJECT_KEY = sonar.organization
SONAR_TOKEN = generated token from the previous step
SONAR_PROJECT_NAME = sonarqube_actions_demo

Remove the auto-generated test files by the Spring Boot initializer from src/test/java/com/practice/sonarqube_actions_demo

Update the Gradle Wrapper to the 8.8 version by running the following command:


 gradle wrapper --gradle-version 8.8 --distribution-type bin

Build the project by running ./gradlew clean build, and then run Sonar locally using one of the previously mentioned approaches.
If you're using SonarCloud, use the project key from the sonar.projectKey property.

We can see two issues, but both are acceptable in our case.
The first one is a false positive because of how we use the variable, we only read the data and compare it with the actual branch name. No execution is involved. This warning refers to a script in the branch-name-policy job located in the build.yml file.

The second issue is our gradle-local.properties file, where we manually added the Sonar token. Since this file is included in .gitignore, we can safely accept this when our code is analyzed in SonarCloud.

As you can see, we get the analysis results immediately without having to push code to GitHub every time, which also helps avoid creating unnecessary commits.

Push the changes to GitHub.

Git commands:
Replace git@github.com:USERNAME/REPOSITORY.git with your GitHub repository link.

Results

All jobs are successful on GitHub.

In SonarCloud, go to the Projects section and select the sonarqube_actions_demo project. There, you will see the scanned results, but without Quality Gate. Free-plan users have access only to the default Quality Gate.

Let's protect our main branch on GitHub and then create a new Pull Request to see how it works.
Go to the Rulesets at https://github.com/VardanMatevosyan/sonarqube_actions_demo/settings/rules and create the Rule for the main branch.

Here are the configurations

Rules.

Enable “Require status checks to pass” and add three jobs by name that were included in the jobs section in the build.yml file.

Click Create.

Pull Request workflow jobs check

Check out the new branch from the main and make a simple change, as shown in the screenshot below. Push the changes and create a PR with those changes.

All jobs have passed.

Merge the changes. Once the changes are merged, you’ll see the jobs running on the main branches.

To view the GitHub Actions details, click one of the Details links related to a specific job. Then select the job you want to inspect, and choose any individual execution step to see its detailed information.

Let’s check the scanning results on SonarQube. Go to your project at https://sonarcloud.io/project/overview?id=VardanMatevosyan_sonarqube_actions_demo.

The “id=VardanMatevosyan” part of the link will differ depending on your GitHub username. You can see the scanning results for each branch or pull request in the “Latest Activity” section, as well as the Main branch status and the Main Branch evolution chart for issues, code coverage, and duplications.

When you click on a specific branch, you will see the scanning results only for the new code changes included in the particular Pull Request.

Let’s accept or mark the issue as a false positive that is acceptable for our application. Go to the main branch and click on the Issues tab.

Click on the Open status and select, for example, False Positive.

Write the comment.

Return to the project at https://sonarcloud.io/projects, and you will see that there are no remaining issues.

Failing the pipeline based on SonarQube's default Quality Gates for a free account

Let's implement an endpoint at /users/{id} to retrieve user information by ID.

Add dependencies to the “gradle.build” file in addition to the Spring Boot Web and logback. This is the complete list of dependencies:

H2 Database is an in-memory database for testing purposes.
Spring Boot JDBC is used in the persistence layer to interact with the database.
Spring Boot Test is used for unit tests of a Spring application.
JUnit 5 to write unit tests.
Lombok is to reduce boilerplate code.
MapStruct is used for easily mapping entities to DTO objects.


dependencies {
   // Spring boot runtime
   implementation 'org.springframework.boot:spring-boot-starter-web'
   implementation 'org.springframework.boot:spring-boot-starter-jdbc'


   // Persistence H2 for demo (optional)
   runtimeOnly 'com.h2database:h2'


   // Observability
   implementation 'ch.qos.logback:logback-classic:1.5.13'
   implementation 'ch.qos.logback:logback-core:1.5.19'




   // Test
   testImplementation 'org.springframework.boot:spring-boot-starter-test'
   testImplementation 'org.junit.jupiter:junit-jupiter:5.10.2'
   testImplementation 'com.h2database:h2'


   // Annotation processing
   compileOnly 'org.projectlombok:lombok:1.18.26'
   annotationProcessor 'org.projectlombok:lombok:1.18.26'
   implementation 'org.mapstruct:mapstruct:1.5.5.Final'
   annotationProcessor 'org.mapstruct:mapstruct-processor:1.5.5.Final'
}

Sourcecode structure

Controller


@RestController
@RequiredArgsConstructor
@FieldDefaults(level = AccessLevel.PRIVATE, makeFinal = true)
public class UserController {


   UserServiceImpl userService;


   @GetMapping("/users/{id}")
   public ResponseEntity<UserDto> getUser(@PathVariable Integer id) {
       UserDto user = userService.getUserById(id);
       return ResponseEntity.ok(user);
   }
}

Exception

DaoExcetion


public class DaoException extends RuntimeException {


   public DaoException(String message, Throwable cause) {
       super(message, cause);
   }


}

GlobalExceptionHandler


@RestControllerAdvice
public class GlobalExceptionHandler {


   @ExceptionHandler(NoSuchElementException.class)
   public ResponseEntity<ErrorResponse> handleException(NoSuchElementException exception) {
       HttpStatusCode httpStatusCode = HttpStatusCode.valueOf(HttpStatus.NOT_FOUND.value());
       ErrorResponse errorResponse = ErrorResponse.create(exception, httpStatusCode, exception.getMessage());
       return ResponseEntity.status(httpStatusCode).body(errorResponse);
   }


   @ExceptionHandler(value = {Exception.class, DaoException.class})
   public ResponseEntity<ErrorResponse> handleException(DaoException exception) {
       HttpStatusCode httpStatusCode = HttpStatusCode.valueOf(HttpStatus.INTERNAL_SERVER_ERROR.value());
       ErrorResponse errorResponse = ErrorResponse.create(exception, httpStatusCode, exception.getMessage());
       return ResponseEntity.status(httpStatusCode).body(errorResponse);
   }


   @ExceptionHandler(RuntimeException.class)
   public ResponseEntity<ErrorResponse> handleException(RuntimeException exception) {
       HttpStatusCode httpStatusCode = HttpStatusCode.valueOf(HttpStatus.BAD_REQUEST.value());
       ErrorResponse errorResponse = ErrorResponse.create(exception, httpStatusCode, exception.getMessage());
       return ResponseEntity.status(httpStatusCode).body(errorResponse);
   }




}

Mapper


@Mapper(componentModel = "spring")
public interface UserMapper {


   UserDto toDto(User user);


}

Model

UserDto


@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
@FieldDefaults(level = AccessLevel.PRIVATE)
public class UserDto {
   Integer id;
   String username;
   String email;
}

Entities

User


@Getter
@Setter
@AllArgsConstructor
@NoArgsConstructor
public class User {
   Integer id;
   String username;
   String email;
}

Persistence

UserDao


public interface UserDao {


   Optional<User> getUserById(Integer id);


}

UserDaoImpl


@Repository
@RequiredArgsConstructor
@FieldDefaults(level = AccessLevel.PRIVATE)
public class UserDaoImpl implements UserDao {


   final DataSource dataSource;


   public Optional<User> getUserById(Integer id) {
       String query = "SELECT id, username, email FROM users WHERE id = " + id;
       try (
               Connection connection = dataSource.getConnection();
               Statement ps = connection.prepareStatement(query)) {
           var rs = ps.executeQuery(query);
           if (rs.next()) {
               User user = buildUserEntity(rs);
               return Optional.of(user);
           }
           return Optional.empty();
       } catch (NullPointerException | SQLException e) {
           throw new DaoException("SQL error", e);
       }
   }


   private User buildUserEntity(ResultSet rs) throws SQLException {
       return new User(
               rs.getInt("id"),
               rs.getString("username"),
               rs.getString("email"));
   }
}

Service

UserService


public interface UserService {


   UserDto getUserById(Integer id);


}

UserServiceImpl


@Service
@RequiredArgsConstructor
public class UserServiceImpl implements UserService {


   final UserDao userDao;
   final UserMapper userMapper;


   public UserDto getUserById(Integer id) {
       requireNonNull(id, "id must not be null");
       return userDao.getUserById(id)
               .map(userMapper::toDto)
               .orElseThrow(() -> new NoSuchElementException("User not found with id: " + id));
   }


}

Database schema and data

Add “schema.sql” to create the users table and insert some testing data.


CREATE TABLE users (
  id INT PRIMARY KEY,
  username VARCHAR2(255),
  email VARCHAR2(255)
);


INSERT INTO users(id, username, email)
VALUES  (1, 'Alice', 'alice@example.com'),
       (2, 'Bob', 'bob@example.com'),
       (3, 'Admin', 'admin@example.com');

Application properties

Add these properties to the existing ones in the “application.properties” file.


# Database configuration
spring.datasource.url=jdbc:h2:mem:testdb;DB_CLOSE_DELAY=-1
spring.datasource.driver-class-name=org.h2.Driver
spring.datasource.username=sa
spring.datasource.password=password


# Enable H2 web console via http://localhost:8008/h2-console
spring.h2.console.enabled=true

Add a “gradle.properties” file to the root of the project. This property is required so GitHub waits for SonarCloud to return the scanning results. If you omit this, all scanning results will appear as passed.


systemProp.sonar.qualitygate.wait=true

Let’s run the application. As you can see, it returns the correct user data by the ID.

Now let’s run SonarQube locally from IntelliJ IDEA.

After scanning, SonarQube immediately shows one detected SQL Injection vulnerability. You can even see the suggested fix.

Let’s imagine that we forgot to run a SonarQube scan.
Pull the latest changes from the main branch and create a new branch that starts with feature/. Commit and push your changes. Then go to GitHub and create a Pull Request.
You can see that the Sonar job has failed.

For more details, you can click on the SonarQube Scan job.

Let’s check the SonarQube project dashboard at https://sonarcloud.io/project/overview?id=VardanMatevosyan_sonarqube_actions_demo

Then choose your branch

As you can see, it failed. Click to view the details. You will see that two conditions have failed.

Click on “Security Hotspot Reviewed”. As you can see, it shows the same result we saw locally.

The SQL injection vulnerability.

Fix the SQL Injection vulnerability by using the PreparedStatement class and setter methods to set the values.

UserDaoImpl class


@Repository
@RequiredArgsConstructor
@FieldDefaults(level = AccessLevel.PRIVATE)
public class UserDaoImpl implements UserDao {


   final DataSource dataSource;


   public Optional<User> getUserById(Integer id) {
       String query = "SELECT id, username, email FROM users WHERE id = ?";
       try (
               Connection connection = dataSource.getConnection();
               PreparedStatement ps = connection.prepareStatement(query)) {
           ps.setInt(1, id);
           var rs = ps.executeQuery();
           if (rs.next()) {
               User user = buildUserEntity(rs);
               return Optional.of(user);
           }
           return Optional.empty();
       } catch (NullPointerException | SQLException e) {
           throw new DaoException("SQL error", e);
       }
   }


   private User buildUserEntity(ResultSet rs) throws SQLException {
       return new User(
               rs.getInt("id"),
               rs.getString("username"),
               rs.getString("email"));
   }
}

Run Sonar locally, and you will not find any issues. Then push changes to a remote branch. The Sonar job still fails.

Look in the SonarQube dashboard, you'll see that the SQL Injection vulnerability is gone, but now the job is failing because tests and code coverage are missing. We'll explore this in the next section: “Adding unit tests and the JaCoCo plugin for code coverage.”

Even though we went through all of the steps from writing code up to creating a Pull Request, having the SonarQube plugin configured in your IDE is helpful in immediately detecting issues without running the application locally or pushing changes to your remote branch.

Adding unit tests and the JaCoCo plugin for code coverage

Add these changes to the “gradle.build” file:

JaCoCo plugin


id 'JaCoCo'

JaCoCo properties for SonarQube.
The config, mapper, model, and exception packages should be excluded from code coverage processing in SonarQube.


   property "sonar.coverage.JaCoCoxml.import", "true"
   property "sonar.java.coveragePlugin", "JaCoCo"
   property "sonar.coverage.JaCoCo.xmlReportPaths",
           System.getenv("SONAR_COVERAGE_JaCoCo_XML_REPORT_PATH")
                   ?: localProps["sonar.coverage.JaCoCo.xmlReportPaths"]
   property "sonar.coverage.exclusions", "**/config/**,**/mapper/**,**/model/**,**/exception/**"

JaCoCo configuration


JaCoCo {
   toolVersion = "0.8.12"
}


JaCoCoTestReport {
   dependsOn test
   reports {
       xml.required = true
       html.required = true
       csv.required = false
   }


   afterEvaluate {
       classDirectories.setFrom(files(classDirectories.files.collect {
           fileTree(dir: it, exclude: ['**/config/**', '**/model/**', '**/exception/**', '**/mapper/**'])
       }))
   }
}


JaCoCoTestCoverageVerification {
   dependsOn JaCoCoTestReport
   violationRules {
       rule {
           enabled = true
           element = 'BUNDLE'


           limit {
               counter = 'LINE'
               value = 'COVEREDRATIO'
               minimum = 0.90
           }


           limit {
               counter = 'BRANCH'
               value = 'COVEREDRATIO'
               minimum = 0.65
           }


           limit {
               counter = 'METHOD'
               value = 'COVEREDRATIO'
               minimum = 0.90
           }


           limit {
               counter = 'CLASS'
               value = 'COVEREDRATIO'
               minimum = 0.90
           }
       }
   }


   afterEvaluate {
       classDirectories.setFrom(files(classDirectories.files.collect {
           fileTree(dir: it, exclude: ['**/config/**', '**/model/**', '**/exception/**', '**/mapper/**'])
       }))
   }
}

Update the task test by adding this line at the end


 finalizedBy JaCoCoTestReport

The complete “gradle.build” file


plugins {
   id 'java'
   id 'JaCoCo'
   id "org.sonarqube" version "7.0.0.6105"
   id 'org.springframework.boot' version '3.0.0'
   id 'io.spring.dependency-management' version '1.1.7'
}


group = 'com.practice'
version = '0.0.1-SNAPSHOT'
description = 'sonarqube_actions_demo'


java {
   toolchain {
       languageVersion = JavaLanguageVersion.of(17)
   }
}


configurations {
   compileOnly {
       extendsFrom annotationProcessor
   }
}


repositories {
   mavenCentral()
}


dependencies {
   // Spring boot runtime
   implementation 'org.springframework.boot:spring-boot-starter-web'
   implementation 'org.springframework.boot:spring-boot-starter-jdbc'


   // Persistence H2 for demo (optional)
   runtimeOnly 'com.h2database:h2'


   // Observability
   implementation 'ch.qos.logback:logback-classic:1.5.13'
   implementation 'ch.qos.logback:logback-core:1.5.19'




   // Test
   testImplementation 'org.springframework.boot:spring-boot-starter-test'
   testImplementation 'org.junit.jupiter:junit-jupiter:5.10.2'
   testImplementation 'com.h2database:h2'


   // Annotation processing
   compileOnly 'org.projectlombok:lombok:1.18.26'
   annotationProcessor 'org.projectlombok:lombok:1.18.26'
   implementation 'org.mapstruct:mapstruct:1.5.5.Final'
   annotationProcessor 'org.mapstruct:mapstruct-processor:1.5.5.Final'
}




def localProps = new Properties()
def localFile = file("gradle-local.properties")
if (localFile.exists()) {
   localProps.load(localFile.newDataInputStream())
}


sonar {
   properties {
       property "sonar.coverage.JaCoCoxml.import", "true"
       property "sonar.java.coveragePlugin", "JaCoCo"
       property "sonar.coverage.JaCoCo.xmlReportPaths",
               System.getenv("SONAR_COVERAGE_JaCoCo_XML_REPORT_PATH")
                       ?: localProps["sonar.coverage.JaCoCo.xmlReportPaths"]
       property "sonar.projectKey", System.getenv("SONAR_PROJECT_KEY") ?: localProps["sonar.projectKey"]
       property "sonar.organization", System.getenv("SONAR_ORGANIZATION_KEY") ?: localProps["sonar.organization"]
       property "sonar.projectName", System.getenv("SONAR_PROJECT_NAME") ?: localProps["sonar.projectName"]
       property "sonar.token", System.getenv("SONAR_TOKEN") ?: localProps["sonar.token"]
       property "sonar.host.url", System.getenv("SONAR_HOST_URL") ?: localProps["sonar.host.url"]
       property "sonar.coverage.exclusions", "**/config/**,**/mapper/**,**/model/**,**/exception/**"
   }
}




JaCoCo {
   toolVersion = "0.8.12"
}


JaCoCoTestReport {
   dependsOn test
   reports {
       xml.required = true
       html.required = true
       csv.required = false
   }


   afterEvaluate {
       classDirectories.setFrom(files(classDirectories.files.collect {
           fileTree(dir: it, exclude: ['**/config/**', '**/model/**', '**/exception/**', '**/mapper/**'])
       }))
   }
}


JaCoCoTestCoverageVerification {
   dependsOn JaCoCoTestReport
   violationRules {
       rule {
           enabled = true
           element = 'BUNDLE'


           limit {
               counter = 'LINE'
               value = 'COVEREDRATIO'
               minimum = 0.90
           }


           limit {
               counter = 'BRANCH'
               value = 'COVEREDRATIO'
               minimum = 0.65
           }


           limit {
               counter = 'METHOD'
               value = 'COVEREDRATIO'
               minimum = 0.90
           }


           limit {
               counter = 'CLASS'
               value = 'COVEREDRATIO'
               minimum = 0.90
           }
       }
   }


   afterEvaluate {
       classDirectories.setFrom(files(classDirectories.files.collect {
           fileTree(dir: it, exclude: ['**/config/**', '**/model/**', '**/exception/**', '**/mapper/**'])
       }))
   }
}


tasks.named('test') {
   useJUnitPlatform()
   finalizedBy JaCoCoTestReport
}

Test package structure

We need to add the “data.sql” file. This script inserts testing data into the database. You can access them while running tests.


INSERT INTO users (id, username, email)
VALUES (10, 'alice', 'alice@example.com'),
      (11, 'bob', 'bob@example.com');

UseControllerTest


@WebMvcTest(UserController.class)
class UserControllerTest {


   @Autowired
   private MockMvc mockMvc;


   @MockBean
   private UserServiceImpl userService;


   @Test
   void getUser_shouldReturnUserDto_whenUserExists() throws Exception {
       // Arrange
       Integer userId = 1;
       UserDto userDto = new UserDto(userId, "jane_doe", "jane@example.com");
       when(userService.getUserById(userId)).thenReturn(userDto);


       // Act and Assert
       mockMvc.perform(get("/users/{id}", userId)
                       .contentType(MediaType.APPLICATION_JSON))
               .andExpect(status().isOk())
               .andExpect(jsonPath("$.id").value(userDto.getId()))
               .andExpect(jsonPath("$.username").value(userDto.getUsername()))
               .andExpect(jsonPath("$.email").value(userDto.getEmail()));


       verify(userService).getUserById(userId);
   }


   @Test
   void getUser_shouldReturn500_whenUserServiceThrowsException() throws Exception {
       // Arrange
       Integer userId = 999;
       when(userService.getUserById(userId))
               .thenThrow(new NoSuchElementException("User not found with id: " + userId));


       // Act and Assert
       mockMvc.perform(get("/users/{id}", userId)
                       .contentType(MediaType.APPLICATION_JSON))
               .andExpect(status().is4xxClientError());


       verify(userService).getUserById(userId);
   }
}

UserDaoImplTest


@JdbcTest
@TestPropertySource(properties = {
       "spring.datasource.url=jdbc:h2:mem:testdb;DB_CLOSE_DELAY=-1",
       "spring.datasource.driver-class-name=org.h2.Driver"
})
class UserDaoImplTest {


   @Autowired
   private DataSource dataSource;


   private UserDaoImpl userDao;


   @BeforeEach
   void setUp() {
       this.userDao = new UserDaoImpl(dataSource);
   }


   @Test
   void getUserById_shouldReturnUser_whenUserExists() {
       // Arrange
       int userId = 10;
       // Act
       var userOpt = userDao.getUserById(userId);


       // Assert
       assertThat(userOpt).isPresent();
       User user = userOpt.get();
       assertThat(user.getId()).isEqualTo(userId);
       assertThat(user.getUsername()).isEqualTo("alice");
       assertThat(user.getEmail()).isEqualTo("alice@example.com");
   }


   @Test
   void getUserById_shouldReturnEmpty_whenUserDoesNotExist() {
       // Act
       var userOpt = userDao.getUserById(999);


       // Assert
       assertThat(userOpt).isEmpty();
   }


   @Test
   void getUserById_shouldReturnEmpty_whenIdIsNull() {
       // Assert and Act
       assertThatException()
               .isThrownBy(() -> userDao.getUserById(null))
               .isInstanceOf(DaoException.class)
               .withMessage("SQL error");
   }
}

UserServiceImplTest


@ExtendWith(MockitoExtension.class)
class UserServiceImplTest {


   @Mock
   private UserDao userDao;


   @Mock
   private UserMapper userMapper;


   @InjectMocks
   private UserServiceImpl userService;


   @Test
   void test_whenGetUserById_shouldReturnUserDto_whenUserExists() {
       // Arrange
       Integer userId = 1;
       User user = new User(userId, "john_doe", "john@example.com");
       UserDto userDto = new UserDto(userId, "john_doe", "john@example.com");


       when(userDao.getUserById(userId)).thenReturn(Optional.of(user));
       when(userMapper.toDto(user)).thenReturn(userDto);


       // Act
       UserDto result = userService.getUserById(userId);


       // Assert
       assertThat(result).isEqualTo(userDto);
       verify(userDao).getUserById(userId);
       verify(userMapper).toDto(user);
   }


   @Test
   void test_whenGetUserById_shouldThrowNoSuchElementException_whenUserNotFound() {
       // Arrange
       Integer userId = 999;
       when(userDao.getUserById(userId)).thenReturn(Optional.empty());


       // Act and Assert
       assertThatThrownBy(() -> userService.getUserById(userId))
               .isInstanceOf(NoSuchElementException.class)
               .hasMessage("User not found with id: " + userId);


       verify(userDao).getUserById(userId);
       verify(userMapper, never()).toDto(any());
   }


   @Test
   void getUserById_shouldHandleNullId() {
       // Act and Assert
       assertThatThrownBy(() -> userService.getUserById(null))
               .isInstanceOf(NullPointerException.class)
               .hasMessage("id must not be null");
   }
}

Update “build.yml” file.
Add test_and_coverage next to the build job.


test_and_coverage:
 name: Test and Coverage
 runs-on: ubuntu-latest
 container:
   image: eclipse-temurin:17-jdk
 steps:
   - name: Checkout source code to docker ubuntu container
     uses: actions/checkout@v4
     with:
       token: ${{ secrets.GITHUB_TOKEN }}
       fetch-depth: 0
   - name: Run tests with coverage
     run: ./gradlew JaCoCoTestCoverageVerification
   - name: Upload test results
     uses: actions/upload-artifact@v4
     with:
       name: test-coverage-report
       path: 'build'
       overwrite: true
       retention-days: 5

Add the test_and_coverage job after the build job under the needs section for the sast job.
This configuration ensures that the sast job will wait until the build and test_and_coverage jobs have completed their execution.


sast:
 needs:
   - build
   - test_and_coverage

Add these two sast steps after the “Cache SonarQube packages” step. First one download the JaCoCo report saved by the previous test_and_coverage job execution. The second one is to check if the report exists.


- name: Download JaCoCo report
  uses: actions/download-artifact@v4
  with:
   name: test-coverage-report
   path: .


- name: Verify report exists
  run: |
   ls -la ./reports/JaCoCo/test

Complete “build.yml” file.


name: SonarQube


on:
 push:
   branches:
     - 'main'
 pull_request:
   branches:
     - main


jobs:
 branch-name-policy:
   name: branch-name-policy
   runs-on: ubuntu-latest
   steps:
     - name: Check PR source branch name
       shell: bash
       run: |
         if [ "${{ github.event_name }}" = "pull_request" ]; then
           BRANCH="${{ github.head_ref }}"
         else
           BRANCH="${{ github.ref_name }}"
         fi
         echo "PR head ref: $BRANCH"
         if [[ "$BRANCH" =~ ^(release/|hotfix/|feature/|bugfix/|test|main).* ]]; then
           echo "Allowed branch pattern: $BRANCH"
           exit 0
         else
           echo "::error ::Branch name '$BRANCH' is not allowed to merge into main. Allowed patterns: release/*, hotfix/*, feature/*, bugfix/*, test*"
           exit 1
         fi
 build:
   name: Build
   runs-on: ubuntu-latest
   container:
     image: eclipse-temurin:17-jdk
   steps:
     - name: Checkout source code to docker ubuntu container
       uses: actions/checkout@v4
       with:
         token: ${{ secrets.GITHUB_TOKEN }}
         fetch-depth: 0
     - name: Build project
       run: ./gradlew build -x test
 test_and_coverage:
   name: Test and Coverage
   runs-on: ubuntu-latest
   container:
     image: eclipse-temurin:17-jdk
   steps:
     - name: Checkout source code to docker ubuntu container
       uses: actions/checkout@v4
       with:
         token: ${{ secrets.GITHUB_TOKEN }}
         fetch-depth: 0
     - name: Run tests with coverage
       run: ./gradlew JaCoCoTestCoverageVerification
     - name: Upload test results
       uses: actions/upload-artifact@v4
       with:
         name: test-coverage-report
         path: 'build'
         overwrite: true
         retention-days: 5
 sast:
   needs:
     - build
     - test_and_coverage
   name: SonarQube Scan
   runs-on: ubuntu-latest
   steps:
     - name: Checkout source code to docker ubuntu container
       uses: actions/checkout@v4
       with:
         fetch-depth: 0


     - name: Cache SonarQube packages
       uses: actions/cache@v4
       with:
         path: ~/.sonar/cache
         key: ${{ runner.os }}-sonar
         restore-keys: ${{ runner.os }}-sonar


     - name: Download JaCoCo report
       uses: actions/download-artifact@v4
       with:
         name: test-coverage-report
         path: .


     - name: Verify report exists
       run: |
         ls -la ./reports/JaCoCo/test


     - name: SonarQube Scan
       env:
         SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
         SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
         SONAR_ORGANIZATION_KEY: ${{ secrets.SONAR_ORGANIZATION_KEY }}
         SONAR_PROJECT_KEY: ${{ secrets.SONAR_PROJECT_KEY }}
         SONAR_PROJECT_NAME: ${{ secrets.SONAR_PROJECT_NAME }}
       run: ./gradlew sonar --info

Push the changes to the remote branch and check the state of the Pull Request’s jobs execution results. The pipeline failed because one last piece is missing.

We need to add the JaCoCo test coverage report path in the SonarQube configuration for this project. This can be done by navigating to the SonarQube project, Administration, located in the bottom-left corner, and then General Settings. Paste reports/JaCoCo/test/JaCoCoTestReport.xml and click save.

Go to GitHub, click on the SoarQube job to navigate to the GitHub Actions page. Click on the Sonar job and re-run the job.

Now all jobs have passed.

Return to the Pull Request page, and now you can merge the changes to the main branch.

Merge the changes, and verify that all jobs pass after merging to the main branch.

Verify that test coverage appears on the SonarQube project. It shows the overall test coverage percentage. If you need charts on code coverage, click on the project and select the Coverage header at the top of the “Main Branch Evolution” section.

Conclusion

Effective SAST implementation has to be smoothly integrated into your development and deployment processes. This article demonstrates how to maximize the benefits of SonarCloud, including local scanning with IntelliJ IDEA and Docker, integrating scans with GitHub Actions pipelines, and enhancing code coverage through unit testing and the JaCoCo plugin.

You can keep your codebase secure and prevent vulnerabilities from reaching production by enforcing quality gates and managing false positives. By implementing these practices in your SSDLC, you are not only strengthening the security but also establishing an environment of quality and accountability within your development teams.

Start applying these steps today to improve software security with continuous and automated SAST.

Catch vulnerabilities before they ship: local SonarQube setup (Part 2)

Vardan Matevosian — Tue, 09 Dec 2025 12:05:00 +0000

Note: Click on the image to see a larger (original) version.

Introduction

Static Application Security Testing (SAST) is a crucial practice within the Software Security Development Life Cycle (SSDLC) that enables developers to identify security vulnerabilities early in the code development phase. While understanding the concepts of SAST is important, implementing it effectively in real-world projects is what ensures robust and secure software delivery.

In this second part of our SAST series, we focus on integrating the SonarQube Cloud, a popular static analysis tool, into the IntelliJ IDEA and running it using Docker.

We will explore:

SonarQube Cloud for SAST
Local scanning with SonarQube Cloud via IntelliJ IDEA
Local scanning using Docker Compose with SonarQube image

Tools:

SonarQube Cloud
Spring Boot
IntelliJ IDEA
Docker-Compose

Prerequisites:

Create a Spring Boot project using IntelliJ IDEA or the Spring Boot Initializr at https://start.spring.io/.
Click Next and generate the project without dependencies.

SonarQube Cloud for SAST

SonarQube Cloud offers a hassle-free way to start static code analysis without managing your own infrastructure. It provides cloud-hosted scanning capabilities that analyze code quality, security vulnerabilities, bugs, and code smells.

Setting Up SonarQube Cloud

Create an account: Visit SonarQube’s official website and sign up for a free or paid cloud account.
Create a new project: Once logged in, create a new project by providing your repository details.
Generate an authentication token: For integrating scanning tools, generate a security token from your account settings. We must store it in a secret place, like in the GitHub Actions environment or repository secret.
Configure project settings: We need to set Quality Gates, SLAs, and rules according to our security policy. For a free account, we cannot create the Quality Gates; we must use the default one.

SonarQube Cloud then becomes the central place to view detailed security reports and code quality metrics.

Overview of SonarQube’s cloud capabilities for static code analysis

SonarCloud is a fully managed SaaS platform for continuous static code analysis, designed to detect code quality issues, security vulnerabilities, and maintainability risks across modern software projects. It provides code coverage plugin integration that is used by 30+ different programming languages, including Java, Python, C#, JavaScript, TypeScript, and Go.

Capabilities:

Cloud-hosted and fully managed: SonarCloud removes the need for installation, hosting, or maintenance. This allows teams to focus solely on development and CI/CD pipelines. Use the cloud version if your company does not work under compliance regulations.

SonarSource manages:
- uptime
- scaling
- rule updates
- language analyzers
- security patches
Deep Static Code Analysis: SonarCloud performs comprehensive static analysis across many dimensions:
- Bug Detection. Identifies code paths that can lead to crashes, incorrect logic, or unintended behavior.
- Security vulnerability detection. Finds CWE-based, OWASP-aligned issues such as:
  - SQL Injection
  - Path traversal
  - Input validation issues
  - Hardcoded secrets
  - Command injection
  - Code Smells. Flags maintainability issues, duplicated code, bad design, and anti-patterns.
- Cognitive Complexity. Measures how difficult code is to understand and maintain.
- Multi-language support. Supports 30+ languages, including Java, Python, JavaScript, TypeScript, Go, C#, Kotlin, PHP, Terraform, YAML, and more.
Seamless CI/CD integration: SonarCloud integrates natively with:
- CI providers:
  - GitHub Actions
  - Azure Pipelines
  - Bitbucket Pipelines
  - GitLab CI
- Build tools: SonarQube provides integrations with build tools. For example, in our case, the Gradle Sonar plugin is used to run Sonar Scanner in the CI/CD pipeline.
Pull request and branch analysis: SonarCloud performs inline analysis during PR reviews, preventing issues from reaching the main branch. The free plan does not support this.
Quality Gates: A Quality Gate defines the rules that code must satisfy before being merged. If a PR fails the Quality Gate, the CI pipeline can block the merge. Adding custom Quality Gates is not supported by the free plan.

Default checks include:
- No new critical or blocker issues.
- Code coverage must meet a minimum threshold.
- No new bugs or security vulnerabilities.
- No new code duplications.
Test coverage and code metrics: SonarCloud provides overall coverage and new code coverage, for example, for a specific PR or branch.
Organization and project dashboards: SonarCloud provides rich dashboards for:
- Centralized issue tracking.
- Historical trend charts for issues, code coverage, and duplications.
- Hotspot security review.
- Code coverage progress.
- History of activities for each branch or PR.
Notifications and integrations: Supports notifications via:
- GitHub checks.
- GitLab merge requests.
- Slack.
- Email.
- Webhooks.
Open APIs and extensions: SonarQube provides APIs to build custom dashboards and export metrics.

Local scanning with SonarQube Cloud via IntelliJ IDEA

Running local scans during development helps catch issues early before code is committed.

Installing and configuring the SonarQube plugin in IntelliJ IDEA

Open IntelliJ IDEA.
Navigate to File > Settings > Plugins and search for the "SonarQube" plugin.
Install and restart the IDE. It must appear in the “Installed” section.

Generate the authentication Sonar token. Go to the SonarCloud website, then My Account > Security > Generate Token, or click on this link https://sonarcloud.io/account/security/, and you will be redirected to the token generation page. Enter the name of the token, typically where you want to use it, and click the “Generate Token” button.

Configure the plugin by adding your SonarQube Cloud server URL and authentication token. Click on the SonarQube plugin icon, then select the gear icon, as shown in the screenshot.

Enter the Project key of your SonarQube project and click “Configure the connection”.

You will see the Connection section, click the plus to add a new connection.

Enter the name of the connection and click “Next”.

Paste the generated token, or you can even create the token from this IDE window. Click “Next”, and the IDE will attempt to connect to Sonar Cloud. You will see that authentication is successful if the connection is established.

Running local scans

After configuration, you can run SonarQube scans directly from the IDE. The plugin highlights issues inline and provides quick access to detailed analysis reports. Click “Analyze All Project Files”.

You can see the results. In this case, it found the token in the gradle-local.properties file, which is ignored by the .gitignore file, and it is only for local purposes. However, you will still see it unless you exclude it from scanning. This plugin also allows you to do it.

Below you can see the result of this specific finding. Additionally, the plugin provides information on why this issue occurs and how to resolve it.

Benefits of local scanning:

Immediate feedback on security and quality issues.
Reduces the likelihood of pushing vulnerable code.
Saves time by fixing problems early in the development workflow.

Local scanning using Docker Compose with SonarQube image

If you prefer running SonarQube locally, Docker provides an easy setup that eliminates the need for complex installation.

Setting up SonarQube locally via Docker Compose

Create a “docker-compose.yml” file with the following content:

    version: "3.9"


    services:
     sonarqube:
       image: sonarqube:latest
       ports:
         - "9000:9000"
       environment:
         SONAR_ES_BOOTSTRAP_CHECKS_DISABLE: "true"
       volumes:
         - sonarqube_data:/opt/sonarqube/data
         - sonarqube_extensions:/opt/sonarqube/extensions


    volumes:
     sonarqube_data:
     sonarqube_extensions:

Here is the gradle-local.properties file.

Place it in the root of the project and add it to the .gitignore.

    systemProp.sonar.qualitygate.wait=true


    sonar.projectKey=sonarqube_actions_demo_key
    sonar.organization=local-organization
    sonar.projectName=sonarqube_actions_demo
    sonar.token=sqp_b7dc6e025b58eb7455b11c6c468cda2b79eb6450b
    sonar.host.url=http://localhost:9000
    sonar.coverage.jacoco.xmlReportPaths=build/reports/jacoco/test/jacocoTestReport.xml

Gradle configuration. The SonarQube plugin is required.

    plugins {
       id 'java'
       id "org.sonarqube" version "7.0.0.6105"
       id 'jacoco'
       id 'org.springframework.boot' version '3.0.0'
       id 'io.spring.dependency-management' version '1.1.7'
    }

SonarQube properties

    def localProps = new Properties()
    def localFile = file("gradle-local.properties")
    if (localFile.exists()) {
    localProps.load(localFile.newDataInputStream())
    }


    sonar {
    properties {
       property "sonar.projectKey", System.getenv("SONAR_PROJECT_KEY") ?: localProps["sonar.projectKey"]
       property "sonar.organization", System.getenv("SONAR_ORGANIZATION_KEY") ?: localProps["sonar.organization"]
       property "sonar.projectName", System.getenv("SONAR_PROJECT_NAME") ?: localProps["sonar.projectName"]
       property "sonar.token", System.getenv("SONAR_TOKEN") ?: localProps["sonar.token"]
       property "sonar.host.url", System.getenv("SONAR_HOST_URL") ?: localProps["sonar.host.url"]
    }
    }

Run the following command to start the container: docker-compose up -d, or you can run it from your IntelliJ IDEA

You can see the container is up and running

Access SonarQube dashboard at http://localhost:9000. Login is admin, but you will need to change the password from admin to a new one.

Click Create project from the top right corner.

Enter the same name and project key as in your gradle-local.properties file. Then select to use the previous version.

Choose Locally as the Analysis Method

Type the name of the token and click Generate, then Continue, and set it in the gradle-local.properties file to the “sonar.token” property like

properties sonar.token=sqp_b7dc6e025b58eb7455b11c6c468cda2b79eb6450b

.

If you want to generate manually, you can do it as shown in the screenshot below.

Run the Sonar scan from the command line or from IntelliJ IDEA

Use this command ./gradlew sonar --info or run from your IntelliJ IDEA

You can view the result by going to the Projects tab. The metrics and coverage are for the main branch only and show overall coverage and metrics. For more details about the new code analysis, click on the project.

Comparing Local Docker Setup with Cloud Scanning

Cloud: No maintenance, scalable, accessible anywhere.
Local Docker: Full control, ideal if you have no internet connection for an extended period but need to review scan results, useful for sensitive projects.

Conclusion

This article demonstrates how to maximize the benefits of SonarCloud by scanning locally with IntelliJ IDEA or Docker. This helps prevent insecure code from being pushed even to a feature branch and allows developers to work more productively.

Closing

This article covered SonarQube Cloud configuration and IntelliJ IDEA integration, as well as running SonarQube locally with Docker. In “Automating code security in CI/CD: SonarCloud SAST guide (Part 3)”, we will explore practical integration examples, configuration patterns, and CI/CD pipelines.

The Secret Behind SAST: The Security Blind Spot Developers Can’t Ignore (Part 1)

Vardan Matevosian — Sat, 06 Dec 2025 17:41:46 +0000

Itroduction

The first part of this article provides a robust theoretical foundation for understanding SAST and its importance in ensuring secure development. Additionally, the subsequent articles (Part 2, and Part 3) will delve into practical examples and effective implementation strategies.

In the field of modern software engineering, it is not only required to provide features on time but also to ensure their security. As companies refine their Secure Software Development Life Cycle (SSDLC) strategies, one essential aspect that stands out is Static Application Security Testing (SAST).

What is SAST?

SAST, or Static Application Security Testing, refers to a type of security testing that identifies and addresses potential vulnerabilities in software code. SAST involves examining source code, bytecode, or binaries without running the actual application by scanning the codebase for known vulnerability patterns.

Source code refers to the human-readable code written by developers.

Bytecode refers to the compiled form of source code that a virtual machine or runtime can execute, which can be analyzed by SAST tools to detect errors, vulnerabilities, or performance issues before deployment. For example, in Java .class files – the compiled Java classes generated from .java source files.

Binaries refer to compiled artifacts; in Java, these are typically .jar files, which are Java archives containing .class files and sometimes additional resources such as properties or XML files.

This tool can detect security weaknesses early on, which covers bugs, code smells, and the latest at this moment, 2021 OWASP TOP 10 categories, such as:

SAST tools analyze program components, including code structure, data flows, and control flows, to identify potential security vulnerabilities before the software is developed or deployed.

Control flow refers to the order in which individual statements, instructions, or functions in a program are executed.

Data flow refers to the movement of data through a program, specifically how values are assigned, modified, and passed between variables, functions, or modules. It defines how data travels and transforms during execution. One example is detecting tainted data. Tainted data refers to identifying untrusted or potentially dangerous input in a program that could flow into sensitive operations (called “sinks”) without proper validation or sanitization.

Control flow determines the sequence of execution in a program, while data flow tracks how data values propagate and transform through that execution.

Aspect	Control Flow	Data flow
What it describes	Execution order or decision paths	How data moves and changes
Examples	Loops, conditionals, function calls	Variable assignments, method parameters, and return values
Use in SAST	Detect unreachable code, infinite loops, and so on	Detect tainted data, SQL injection, and logging sensitive info

Some of the tools classified as SAST are:

Semgrep, PMD, SpotBugs, and FindSecBugs - popular open-source tools for code analysis and bug detection.
Fortify, Checkmarx, and Veracode - reliable enterprise solutions.
Snyk, SonarQube Cloud, and GitHub CodeQL - cloud-based or SaaS tools.

The importance of SAST in secure development cannot be overstated.

Implementing SAST within SSDLC enables the efficient implementation of large-scale security measures by:

Detecting problems early on
Halting the advancement of vulnerable code through the pipeline, SAST minimizes both time and expense associated with remediation.
Incorporating security earlier in the development process
Feedback is provided to developers during the commit or pull request process while the context is still fresh, allowing for any necessary fixes to be made more easily.
Promoting the education of developers.
SAST findings facilitate the organic acquisition of secure coding patterns by developers, promoting the integration of security as a daily practice.
Minimizing risk in the manufacturing process

By addressing vulnerabilities early on in the SDLC or live systems, there is a lower occurrence of security incidents. Several compliance frameworks, such as ISO 27001, SOC2, and PCI DSS, require the inclusion of static security testing in secure development governance.

How to integrate SAST into CI/CD?

The integration of SAST into the development lifecycle is essential for its optimal effectiveness.

Developer local environment (can be optional, but recommended)

Run lightweight SAST tools locally (Semgrep, CodeQL CLI, Snyk CLI, SonarQube local server using Docker) or run IDE plugins such as SonarQube Cloud that can connect easily from the IDE to the SonarQube Cloud server before pushing code.
Helps reduce noise in the CI pipeline or incidentally pushes sensitive data to the GIT repository.

Pull request (PR) and merge request (MR) stage

Protect the main branches from merging directly until all pipeline jobs are SUCCESSFUL. If Git Flow is used, protected branches typically are: dev, qa, or staging, pre-prod, and prod.
Trigger a SAST scan on each PR/MR.
Block merging if findings exceed severity thresholds, for example, by configuring Quality Gate in SonarQube or other severity-related policies. You can configure the CI/CD pipeline to FAIL if, for example, 1 Critical and/or 3 High vulnerabilities are detected.
Use the SAST tool’s suggestions on how to resolve the issue.
Investigate the findings to identify potential false positives. SAST scanners provide useful information about each vulnerability, making it easier to understand them.

CI pipeline

Add SAST as an early stage. Depends on the project; it can be after the build and test stage or before it, if only the source code is used to scan the project, but the recommended approach is to use it after, because you can configure it to scan for binaries or bytecode.
Fail builds based on:
- severity level (Low, Medium, High, Critical)
- the count of severity levels (for example, 20 Medium, 5 High, 2 Critical)
- security policy rules
- code smells

Scheduled full scans

Run nightly or weekly deep scans on the entire codebase. For example, Snyk scans the project by default once a week and sends the report to the user’s email (this is a SaaS tool, and it depends on whether the company is allowed to send the codebase to other services for scanning for vulnerabilities).
Capture findings not detected in incremental scans.

Governance

Export results into an issue tracker (such as Jira) or a SIEM (Security Information and Event Management) system. Some of the SAST tools allow the creation of an issue ticket in Jira.
Track remediation SLAs (Service Level Agreement) by severity:
- Critical issues fixed within 24 hours
- High-severity fix within 3 days
- Medium 7–14 days
- Low 30+ days
Maintain centralized dashboards (SonarQube, Snyk, DefectDojo).

The key principle: SAST must become a non-negotiable quality gate, just like unit tests, linters, or build verifiers.

Why do some companies run SAST within CVS instead of SaaS tools?

While modern SaaS security platforms are powerful, many enterprises still run SAST inside their version-control system (CVS) or self-hosted environments.

Data protection and compliance

Source code is often the company’s most sensitive intellectual property.
Some industries, such as finance, defense, and telecom, cannot upload code to external SaaS due to:

Data residency restrictions
Regulatory constraints
Confidentiality concerns

Full control and custom rules

Self-hosted SAST (SonarQube Enterprise, Checkmarx On-Premise) offers:

Custom rule tuning for domain-specific patterns
Control over scanner performance and scheduling
On-prem log retention and audit trails

No external vendor dependency
Large organizations want predictable SLAs and reliability without relying on external service uptime or rate limits. Companies often use cloud VMs (Virtual Machines) with autoscaling that make the server available even if one goes down, especially when all infrastructure is deployed on a specific cloud provider like AWS, Azure, and GCP. Still, it is more difficult to configure and maintain your own server compared to SaaS alternatives.

Cost optimization at scale

SaaS SAST tools are charged per seat or LOC (lines of code).
For large organizations with millions of LOC, on-premise licensing might be more efficient.
This doesn't make SaaS solutions inferior; they are excellent for small to mid-sized companies or teams that prefer zero maintenance overhead, but big enterprises often choose to keep scanning where the codebase is located or self-hosted.

How does SAST strengthen your application before deployment?

SAST adds many layers of security reinforcement before one line is deployed:

Eliminates vulnerabilities at the earliest point. Fixing issues in development prevents vulnerabilities from ever entering later stages.
Reduces attack surface. Every resolved injection flaw, every sanitized input, and every removed secret reduces the exploitable surface in production.
Improved code quality. Most of the SAST rules lead to improved code clarity, design patterns, and maintainability.
Drives security culture. SAST is an enabler of secure software development practices. Teams start thinking in terms of:
- safe patterns
- least-privilege design
- secure defaults
- flow validation

SAST best practices

To maximize the value of SAST in SSDLC:

Start with a minimal and focused rule set. Avoid overwhelming developers. Enable rules progressively.
Integrate into PR pipelines.
Make SAST feedback part of the daily development routine.
Use severity thresholds. These configurations can differ from company to company.
Avoid false positives. Not all findings are equal; that is why you need to tune rules to reduce false positives. Even if the finding’s severity level is High and it may appear to be a serious issue, it depends on how the feature or script was implemented.
Establish SLAs for remediation. For example:
- Critical: fix within 1-2 days.
- High: fix within 5-7 days.
- Medium: fix within 30 days.
Combine with other AST tools. SAST is one part of the security puzzle. Always complement it with:
- ISCA (dependency scanning), if the tool does not support it, or you can use the free trial version of the tool.
- WAF (Web Application Firewall) adds a defence layer in front of your application by filtering and monitoring HTTP/HTTPS traffic.

WAF does not replace SAST or DAST. It can block known attack patterns, mitigate exploitation attempts before fixes are deployed, provide real-time protection in production, and prevent DDoS attacks.

DAST (Dynamic Application Security Testing). Scan the DEV or QA environment, because DAST is used when the application is up and running. Effective DAST can be performed in two phases:

Automated scanning — baseline detection of common runtime vulnerabilities.

Manual exploratory testing — for issues that automated tools often miss (logic flaws, authorization bypasses, etc.). Not all vulnerabilities can be discovered by SAST alone, which is why DAST is an important complement.

Ensure DevSecOps collaboration. Security engineers, platform teams, and developers must collaborate on:
- rule tuning
- prioritization
- education

Conclusion

Closing

This article covered the theoretical foundation of SAST and its strategic role within secure development. In ”Catch vulnerabilities before they ship: local SonarQube setup (Part 2)”, we will explore SonarQube Cloud configuration and IntelliJ IDEA integration, as well as running SonarQube locally with Docker.
If you're building secure systems at scale, SAST is where prevention truly begins.

Originally published on my personal blog: https://matevosian.tech/blog/post/SAST-part1-theory

DEV Community: Vardan Matevosian

Is OpenAI really running ChatGPT on a single PostgreSQL instance?

The second-highest salary: Why the simplest SQL query is often the smartest

The problem and sample data

Three common solutions compared

METHOD 1: MAX() + Subquery

METHOD 2: DISTINCT + ORDER BY + OFFSET

Method 3: DENSE_RANK() Window Function

H2H comparison

Key takeaways

Final recommendation

Application security: thinking backwards

Application Security with OAuth 2.0 and OpenID

Java Interface Evolution: Best Practices and Strategies

Introduction

Timeline navigation

Default methods

Real JDK example of default method

Static methods

Real JDK example of static method

Functional interfaces

Real JDK example of functional interface

Why These Matter

Best practices

Conclusion

Security isn’t just about code

Automating code security in CI/CD: SonarCloud SAST guide (Part 3)

Introduction

Integrating SonarQube scanning into the CI/CD pipeline using GitHub Actions

Workflow name

Workflow trigger

Job Section

branch-name-policy

build

sast

Results

Failing the pipeline based on SonarQube's default Quality Gates for a free account

Sourcecode structure

Controller

Exception

Mapper

Model

Persistence

Service

Database schema and data

Application properties

Adding unit tests and the JaCoCo plugin for code coverage

Conclusion

Links

Catch vulnerabilities before they ship: local SonarQube setup (Part 2)

Introduction

SonarQube Cloud for SAST

Setting Up SonarQube Cloud

Overview of SonarQube’s cloud capabilities for static code analysis

Local scanning with SonarQube Cloud via IntelliJ IDEA

Installing and configuring the SonarQube plugin in IntelliJ IDEA

Running local scans

Local scanning using Docker Compose with SonarQube image

Setting up SonarQube locally via Docker Compose

Run the Sonar scan from the command line or from IntelliJ IDEA

Comparing Local Docker Setup with Cloud Scanning

Conclusion

Closing

Links

The Secret Behind SAST: The Security Blind Spot Developers Can’t Ignore (Part 1)

Itroduction

What is SAST?

The importance of SAST in secure development cannot be overstated.

How to integrate SAST into CI/CD?

Why do some companies run SAST within CVS instead of SaaS tools?

How does SAST strengthen your application before deployment?

Conclusion

Closing

METHOD 1: `MAX()` + Subquery

METHOD 2: `DISTINCT` + `ORDER BY` + `OFFSET`

Method 3: `DENSE_RANK()` Window Function