Okay team, I've been diving deep into Mend's policy and remediation features, and I keep hitting a conceptual speed bump with my team around the 'Suppress' and 'Ignore' actions. I *love* the granular control Mend offers, but I'm worried we're using them inconsistently and creating future debt.
Here's our hang-up: we understand that **Ignore** is for a specific vulnerability instance (like CVE-2023-12345 in *log4j-core-2.14.1.jar*), and **Suppress** is for a broader vulnerability signature or finding type. The power is there, but our workflow is messy.
Some engineers use 'Ignore' on a finding because they've applied a temporary workaround and want to revisit it later, while others use 'Suppress' on a library-level issue because "we don't use that function." This leads to confusion during audits or when a new team member looks at a suppressed/ignored list. We've also had cases where a Suppress rule created for one project accidentally applied to another because the scope wasn't set carefully.
How does your team handle this? I'm particularly interested in:
- Do you have a formal policy or checklist an engineer must complete before using either action?
- How do you document the *business* or *technical* rationale within Mend itself? Are you meticulous with those comment fields?
- Do you set expiration dates on these actions as a forcing function for review?
- How do you prevent "out of sight, out of mind" with these suppressed/ignored items?
I really want to leverage these features to keep our noise low and focus on real risks, but I want to do it in a clean, maintainable way. Any best practices or war stories would be super helpful
good docs save lives
I'm a senior backend engineer at a fintech company with around 200 developers; we run a significant microservices stack on Go and Java, and we've used Mend (formerly WhiteSource) in production for about three years to manage vulnerabilities across 400+ services.
Based on that experience, here's how we structured the decision between Suppress and Ignore:
1. **Mandatory JIRA Link:** Any Ignore or Suppress action must include a JIRA ticket ID in the Mend comment field. That ticket requires a specific template: a description of the risk, the business/technical rationale (e.g., "false positive due to XYZ scanner bug," "mitigated by network controls," "scheduled for update in Q3"), and an expiration date set for review.
2. **Scope Lockdown:** We disable global suppression rules entirely. All Suppress actions must be scoped to a single project or repository. This prevents the "spillover" you mentioned. We enforce this through Mend's role-based access control, where only security team members can create project-level suppressions.
3. **Ignore as a Temporary Gate:** The "Ignore" action is formally defined as a temporary, 30-day maximum state. It's used only for validated false positives or for vulnerabilities with an approved, immediate remediation ticket that is already in progress. After 30 days, Mend automatically resurfaces the finding.
4. **Suppress as a Risk-Accepted Policy:** The "Suppress" action is treated as a formal, documented risk acceptance. It requires sign-off from the service owner, the product security team, and must be re-evaluated annually. We use it exclusively for broader, accurate signatures where the affected code path is genuinely unreachable in our runtime environment.
Our pick is to treat **Ignore as a short-term operational tool and Suppress as a long-term policy decision.** If your team's primary pain point is clutter from temporary workarounds, enforce a strict time-bound policy on Ignore. If the bigger issue is risk hidden by over-broad rules, lock down Suppress scope and require documentation links.
sub-100ms or bust