I've been wrestling with Mend's project management for a few months now, specifically around how it handles what it calls 'duplicate' projects. It seems like a common pain point when you're integrating into a CI/CD pipeline, especially if you have multiple branches or build environments triggering scans.
From what I can tell, Mend creates a new 'project' in its UI based on a combination of the project name and some internal identifiers. If your pipeline rebuilds the same code with a slightly different parameter, or if you're scanning both a feature branch and main, you can end up with a cluttered list of what appear to be identical projects. The deduplication logic isn't always transparent.
My main concern, from a secrets management perspective, is that this fragmentation can obscure the vulnerability timeline. If a critical library flaw appears in branch scan 'A' but not in duplicate project 'B', tracking the rollout of a fix becomes manual and error-prone. It feels like we're hardcoding project identities in our pipeline scripts just to keep Mend happy, which is exactly the kind of rigid coupling I try to avoid.
How are others navigating this? Are you:
- Forcing a consistent `projectName` and `projectToken` across all builds of the same application?
- Using the Mend API to clean up old project entries post-merge?
- Or accepting the duplication and using tags or custom fields to group them logically?
I'm particularly interested in patterns that work well with infrastructure-as-code setups, where we want the scanning to be declarative and repeatable without creating UI clutter.
Encrypt all the things.
You've hit on a major CI/CD integration headache. The project name plus identifier combo is a known issue.
We standardized on a single, computed project name in our pipeline, ignoring branches for the Mend upload. The branch-specific data gets tagged inside the scan results via custom fields instead. This keeps the project list clean. The downside is you lose the automatic branch separation in the UI, so your dashboard filters become critical.
Have you measured the actual risk of missing a fix rollout due to this fragmentation, or is it a perceived audit trail problem? I'd want to see numbers on missed SLA compliance before dedicating more engineering time to workarounds.
Standardizing the upload name is the only way to keep a sane UI. The audit trail issue is real, not just perceived - if a fix verification scan gets buried in a separate project for a release branch, it's a compliance miss waiting to happen.
Your custom field tagging works, but it pushes the filtering burden onto every team member using the dashboard. That creates its own risk when someone doesn't set the filter correctly.
We solved it by adding a pipeline stage that re-tags the main project with the latest branch scan results and closes the old 'duplicate' via API.
You're right that this fragmentation can really muddy the timeline for fixing a critical vulnerability, especially when you need a clear audit trail. The coupling to pipeline scripts is an anti-pattern.
I'd add a practical caveat to the other suggestions: forcing a consistent project name works, but you must pair it with a strict policy to archive the old, true duplicate projects via API on a schedule. Otherwise, you're just hiding the mess, and it can still cause confusion during an audit if someone stumbles upon the outdated entries.
Have you considered using Mend's product tokens as the single source of truth for project identity, instead of letting the CI/CD tooling dictate it? That shifts the control plane back to the security team.
That's a really good point about the audit trail risk. If an auditor sees those archived projects and asks why there are multiple entries, you need a solid explanation ready. Hiding them doesn't make the problem go away, it just moves it.
I'm still new to the Mend API. When you archive old projects on a schedule, do you just change their status, or are you actually deleting them? What's the best practice there?