SonarQube and Gitlab SAST

To successfully pass through the pipelines, product teams must adhere to specific criteria set by Platform One's Mission DevOps (MDO) and Cyber Teams.

• The pipelines utilized by Platform One employ SonarQube, Gitlab SAST and Fortify gate check scripts to ensure that only high-quality, secure code is deployed to our environments.
• Our ATO mandates that product teams address all findings rated above Minor/Low.
• Our ATO also mandates, per NIST DevSecOps control, that we provide mechanisms for approval or gate checks before pushing code to staging (i.e. pushes directly to the default branch are discouraged/disallowed)

SonarQube and Gitlab SAST will be updated as new versions of each tool become available. These updates may affect the findings in our pipelines, as the rulesets in both tools are regularly adjusted and improved. We have observed that updates occur more frequently with SonarQube.

NOTE

Teams can run SonarQube locally to catch findings before the pipeline, and prepare for new versions of SonarQube and rulesets coming out by tracking their updates on the SonarQube documentation.

SonarQube

Software Qualities: Security, Reliability, and Maintainability

SonarQube classifies every rule – and therefore every issue – under one of three high-level software qualities that align with Clean Code principles:

Security : Protection of your software from unauthorized access, use, or destruction. Security-related issues (for example Vulnerabilities or certain Bugs) can expose sensitive data or allow attackers to execute malicious code and should be fixed immediately.

Reliability : A measure of how well the software can continue to perform its intended functions under stated conditions for a stated period of time. Reliability issues (Bugs) can cause production crashes or unpredictable behaviour.

Maintainability : The ease with which code can be understood, repaired, and improved. Maintainability issues (Code Smells) slow down development and increase the likelihood of future defects.

Severity levels

Each issue is also assigned a severity that represents its potential impact:

• Blocker – Significant probability of severe unintended consequences; fix immediately.
• High – High impact on the application; fix as soon as possible.
• Medium – Moderate impact.
• Low – Low impact.
• Info – No expected impact; informational only.

All issues with a severity higher than Info/Low must be fixed or a formal exception must be requested.

Security Hotspots

Security hotspots identify sections of code that are sensitive to security issues and require manual review by the developer. After reviewing a security hotspot, you may determine that there is no threat, or you may need to apply a fix to secure the code. Unlike typical issues, security hotspots necessitate careful examination. All security hotspots must be either resolved or formally requested for an exception.

Gitlab SAST

Gitlab SAST is a newer Static Analysis tool that Party bus will be leveraging to improve our security and user experience when running automated security checks. Gitlab SAST is comprised of 2 types of scanners: Gitlab Advanced SAST and Semgrep SAST. For most purposes, Gitlab Advanced SAST will be the primary scanning tool, but Semgrep SAST will be used for C++ code. (For more information on what is covered with gitlab SAST, look to the gitlab SAST public template).

Merge Request Policies: Purpose and Enforcement

To ensure secure and high-quality deployments, Party Bus is adopting a strict merge request (MR) policy for all code changes to default branches (e.g., master/main) as of September 2025. This means:

• Direct pushes to default branches are no longer allowed. All changes must be made through a merge request targeting the default branch. This aligns with ATO and NIST DevSecOps requirements for pre-deployment gate checks and helps prevent new vulnerabilities from reaching production.

• GitLab SAST is enforced at the MR stage. When you open a merge request, the pipeline will automatically scan your changes for vulnerabilities.

How the Policy Works

• New Vulnerabilities: The MR policy will block merges if any new Medium, High, or Critical vulnerabilities are detected. Developers must remediate these issues or request a whitelist exception before merging.

• Existing Vulnerabilities (Adoption Phase): During the initial rollout, Party Bus will also block merges if the project has any existing vulnerabilities in the default branch. This is a temporary measure to encourage teams to address outstanding issues as we transition to the new workflow.

Summary Table:

Phase	What Blocks a Merge?
Adoption Period	Any vulnerability (new or existing)
Steady State	Only new Medium/High/Critical

Rationale and Workflow

INFO

BLUF:
Gitlab SAST is not a pass/fail job. We are using the MR strategy going forward to better align with best practices

• Why MRs? Requiring all changes to go through a merge request ensures that every code change is scanned and reviewed before it reaches the deployment branch. This process helps catch and address vulnerabilities early.

• Key Points:

  • Development branches are for new code.
  • All merges to deployment branches must go through an MR.
  • All new vulnerabilities are identified and gated at the MR stage.
  • During the adoption phase, existing vulnerabilities are also enforced

• Looking Ahead: After the adoption phase, enforcement will focus on new vulnerabilities only. Party Bus will also consider applying this enforcement model to other security tools in the future.

In summary: All code changes must go through a merge request, and pipelines will block merges on any vulnerabilities during the adoption phase. This ensures that new vulnerabilities are caught and addressed before deployment, and that existing issues are remediated as part of the transition. Please see Reviewing SAST results on how to distinguish new and existing findings as well as Additional Guidance for viewing and sorting findings for more information on how to navigate findings

Additional guidance on pipeline scope and how to create an MR policy

Because of the variation in customer workflows, especially given the existing policy that allows any maintainer to protect branches for pipeline runs, Party Bus is leveraging multiple paths to give developers the best experience when working through the Party Bus process. Additionally, Pipelines will need to reach completion for merges to happen. As such, we have created several paths for adoption.

1. Running MR pipelines on protected branches (EXISTING WORKFLOW). Customers can protect branches if they are maintainers or set up wildcard rules to protect branches so that their developers can automatically be able to run pipelines when going through the development lifecycle. When the developers in question are ready to merge to the deployment/default branch, they can create an MR. As such this MR may already have pipelines that have been run against it and will be able to evaluate the SAST rules for the merge criteria
2. Running MR pipelines on unprotected branches (NEW WORKFLOW). Customers can also create pipelines that run against unprotected branches by creating an MR with an unprotected branch. This is advantageous because it allows customers to only create pipelines when they are ready to merge against the default branch. Otherwise any development pushes that happen do not trigger pipelines. once the MR is created and the pipeline gets kicked off, then the rules are evaluated after completion. This will run a full pipeline
3. Running an ABBREVIATED pipeline on an unprotected branch (EVENTUAL NEW WORKFLOW). We do recognize that some customers are used to merging directly to the deployment branch or have some lengthy pipeline runs so we are providing a way to run ONLY gitlab SAST as a part of the new requirements. We are still working on a process that allows customers to have some control over this aspect. Will release guidance before final enforcement if not during soft enforcement/early adoption period

NOTE: if running unprotected branches and you have custom variables in your project CI/CD variables, you must leave those variables unprotected. They can still be masked for obscuring sensitive data

Fortify (soon to be deprecated)

Fortify Static Code Analyzer is a collection of software security tools that identify violations of security-focused coding rules and guidelines across various programming languages. It provides analysis information to help you create more secure software and enhances the efficiency, consistency, and completeness of security code reviews.

All critical, high, and medium findings must be addressed either by fixing them or by providing a comment with an explanation. In your comment, please clarify why the finding is a false positive or explain why it does not need to be fixed.

Example:

Requesting an Exception (Sonarqube and Fortify)

To request an exception for findings related to SonarQube or Fortify, please follow these steps:

1. In SonarQube or Fortify, add a comment to the issue that explains why the finding is a false positive or does not require fixing.
2. Submit a SonarQube/Fortify whitelist request to get the exception approved. If multiple findings need to be addressed, include all issues in the same request ticket. SonarQube/Fortify Whitelist Request

Requesting an Exception for GitLab SAST

1 | Kick off the Merge-Request (MR) pipeline

Start an MR using one of the workflows described above (protected branch, unprotected branch, or abbreviated pipeline).

2 | Review the SAST results

After the pipeline finishes, review any vulnerabilities reported by GitLab SAST.

NOTE

Do not dismiss findings yourself – the MR policy ignores the dismissed state and instead relies on necessary approvals on the MR. If you dismiss your own findings they will be hidden from view

Scenario A – New findings

1. Click Show Details (ˇ) to expand the list.
2. Inspect each finding to decide whether it is a true issue or a false positive.
3. For findings you want whitelisted, scroll to the bottom of the vulnerability window and click Create Issue.
4. In the newly-created issue, add an explanatory comment and copy the issue URL.
5. Repeat for every finding you wish to whitelist; you will include each URL in your Cyber ticket.

Scenario B – Existing findings (initial adoption)

1. Navigate to Secure → Vulnerability Report in your project sidebar. (There is guidance below on how to navigate these findings with more granularity if needed)
2. Select one or more findings using the check-boxes.
3. In Select Action, choose Attach to new issue (or Attach to existing issue).
4. Click Create Issue (blue button on the far right).
5. In the issue, add justification/comments and note the issue URL(s) for your Cyber ticket.

Heads-up: Both scenarios can occur together when an MR introduces new findings while existing ones are still present.

3 | Submit a Cyber whitelist request

1. Open the Cyber Help Desk form: https://jira.il2.dso.mil/servicedesk/customer/portal/81/create/1487
2. Provide the MR link and every issue URL created in the steps above.
3. Use the drop-down to indicate whether each request is for New or Existing findings. (See above for explanation if needed)
4. Supply any additional context that will help the Cyber team act quickly, then click Submit.

4 | After submission

• The Cyber team will either approve the whitelist request or ask for additional information/remediation.

Additional Guidance for viewing and sorting findings

If the MR view for findings proves to be difficult to navigate or utilize, you can always go to the full pipeline or project view.

• Project vulnerability reports: Available in your Vulnerability Reports. This URL is essentially https://code.ilx.dso.mil/your/project/path/-/security/vulnerability_report
  • Filtering by vulnerability is possible by using the filter bar, clicking into it and then selecting the resulting options. For all possible options, please use the doc linked just above this line
  • Additionally, you have the ability to sort these findings based on various states. As stated above, Dismissed Findings will not show in the default view, but you can use the dropdowns to un-filter them. Or you can use the url above with some extra filtering. Ex. https://code.ilx.dso.mil/your/project/path/-/security/vulnerability_report/?state=CONFIRMED,DETECTED,DISMISSED
  • Any findings that have been resolved due to postive actions by the developer or even some environmental factors by our team to fine tune results can also be sorted and viewed for historical purposes. URL is https://code.ilx.dso.mil/your/project/path/-/security/vulnerability_report/?state=RESOLVED
• Viewing Results for your pipelines: These Instructions will assist in navigating the user towards the pipeline findings
  • Pipeline results links should look something like the following: https://code.il2.dso.mil/platform-one/devops/hello-pipeline/sast-world/-/pipelines/888375/security
  • These findings will represent ALL SAST vulnerabilities found in a pipeline, but anything that has been dismisssed as a result of previous whitelisting will not show by default. This includes findings whitelisted as a part of the Existing findings workflow AND the New Findings workflows outlined above.
  • Similar to the main project vulnerabilities dashboard you can filter by various statuses, however instead of an open filter bar, you will be presented with a set of dropdowns.
• Lastly, if removing all filters from the vulnerability report, you may also see Resolved Findings. These are findings that your team either fixed, or got automatically resolved due to configuration changes on the Party Bus side. These are not evaluated during the MR policy process and are merely meant to show as a historical record of things that were fixed or went away

Relevant Links

• https://fortify.il2.dso.mil
• https://fortify.il4.dso.mil
• https://fortify.il5.dso.mil
• https://sonarqube.il2.dso.mil
• https://sonarqube.il4.dso.mil
• https://sonarqube.il5.dso.mil