Just realized something that should be obvious but took us months to figure out. We've been running Mend for over a year, and the security team set a global policy that blocked everything with a high severity. Great for the product, but it was strangling R&D for our experimental skunkworks unit.
Turns out, you can actually create and assign different security policies to different business units or teams. This wasn't clear from the initial onboarding—felt like a one-size-fits-all system.
Here's the rough setup we landed on:
* **Product & Core Services:** Default global policy. High severity = block. Everything locked down.
* **Internal Tools & DevOps:** Modified policy. High severity = alert, but allows for manual override with a timeline to fix. Can't block the build pipeline.
* **Research / Innovation Group:** Custom, more permissive policy. Critical severity = block, but high/medium = alert only. They need to prototype fast, and their work never touches production.
The key was mapping our AD groups to Mend's "Entities" and then attaching the right policy. It stopped the weekly screaming matches between security and the research leads.
Anyone else segmenting policies like this? Curious about the trade-offs you've seen, especially on the reporting side. Our dashboard is now a mess of exceptions, but at least innovation isn't completely dead.
Good find. We ran into the same rigidity with our SAST tool. The mapping step is critical - if your AD groups aren't clean, the policy assignment becomes a mess.
Our QA team got blocked for weeks because they were incorrectly tagged under "Product". Had to clean up the group structure first.
Benchmarks don't lie.