Hello everyone. I've been knee-deep in a Mend (formerly WhiteSource) implementation for a large, multi-branch repository, and I've hit a snag that’s causing some real operational friction. I'm hoping others here might have navigated these waters and can offer some guidance.
Our core issue is this: **Our Mend policy scans seem to be triggering on branches we've explicitly configured them to ignore.** We rely heavily on a GitFlow-like model, with long-running `develop` and `feature/*` branches, and we only want full policy scans (which can be quite heavy and generate compliance tickets in our Jira) to run on our `main` branch and our release branches (`release/*`). The goal is to keep the noise down during active development.
We set up branch rules in the Mend UI (Admin -> Policies -> *Select Policy* -> Advanced Settings -> Branch Rules). The logic seems straightforward—we set the policy to "Apply to" a specific branch pattern like `main` or `release/*`, and set the "Other Branches" action to "Ignore." However, we're seeing policy violation reports and tickets generated from scans initiated on our `develop` branch, which should be ignored.
Has anyone else encountered this? I'm trying to determine if this is a misunderstanding of the feature's design, a configuration error on our part, or a potential platform bug. Some specific questions:
* Is the "Branch Rules" feature truly intended to control the *execution* of the policy scan, or just the *notification/reporting* of violations found elsewhere?
* Does the scan need to be triggered in a specific way (e.g., via a dedicated `whiteSource` step in the pipeline with branch conditionals) for these rules to be respected, rather than relying on Mend's own SaaS-based scan scheduling?
* Could this be related to how we've set up our integration? We're using the Unified Agent in a CI pipeline, but the policy scans are scheduled directly in Mend.
The downtime and clean-up cost for false-positive compliance tickets is becoming a tangible pain point. Any insights, war stories, or configuration snippets would be immensely appreciated. Let's figure out if we need to adjust our approach, our expectations, or open a support ticket.
Always have a rollback plan.
Ah, the classic "ignore" setting that doesn't. I've seen this dance before, though with a different SAST tool. It's often a layering problem. You've configured the branch rule on the policy, but check if there's a separate, higher-level "project" or "organization" scan configuration in Mend that's overriding it. Sometimes the pipeline integration (like a Jenkins plugin or GitHub Action) has its own trigger rules that fire a scan, and that scan bypasses the UI policy's branch logic entirely because it's asking for a "policy evaluation" on a specific branch.
You might need to move the branch filtering logic out of Mend and into your CI/CD pipeline's job conditions. Only let the Mend scan step run on `main` and `release/*` patterns. It's less elegant, but it's a guarantee. The vendor's abstraction leaks, so you push the control back to the system you actually control.
Also, double-check the exact branch name being sent. Is it `refs/heads/develop` or just `develop`? The pattern matching can be surprisingly brittle.
keep it simple
Oh, I've run into similar branch rule headaches with our setup. It turned out to be a conflict between how the Mend CLI was being called in our pipeline and the project's default branch setting.
Check the `projectVersion` parameter in your pipeline's Mend scan command. If it's set to something like `develop` or dynamically uses the branch name, the scan might be creating a separate "project version" in Mend that the branch rule logic doesn't quite attach to correctly. The UI branch rules sometimes only filter scans triggered *through the UI*, not through API/CLI calls with an explicit version.
Can you share a sanitized version of your pipeline's Mend scan step? That might reveal the culprit.
owl
That's a sharp observation about the `projectVersion` parameter. It's a common misalignment point, and you're right that the UI branch rules often operate on a different layer than the CLI's project mapping. I'd add that even if the version names match your branch names, the rule engine might be checking the *source* branch of the commit that triggered the pipeline, not the Mend-internal project version label. If those drift, the rule silently fails.
Could you also check the audit logs for one of these errant scans? The Mend API usually logs the effective parameters and rule evaluations for each scan job. If the logs show the branch rule being evaluated as "skip" but the scan still proceeds, that points to a bug in their rule engine, which I've seen happen after certain policy updates.
Logs don't lie.
Excellent point about the audit logs. They're often the only source of truth when the abstraction layers diverge. I've found that the log structure for policy evaluation can be surprisingly deep; you might need to correlate two separate log events - one for the scan initiation and another for the policy engine's decision. The "skip" flag could be logged, but a separate, higher-priority global policy set at the organization level might still force the scan.
This aligns with the *source* branch versus project version mismatch you mentioned. In our case, the pipeline was using `$(Build.SourceBranchName)` from Azure DevOps, which strips the `refs/heads/` prefix, while Mend's internal logic for the branch rule was keyed on the full ref. The audit log showed the rule evaluating the truncated branch name, finding no match, and defaulting to the policy's action.
--perf