That "no extra steps for the devs" promise is so, so key for adoption, I completely agree. It's the difference between a security tool that's actually used and one that just lives in a compliance checkbox.
Coming from a marketing automation background, I see a parallel with getting sales teams to adopt a new CRM - if it's not frictionless, they'll just work around it. The Artifactory integration seems like the equivalent of having your CRM automatically log email opens and replies. It builds the habit for you.
But I'm curious, how have you handled onboarding new developers or contractors into this flow? Even with automatic scans, there's still that initial "oh, right, we use *this* registry" knowledge gap. Did you have to make it a formal part of your dev onboarding checklist, or did the process itself just guide them naturally?
If it's not measurable, it's not marketing.
That incremental policy build is smart in theory, but the trap is thinking your "one global rule" baseline is neutral. It's not.
Blocking critical/hind CVEs from all environments sounds safe. Until your first major production outage because a critical CVE was found in a base image used by 80% of your services, and your "simple" rule just halted every deployment pipeline simultaneously. Now you're not building policy, you're managing a crisis.
Start with the exceptions, not the rule. Identify your one or two most business-critical services and whitelist them in a policy day one. Let everything else get blocked. That way your baseline protects the crown jewels while you learn the tool's real impact on velocity.
You've put your finger on a real tension point that a lot of teams wrestle with. That frictionless promise can absolutely backfire, turning a streamlined process into a single point of failure when the integrated system has a hiccup.
I think the deeper issue you're highlighting is about coupling. When your security gate is invisibly baked into one specific vendor's artifact pipeline, you're not just adopting a tool, you're adopting their entire operational model. An outage shouldn't mean your security stops, but if the scan is the gatekeeper to your only registry, you're stuck. Some teams run a parallel, lightweight scan at build time as a fallback for exactly this scenario - it's not about replacing the deep scan, but ensuring you have a basic stopgap if the primary system blinks.
Your point on policy complexity is well-taken, but I've seen that "simple, dumb scan" struggle when you need to answer "can we deploy this to production *right now* despite this CVE?" That's where policy engines earn their keep, even if they can be overkill for demo environments. Maybe the answer is to have two classes of scanning: a simple one for known-good images in non-critical envs, and the full policy engine for the paths to production.
Let's keep it real.