Hi everyone. I'm setting up my first security scanning pipeline and trying to integrate JFrog Xray. The documentation keeps mentioning "watches" and "policies," but I'm getting tangled up on how they actually work together.
Could someone explain in simple, pipeline terms?
* Is a **policy** just a set of rules (like "block high-severity CVEs") that sits in a library?
* And a **watch** is what *applies* those policies to specific repos, builds, or artifacts?
* Do I need to bind them together, or does creating a watch automatically include policies?
A concrete example would really help my brain. If I have:
- A Docker repo `my-company-docker-prod`
- A build named `data-pipeline-image`
What would the watch and policy config look like to scan that build for critical vulnerabilities? Maybe a pseudo-YAML or just the steps?
Thanks 😅
You're spot on with your mental model! Think of policies as rulebooks (what to look for) and watches as assignment sheets (where to apply them). They're separate entities you explicitly bind together.
For your example, you'd first create a policy named something like "block-critical-docker" with a rule that triggers on severity >= Critical. Then create a watch that:
1. Targets your `my-company-docker-prod` repository (or specifically the `data-pipeline-image` build if you want)
2. Attaches the "block-critical-docker" policy to it
3. Defines actions like failing the build or sending a Slack alert
The watch doesn't do anything until you assign policies to it. It's like having a security camera (watch) that only starts recording violations when you give it a list of rules (policy) to enforce 😉
Happy to share a snippet of the actual JSON structure from my setup if you'd find that useful. The UI wizard walks you through it pretty well, but the config files help cement the relationship.
Automate all the things.
That's a solid analogy, and the separation of duties is crucial for scaling. One nuance I'd add from experience is that policy reuse across watches is where the real management complexity, and often hidden cost, creeps in.
You might start with that one "block-critical-docker" policy on a single watch. But then you'll need a similar, but slightly different, policy for your npm repos, and another for your release-stage builds where you only warn on criticals. Suddenly you have a dozen policy variations. The licensing or consumption cost often scales with the number of active, distinct policies, not just the number of watches. It's worth checking your tier's policy limit before you architect a separate policy for every minor permutation.
Also, the action definition (like failing the build) is tied to the *watch*, not the policy. So you can attach the same "block-critical-docker" policy to both a dev watch (which only sends an alert) and a prod watch (which fails the build), which is a powerful feature.
null