MDO Announcements - 2025

02 December 2025: MRs Report on Significant Changes to Manifest

Attention Party Bus Customers! As a part of our continued effort to streamline security approvals, you may see an additional finding type in manifest project merge requests. This finding type may appear when a change to images is made in the manifest that would be deemed a significant change to what is currently deployed. For now, these findings will just be flagged and reported. In the future, if an MR is flagged, it will require P1 approval to merge that MR. More information will be provided at that time. In addition, moving forward, all changes to the manifest will require a merge request and be subject to security review.

If you have any feedback or questions, feel free to let us know in the Party Bus Support Channel . Thank you!

12 November 2025: Approval Required for Significant Changes to Base Image

Attention Party Bus Customers! Moving forward, you will see additional findings and approvals in the Merge Request (MR) pipelines for your various projects. These changes align with our efforts to streamline security approvals. The first thing that we are rolling out today will be for image build pipelines. Moving forward, you will see a new job called base-image-policy-scan in MR pipelines when changes are made to the Dockerfile. This job will validate whether the base image has been significantly changed from what is used in the default branch. If a significant change has been made, it will require approval from the P1 Cyber Application Team. Customers will be required to submit a ticket for approval per the instructions in the MR. Please note that simple version tag bumps will not require approval.

If you have any feedback or questions, feel free to let us know in the Party Bus Support Channel . Thank you!

22 October 2025: SonarQube Enterprise v2025.5

Party Bus will be upgrading SonarQube to the latest Enterprise edition. Release notes can be viewed here, but the most visible change will be the addition of new rules.

There are no changes to our Quality Gates (other than new rules). Only findings above Low severity are mandated. This will be enforced for deployed code and thus only applicable to the main/default branch. Findings on non-main branches will be flagged, but will not block the pipeline.

Whitelist requests can be submitted with a SonarQube/Dependency Check/Pentest Whitelist Request . Whitelists should be requested against the default/main branch. Any whitelists there will be copied onto new branches. If a whitelist was approved/added after a branch has run its results, it will not have the whitelist. It will not block the pipeline for the branch, but may be confusing because it shows a finding that has already been addressed in the main branch.

24 September 2025: SonarQube Enterprise Upgrade

Reminder that Party Bus will be upgrading SonarQube to the Enterprise edition to replace the current Community Build. The key benefit of this change is branch analysis which will allow code quality and security at the branch level, a requested feature from customers.

There are no changes to our Quality Gate. Only findings above Low severity are mandated. Our ATO mandates that we provide mechanisms for approval or gate checks before pushing code to staging. This will be enforced on the main/default branch. Findings on non-main branches will be flagged, but will not block the pipeline. This includes findings that were whitelisted on the main branch. Pull/Merge Request analysis will also be enabled.

This update will affect the sonarqube and dependency-check jobs.

Whitelist requests can be submitted with a SonarQube/Dependency Check/Pentest Whitelist Request .

26 August 2025: Clamav Scanning for Image Build Pipelines

Attention Party Bus Customers! To continue to improve the efficiency and security of image build pipelines, you will see a new job called clamav-scan that will perform an AV scan and block the pipeline if malware findings are found within your container image. In the past, we have used the functionality built into Anchore to perform AV scans; however, this will now be handled by the clamav-scan job in your image build pipelines.

If you have any feedback or questions, feel free to let us know in the Party Bus support channel . Thank you!

9 July 2025: Gitlab SAST and Merge Request Workflows updates

As announced previously, Party Bus is moving towards Gitlab SAST (Advanced SAST and semgrep) for their preferred SAST scanner over Fortify. As such, we have higlighted some important workflow changes including the following:

• Merge request pipelines become a standard across all teams
• Scans are enforced using Merge request policies to catch new findings
• No more direct pushes to master branch

Announcement here for more info

SAST Scan Vulnerability Reports

We've enabled Gitlab SAST scans across all pipelines. You'll start seeing these security scan results in two places:

• Main vulnerability reports: Available in your Vulnerability Reports
• Pipeline-specific reports: Can be accessed for each pipeline run by following these instructions

Merge Request Workflow Changes

What's Changed

You may have noticed some behavioral changes around merge request creation and pipeline execution. These updates are part of our first phase to improve the merge request workflow.

Key Benefits

• No more branch protection required: Teams no longer need to protect their branches to run pipelines
• Simplified process: Simply open a Merge Request to trigger a pipeline

Important Notes

• The number of stages that run during merge request pipelines may change as we continue our discovery process
• Pipeline configurations are subject to updates based on ongoing improvements

How to Re-run Merge Request Pipelines

1. Navigate to the Merge Request in the UI
2. Select the Pipelines tab
3. Click Run Pipeline

Known Issues

Current Limitations: These changes have caused some adverse effects with:

• Protected variables functionality (Not to be confused for Masked variables). If running an MR pipeline with an unprotected branch, the pipeline will no longer be able to access protected variables. This is intentional and project level variables can be un-protected as needed by your team. We have already removed the instance-level protected variables as necessary
• Manual pipeline runs for open MRs (see above for how to remediate this)

We're actively investigating these issues and working on fixes as they arise.

Next Steps

• In the coming days/weeks you may see a Security Bot message in your Merge Requests to show the new policies in effect for enforcing SAST. These policies are non-enforcing and are simply meant to be informational. No action is required, but it may be helpful to start understanding and/or remediating findings
• Example Messages from Gitlab Security Bot are as follows:
• Whitelisting workflows are still in the works. As this is a completely new process, we are taking the steps to help teams transition as smoothly as possible

13 June 2025: Fixed inconsistent exclusion of base image vulns in Twistlock

Attention Party Bus Customers. We have fixed issues with how Twistlock vulnerability findings are attributed to the base image and reported in anchore-twistlock-results job.

What this does - reduces need for help desk tickets

• Default gatecheck should no longer incorrectly flag findings from the base image
• Base image findings will be correctly reported for RBD analysis

Additional Details

Problem

Previously, the pipelines depended on VAT data or Twistlock to correctly identify the base image and the associated findings, but often the base image scan results were not up to date enough to use for this. Additionally, Twistlock settings were causing some findings to not be reported.

Solution

• Base image scan occurs in its own job earlier in pipeline
• Twistlock reporting no longer excludes base image findings
• Instead, anchore-twistlock-results job uses base image scan results for whitelisting base image findings for default gatecheck

19 May 2025: Risk-based Deployments (RBD) has launched!

Attention Party Bus Customers. We have implemented a major change to the anchore-twistlock-results job PASS/FAIL logic.

• We have added flexibility to the passing pipeline criteria for evaluating vulnerability findings
• This does not directly affect CtF requirements nor does it change customer workflows

What does RBD do?

• Reduces the need for CVE exception tickets and gets your changes deployed to Staging and Prod faster!
• Findings affecting software already deployed to Production will no longer block future release deployments
• Provides enhanced data reporting to facilitate risk reviews and remediation efforts

Additional Details

Your results job will now PASS if the software is considered less risky than your previous Production release OR if it passes the previous default gate checks.

Examples of Passing Job Criteria:

• (NEW) No findings are added (only carried over from Production release)
• (NEW) Risk score has improved
• No findings for Twistlock or Anchore default gatechecks

Questions?

If you have any feedback or questions, feel free to let us know in the Party Bus support channel . Thank you!

19 Mar 2025: Adjusting Twistlock Severity Filter

Attention Party Bus Customers. As part of our effort to streamline the vulnerability remediation process for customer images, we are now filtering out some additional severities from triggering a Twistlock gatecheck failure in the anchore-twistlock-results.

These are some additional low severity types that have minimal impact on the deployed app's security and will help speed up deployment by filtering these out.

If you have any feedback or questions, feel free to let us know in the Party Bus support channel . Thank you!

13 Feb 2025: Moving Anchore and Twistlock Gatechecks to their own Job

Attention Party Bus Customers. As part of our effort to streamline the vulnerability remediation process for customer images, we have moved the vulnerability gatechecks from the anchore-scan and twistlock-scan jobs to a new job called anchore-twistlock-results.

Moving forward, you should expect the following:

• The anchore-scan and twistlock-scan jobs should only fail as a result of an abnormal pipeline failure (as opposed to a failure resulting in identified vulnerabilities)
• Any pipeline failure due to identified CVEs will take place in the anchore-twistlock-results job
• The details on the vulnerabilities identified and any gatecheck failures due to present vulnerabilities will now be present in the anchore-twistlock-results job
• There are now collapsable sections (that are collapsed by default) in the anchore-twistlock-results job that will provide details on the identified vulnerabilities
• At the end of the anchore-twistlock-results job, it will inform you of any gatecheck failures do to vulnerabilities identified by anchore and/or twistlock.
• If your pipeline has anchore or twistlock disabled (rare) please put in a ticket with MDO to modify your pipeline accordingly

If you have any feedback or questions, feel free to let us know in the Party Bus support channel . Thank you!

23 Jan 2025: Switching from Buildah to Podman for Image Builds

Attention Party Bus Customers. To keep our pipelines secure and up to date, we have made the following change to our customer image build pipelines:

We have changed from using Buildah to Podman as our tool for building images. For the most part these tools have like for like functionality and capabilities but you may notice some difference in the base image detection logic. If you feel these changes have affected your image builds or image scans please open a ticket.

If you have any feedback or questions, feel free to let us know in the Party Bus support channel . Thank you!