GitLab Static Application Security Testing Infrastructure and Implementation

Static Application Security Testing, commonly referred to by the acronym SAST, represents a critical pillar of the DevSecOps lifecycle by allowing for the identification of security vulnerabilities within a project's source code before the code is ever executed. In the context of GitLab, SAST is implemented through a series of specialized analyzers that scan the codebase for known vulnerabilities, such as Cross-Site Scripting (XSS) or Improper restriction of XML external entity references (XXE). By integrating these checks directly into the CI/CD pipeline, organizations can shift security left, identifying flaws during the development phase rather than discovering them in production where the cost and risk of remediation are significantly higher.

The fundamental architecture of GitLab SAST relies on a set of analyzer images that run as jobs within the pipeline. These analyzers produce standardized JSON report files, specifically named gl-sast-report.json, which contain the detailed findings of the scan. These reports act as the primary data exchange format between the analyzer and the GitLab vulnerability management system. For instance, a vulnerability identified by the nodejs-scan analyzer might highlight an unescaped variable in a Vue.js template, which could lead to XSS if untrusted user input is passed to that variable. The resulting JSON output includes a unique identifier for the vulnerability, the category, the name of the rule triggered, and a detailed message explaining the risk.

SAST Analyzer Framework and Tooling

GitLab SAST is not a monolithic scanner but rather a collection of diverse tools tailored to different programming languages and frameworks. Currently, the system is primarily comprised of two distinct types of scanners: GitLab Advanced SAST and Semgrep SAST. While GitLab Advanced SAST serves as the primary tool for most general purposes, Semgrep SAST is specifically utilized for C++ code analysis.

The diversity of the analyzer ecosystem ensures that a wide array of technologies can be scrutinized. The specific tools included in the SAST CI/CD template include:

• Semgrep: This analyzer uses GitLab-managed rules by default and is widely used across many languages.
• SpotBugs: This tool incorporates the find-sec-bugs plugin and provides support for Java-based ecosystems, including Gradle, Maven, and SBT. It is also compatible with the Maven wrapper, Gradle wrapper, and Grails. However, it is important to note that SpotBugs has limitations when analyzing Ant-based projects; in such cases, users are directed to utilize the GitLab Advanced SAST or Semgrep-based analyzers.
• Kubesec: This analyzer is designed to scan Kubernetes manifests and Helm charts for security misconfigurations. By default, this job is disabled in the standard template, requiring manual activation or the use of broader Infrastructure as Code (IaC) scanning.
• Other Specialized Analyzers: The ecosystem includes images such as pmd-apex for Salesforce Apex code and sobelow for Clojure.

The technical specifications for the default analyzer images available in the GitLab registry are detailed in the following table:

Pipeline Configuration and Integration

Integrating SAST into a GitLab project requires the modification of the .gitlab-ci.yml configuration file. The most efficient way to implement this is by including the official SAST template, which automates the creation of the necessary jobs.

To initiate a basic SAST configuration, the following code block is used:

yaml include: - template: Security/SAST.gitlab-ci.yml variables: SAST_DEFAULT_ANALYZERS: "eslint,nodejs-scan,phpcs-security-audit"

In the example above, the SAST_DEFAULT_ANALYZERS variable specifies that three distinct analyzers—eslint, nodejs-scan, and phpcs-security-audit—should be executed. These jobs run during the test stage of the pipeline. Each analyzer operates independently and produces its own gl-sast-report.json file. These artifacts are then available for download via the pipelines interface.

The pipeline architecture often employs a "checker" pattern. When the needs keyword is used in the CI configuration, a vulnerability job (such as sast-vuln:nodejs-scan-sast) can start immediately after the analyzer job (such as nodejs-scan-sast) completes. This allows the checker job to retrieve the generated artifacts and process the findings. This dependency chain ensures that the vulnerability report is updated in real-time as soon as the analyzer finishes its execution.

Advanced Vulnerability Tracking and Tiering

Advanced vulnerability tracking is a feature reserved for the Ultimate tier, available across GitLab.com, GitLab Self-Managed, and GitLab Dedicated offerings. This capability is essential because source code is volatile; as developers modify files, code fragments move, and vulnerabilities may shift their location within a file or migrate between different files entirely.

GitLab's advanced tracking links vulnerabilities to specific code fragments. This ensures that if a piece of code is moved, the system can still track the vulnerability and maintain its history, preventing the "loss" of a known issue during a refactor.

A significant challenge occurs during the transition from legacy analyzers to Semgrep-based analyzers. When the system translates findings, it attempts to combine vulnerabilities from different analyzers into a single record. However, a mismatch may occur if:

• The new Semgrep-based rule identifies the vulnerability in a different location or through a different logic than the previous analyzer.
• The user had previously disabled certain SAST analyzers, preventing the system from recording the necessary identifiers for automatic translation.

In these instances of mismatch, the original vulnerability is marked as "no longer detected" in the vulnerability report, and a new vulnerability is created based on the Semgrep finding. This can lead to a temporary increase in the number of open vulnerabilities during the migration phase.

Customization and Environment Management

For organizations with strict security requirements, such as those operating in offline or air-gapped environments, GitLab provides mechanisms to customize how analyzers are retrieved and executed.

The pull_policy for GitLab Runners is a critical setting. In an offline environment, this should be set to if-not-present to ensure the runner uses locally available Docker images. Conversely, in connected environments, the policy must remain as always to ensure the pipeline utilizes the most up-to-date scanner images, which include the latest security rules and vulnerability signatures.

To move analyzers to a local registry, administrators must import the default images from registry.gitlab.com into their own Docker container registry. This process is subject to the internal network security policies of the organization and typically requires coordination with IT staff.

Furthermore, users with Maintainer or Owner roles can customize the registry source using the SECURE_ANALYZERS_PREFIX CI/CD variable. This variable affects all Secure analyzers, not just SAST. For example, to redirect the pipeline to a custom registry, a user would define:

yaml variables: SECURE_ANALYZERS_PREFIX: "my-docker-registry/gitlab-images"

By defining this, the system will pull my-docker-registry/gitlab-images/semgrep instead of the default GitLab registry path.

The Merge Request Policy and DevSecOps Governance

In high-security environments, such as the Party Bus implementation (effective September 2025), GitLab SAST is used as a mandatory gate for code changes. This aligns with Authority to Operate (ATO) and NIST DevSecOps requirements.

The enforcement policy dictates that direct pushes to default branches, such as master or main, are strictly prohibited. All changes must be submitted via a Merge Request (MR). The SAST pipeline is triggered automatically upon the opening of an MR.

The policy regarding the blocking of merges is as follows:

• New Vulnerabilities: Any new Medium, High, or Critical vulnerabilities detected during the MR scan will block the merge. Developers must either remediate the code or obtain a whitelist exception.
• Existing Vulnerabilities: During the initial adoption phase, the policy also blocks merges if the project contains existing vulnerabilities in the default branch. This is a temporary measure designed to force the cleanup of technical debt and legacy security flaws.

It is important to note that while these policies can block a merge, GitLab SAST itself is not designed as a simple "pass/fail" job in the traditional sense; rather, it provides the data necessary for the MR policy to make an informed decision about the safety of the code.

Handling False Positives and Rule Management

A common challenge in static analysis is the occurrence of false positives. To manage this, GitLab analyzers support "ignore" tags that allow developers to suppress warnings for specific lines of code. However, these tags are not standardized across all analyzers. For example:

• ESLint uses: // eslint-disable-line
• PHPCS uses: // phpcs:ignore

The lack of a unified tagging system requires developers to memorize multiple different formats depending on the language and tool being used. To combat this, some teams implement a custom unified tag system to document why specific lines are being ignored, providing a centralized reason for the exception.

Regarding the rules themselves, the GitLab Advanced SAST rules are stored in a private repository. This means that users cannot directly browse the rule definitions (such as the java_xxe_rule-XMLInputFactoryExternalEntitiesEnabled rule which detects XXE) in a public git repository. If a developer identifies a bug in a rule, the established procedure is to:

1. Open a bug report in the GitLab issue tracker.
2. Assign the issue to the specific group using the label /label ~"group::vulnerability research".
3. For Ultimate tier customers, open a customer support ticket to coordinate with the product and engineering teams.

Conclusion

The implementation of GitLab SAST transforms the security process from a final, often delayed, audit into a continuous, automated verification system. By leveraging a hybrid approach involving both Semgrep and Advanced SAST, GitLab provides comprehensive coverage across a vast array of languages, from Java and C++ to Clojure and Apex. The system's strength lies in its integration with the GitLab CI/CD pipeline, where the use of standardized JSON reports and the SECURE_ANALYZERS_PREFIX allows for flexible deployment in both cloud and air-gapped environments.

The transition toward strict MR policies, as seen in the Party Bus framework, demonstrates the evolution of SAST from a purely advisory tool to a governance mechanism. By blocking the introduction of Medium, High, and Critical vulnerabilities, organizations can mathematically reduce the attack surface of their production environments. However, the effectiveness of this system depends on the organization's ability to manage the "volatility" of source code through advanced vulnerability tracking and the diligent management of false positives. The shift toward private rule repositories ensures that the security logic is maintained by experts, while the provided feedback loops through the vulnerability research group allow the system to evolve alongside emerging threats.

Sources

1. Secure your project with the GitLab SAST analyzers
2. Sonarqube GitLab SAST - Party Bus
3. GitLab SAST Documentation
4. GitLab SAST Analyzers Documentation
5. GitLab Forum - Advanced SAST Rules Repository