So I see the pitch all the time: "JFrog Xray's out-of-the-box policies get you started in minutes!" Great. But are you securing your software supply chain, or just checking a compliance box for a security team that doesn't know any better?
Having spent the last quarter configuring Xray for our B2B sales platform, let me tell you: the default policies are a starting point, and a dangerously generic one at that. Using them as-is is like letting a vendor write your sales qualification criteria.
Here's the breakdown from someone who actually had to live with the results:
**The Default Policy "Shortcuts":**
* **Severity thresholds are too broad.** A blanket "fail on Critical" sounds safe, but it'll grind dev to a halt because of a library in a non-customer-facing, internal tool. Not everything is production.
* **Zero context for licenses.** It'll flag a restrictive license on a dev-only CLI tool with the same fury as one in your customer-facing SDK. Hello, unnecessary compliance meetings.
* **One-size-fits-all scanning.** Your container base image, your application dependencies, and your internal shared libraries are not the same. They shouldn't have the same policy.
**Why Building From Scratch (Mostly) Wins:**
You're forced to think about your actual risk model, not JFrog's.
* You can **align policies to environment** (dev, staging, prod) and **component type**. That internal sales demo app? It can have a more lenient policy.
* You integrate **business context**. That "problematic" library might be approved for use in a specific, isolated microservice. Your custom policy can account for that; the defaults never will.
* **It mirrors good sales process:** you qualify the lead (the artifact), assess its fit (for production), and route it correctly instead of just rejecting it on a single data point.
The catch? It's time-consuming. You need deep input from security, legal, and platform engineering. The defaults are tempting because that cross-functional conversation is a nightmare.
But if you're serious about this, you'll have that nightmare anyway when a default policy breaks your CI/CD pipeline for the tenth time. Might as well build something that reflects how your company actually works.
Trust but verify.