Coder Legion - Recent posts tagged sast

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

Sun, 18 Jan 2026 14:36:05 +0000

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)

Fri, 16 Jan 2026 16:13:02 +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

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.

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.

Coder Legion - Recent posts tagged sast

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