New policy engine - anyone tried it yet?

Alright, who here has been voluntold to be the FinOps person *and* the AppSec person simultaneously? 🙋‍♂️ Because that's me, and my two brain cells are constantly fighting: one screaming about cloud waste, the other about CVE-2024-whatever.

So Mend rolls out this new "Policy Engine" and my ears perked up. Not because I care deeply about component hygiene (I do, but grudgingly), but because the word "policy" in any SaaS product usually translates to "another way to get billed for overages" or "a new checkbox that creates alert spam."

I've poked at it for a couple of sprints. The premise is solid: define rules to block or flag problematic open-source components *before* they get merged, based on more than just CVSS score. You can mix and match license types, vulnerability age, dependency depth, even... *cost*? (More on that in a sec).

Here's my raw, bill-obsessed take:

**The Good:**
* The custom logic is actually flexible. It's not just "high severity = block." I built a rule to flag any `LGPL-3.0` or `GPL-3.0` component that's a **direct** dependency, because our legal team gets the cold sweats. The UI for building these policies is less infuriating than I expected.
* It *does* seem to shift left, which in theory should save engineering cycles. Fewer "OMG revert that lib now!" panics. Can't quantify the savings yet, but fewer midnight pages = cheaper on-call rotations.
* The "security and license" policies are what they're selling, but I'm eyeing the "custom attribute" filters. If you tag your internal libraries with metadata (e.g., `"deprecated": "true"`), you could theoretically block those too.

**The Skeptical (where I live):**
* The cloud cost angle. They mention you can create policies based on "repository tags." If I could tag our repos with `env: prod` and then block new high-severity vulns there, but only *warn* for `env: dev`, that's useful. But it's not a direct cloud cost save. It's an *indirect* risk reduction. My CFO wants direct.
* The execution feels a bit... slow? Or maybe it's just another async check in the CI pipeline. Our builds are already bloated cost-wise. Adding another deep scan at the policy evaluation stage might bump our compute time. I'm watching the AWS CodeBuild bills.
* No native integration with our cloud provider's billing data (obviously). So I can't make a rule that says "block if this library is known to cause high network egress in our AWS region." A man can dream.

**Weird thing I tried:**
I created a janky "cost" policy by using a custom attribute. We have an internal list of known "heavy" libraries (looking at you, certain ML packages). I tagged them in our internal registry with `"storage_size_mb": "450"`. Then made a Mend policy to warn if a component has that tag. It's a hack, but it sparked a conversation about transitive dependency bloat.

Has anyone else given this a serious run? I'm particularly interested in:
* False positive rates – are your devs just learning to click "override"?
* Any noticeable impact on pipeline duration (and thus, compute costs)?
* Are you using it to enforce **license** rules that actually have a future financial impact (like avoiding AGPL in a future commercial SaaS module)?

My cloud bill is too high, and now my vulnerability count is too high. This tool might help with one, but I need to be convinced it doesn't inflate the other.