GitLab Static Application Security Testing

Static Application Security Testing, commonly referred to as SAST, is a fundamental security pillar within the GitLab DevSecOps platform designed to analyze source code for vulnerabilities before the code is ever executed. By integrating security scanning directly into the Continuous Integration and Continuous Deployment (CI/CD) pipeline, organizations can shift security to the left, ensuring that flaws are identified and remediated during the development phase rather than in production. This proactive approach reduces the cost of remediation and prevents the introduction of exploitable vulnerabilities into the codebase.

The GitLab SAST ecosystem is designed to be seamless, automatically detecting supported source code and triggering the appropriate analyzers. These analyzers run as jobs within the test stage of a project's pipeline, providing a structured method for identifying security risks. This integration ensures that security is not a separate, manual step but a continuous process that evolves with the codebase.

GitLab Advanced SAST and the Oxeye Engine

GitLab has introduced Advanced SAST, a high-tier security offering available exclusively to GitLab Ultimate customers. This solution is powered by proprietary technology acquired from Oxeye, which fundamentally changes the way static analysis is performed. Unlike standard analyzers that may rely on simpler pattern matching, Advanced SAST utilizes a proprietary detection engine.

The core strength of Advanced SAST lies in its ability to conduct taint analysis. Taint analysis allows the scanner to track the flow of untrusted data from an input source to a sensitive sink, providing a deeper understanding of whether a vulnerability is actually exploitable in a real-world scenario. This approach is critical for reducing the noise associated with false positives, which often plague traditional SAST tools. By providing relevant context and high-accuracy results, Advanced SAST enables developers to focus on actual vulnerabilities, thereby increasing development velocity and reducing the friction between security teams and developers.

This advanced scanner does not replace the existing platform capabilities but operates alongside them. This creates a layered defense strategy where both standard open-source based analyzers and the proprietary Advanced SAST engine work in tandem to provide the most comprehensive security coverage possible.

Language and Framework Support Matrix

GitLab SAST supports a wide array of languages and frameworks, categorized by the level of support provided by the various analyzer engines. The availability of these options depends heavily on the GitLab tier being utilized.

Full Support Languages

Certain languages benefit from dual-engine support, meaning they can be scanned by both the standard analyzers available to all tiers and the Advanced SAST engine available to Ultimate users.

The standard analyzers for these languages primarily leverage the Semgrep analyzer with GitLab-managed rules. In the case of Java, the support extends to Java Server Pages (JSP) and Android applications. JavaScript support encompasses Node.js and React frameworks, while Ruby support includes Ruby on Rails. YAML support is specifically restricted to file patterns such as application*.yml, application*.yaml, bootstrap*.yml, and bootstrap*.yaml.

Standard Analyzer Only Support

Some languages are supported exclusively through standard analyzers based on open-source tools. These are available to all tiers but do not currently benefit from the Advanced SAST engine.

For Groovy, SpotBugs is utilized with the find-sec-bugs plugin. This supports Gradle, Maven, and SBT, as well as their respective wrappers (Gradle wrapper, Maven wrapper) and Grails. However, SpotBugs faces limitations when analyzing Ant-based projects. In such cases, users are advised to utilize the Semgrep-based analyzer or Advanced SAST for Java or Scala projects based on Ant.

Enabling SAST in the CI/CD Pipeline

Integrating SAST into a project requires specific permissions and environment configurations to function correctly. To begin, a user must possess the Developer, Maintainer, or Owner role within the project.

Infrastructure Requirements

The execution of SAST analyzers depends on the GitLab Runner configuration. The following requirements must be met:

• A Linux-based GitLab Runner is mandatory.
• The runner must utilize either the Docker or Kubernetes executor.
• For GitLab.com hosted runners, Docker and Kubernetes executors are enabled by default.
• Windows-based Runners are explicitly not supported.
• CPU architectures other than AMD64 are not supported.
• The .gitlab-ci.yml configuration must include a test stage. If the stages are redefined, the test stage must be explicitly included.

Implementation Steps

To enable SAST, users should follow these procedural steps:

1. Navigate to the project and select Search or go to the project home.
2. Access the Pipeline editor via Build > Pipeline editor.
3. Integrate the SAST functionality using either a template or a component.

To utilize the SAST CI/CD template, the following code must be added to the configuration:

yaml include: - template: Jobs/SAST.gitlab-ci.yml

Alternatively, to use the CI/CD component, the following code is required:

yaml include: - component: gitlab.com/components/sast/sast@main

Once the code is added, users must select the Validate tab and click Validate pipeline. A successful simulation confirms the file is valid. Finally, the user completes the process by providing a commit message and selecting the target branch in the Edit tab.

Advanced Configuration and Customization

GitLab provides several mechanisms to refine the behavior of SAST analyzers to better fit the specific needs of a project, such as reducing noise or complying with strict regulatory standards.

Customizing Rulesets

Users can disable specific rules to prevent the reporting of vulnerabilities that are not applicable to their environment. For instance, to disable the gosec.G107-1 rule, the following configuration must be added to the .gitlab/sast-ruleset.toml file:

toml [semgrep] [[semgrep.ruleset]] disable = true [semgrep.ruleset.identifier] type = "semgrep_id" value = "gosec.G107-1"

Path Exclusion

To prevent the analyzer from scanning irrelevant files, such as test suites or temporary code, the SAST_EXCLUDED_PATHS variable is used. For example, to exclude a specific file named rule-template-injection.go, the following variable should be defined in the .gitlab-ci.yml file:

yaml variables: SAST_EXCLUDED_PATHS: "rule-template-injection.go"

FIPS Compliance

For organizations requiring Federal Information Processing Standards (FIPS) 140-validated cryptographic modules, GitLab offers FIPS-enabled images. These images are based on the Red Hat UBI base image rather than the standard Alpine base.

FIPS-compliant images are only available for the Semgrep-based analyzer and GitLab Advanced SAST. To implement FIPS compliance, users can set the SAST_IMAGE_SUFFIX variable to -fips or append the -fips extension to the default image name.

Example configuration for FIPS:

yaml variables: SAST_IMAGE_SUFFIX: '-fips' include: - template: Jobs/SAST.gitlab-ci.yml

When running FIPS-enabled images in a Kubernetes runner with a non-root user, the run_as_user attribute under runners.kubernetes.pod_security_context must be updated to 1000, which is the ID of the gitlab user created by the image. To maintain FIPS compliance, all other non-FIPS analyzers must be excluded from the run.

Operating in Offline and Restricted Environments

In environments with strict network security policies, GitLab SAST can be configured to operate offline. This prevents the runner from attempting to pull images from the public internet.

Pull Policy Configuration

In an offline environment, the GitLab Runner pull_policy can be set to if-not-present. This ensures the runner only uses Docker images available locally. However, in any environment that is not offline, the policy should be kept as always to ensure that the most updated scanners are utilized in the CI/CD pipelines.

Local Docker Registry Integration

To ensure all supported languages and frameworks can be scanned in an offline setting, the following default SAST analyzer images must be imported from registry.gitlab.com into a local Docker container registry:

• registry.gitlab.com/security-products/gitlab-advanced-sast:2
• registry.gitlab.com/security-products/kubesec:6
• registry.gitlab.com/security-products/pmd-apex:6
• registry.gitlab.com/security-products/semgrep:6
• registry.gitlab.com/security-products/sobelow:6
• registry.gitlab.com/security-products/spotbugs:5

The specific process for importing these images depends on the organizational network security policy and should be coordinated with IT staff.

Vulnerability Tracking and Management

The utility of SAST is not found solely in the detection of bugs, but in the management of the resulting vulnerabilities.

Advanced Vulnerability Tracking

Available in the Ultimate tier across GitLab.com, GitLab Self-Managed, and GitLab Dedicated, advanced tracking addresses the volatility of source code. As developers modify files, code fragments may shift positions or move between files. GitLab's system links vulnerabilities to specific problematic code fragments. This ensures that even as the code evolves, the vulnerability remains tracked and can be located for remediation.

Resolution and History

The Vulnerability Management system maintains a historical record of security issues. When a vulnerability is automatically resolved, the system leaves a comment on the record. If a previously disabled rule is re-enabled, any corresponding findings are reopened for triage, ensuring no regression in security posture occurs.

Reporting

Every SAST analyzer generates a JSON report as a job artifact. This report contains the granular details of all detected vulnerabilities. Access to download these reports is restricted to users with the Developer, Maintainer, or Owner role.

Kubernetes and Infrastructure Scanning

Beyond source code, the SAST CI/CD template includes capabilities for scanning infrastructure configurations. Specifically, there is an analyzer job capable of scanning Kubernetes manifests and Helm charts.

This job is disabled by default. Users can enable it by activating the Kubesec analyzer. Alternatively, users may consider using IaC (Infrastructure as Code) scanning, which provides support for additional platforms beyond Kubernetes and Helm.

Scaling SAST Implementation

Once SAST has been successfully validated in a single project, organizations can roll out the implementation across their entire portfolio.

• Enforced scan execution can be used to apply consistent SAST settings across entire groups.
• Centralized rulesets can be shared and reused by specifying a remote configuration file, ensuring that security standards are uniform across different projects.
• For highly specific environments, SAST can be further tailored to operate under SELinux constraints or in completely isolated offline environments.

Analysis of SAST Integration and Impact

The integration of SAST into the GitLab CI/CD pipeline represents a fundamental shift from reactive security to proactive risk management. By utilizing a combination of open-source engines like Semgrep and proprietary technology from Oxeye, GitLab provides a tiered approach to security. The standard analyzers provide a baseline of security for all users, while the Advanced SAST engine offers a high-fidelity experience for Ultimate users.

The impact of this system is most evident in the reduction of false positives. The transition from simple pattern matching to taint analysis allows developers to distinguish between a theoretical vulnerability and an exploitable one. This reduces "security fatigue," where developers begin to ignore security alerts due to high noise levels.

Furthermore, the flexibility offered through FIPS-compliant images and offline registry support ensures that GitLab SAST can be deployed in the most restrictive government and enterprise environments without compromising the integrity of the security scan. The ability to track vulnerabilities across code changes ensures that the remediation process is not interrupted by the natural volatility of software development. Ultimately, the exhaustive nature of these tools—covering everything from Android and Java to Kubernetes manifests—creates a comprehensive security shield that encompasses both the application code and the infrastructure it runs on.

Sources

1. GitLab SAST Documentation
2. GitLab Blog - Advanced SAST Availability