Having recently migrated our artifact governance from a patchwork of CLI tools to JFrog Xray, I'm conducting a latency-versus-safety analysis on policy enforcement. The core challenge is architecting a policy matrix that imposes stringent, latency-sensitive checks in production while allowing faster, more permissive scans in development pipelines.
My current approach uses a combination of **Watch assignments**, **Policy rules with priorities**, and **Security/ License criteria**. The goal is to fail builds immediately for critical CVEs in prod, but only warn for dev, while also accounting for license compliance which is uniformly critical. Here is a skeletal configuration illustrating the principle:
```json
{
"policy": {
"name": "prod-critical-blocking",
"type": "security",
"rules": [
{
"name": "block-critical-severity",
"priority": 1,
"criteria": {
"min_severity": "Critical",
"fix_version_exists": false
},
"actions": {
"fail_build": true,
"notify_deployer": true,
"block_download": true
}
}
]
}
}
```
I've assigned this policy to Watches that target my `prod-*` repositories. For development, I have a separate policy where the `actions` for the same severity might only trigger `notify_deployer` and `log`, with `fail_build` only on "High" severity or worse.
My specific queries for the community are:
* **Rule Priority Collision:** How does Xray resolve a scenario where an artifact is covered by multiple Watches with differing policy priorities? If a dev branch image is promoted to a prod repository, does the policy re-evaluation incur a full rescan, and what's the typical latency for that re-evaluation?
* **Criteria Granularity:** Has anyone successfully implemented environment-aware policies using custom properties (e.g., `env=prod`) on builds or artifacts as part of the rule criteria, rather than relying solely on repository-based watches? This would offer finer control.
* **Performance Overhead:** What is the observable delta in pipeline duration when comparing a "warning-only" policy set versus a "blocking" policy set? My preliminary benchmarks show a ~2-3 second overhead for the blocking actions on a mid-sized Docker image scan, but I suspect this scales with component count.
The documentation outlines the mechanics, but I'm seeking empirical data on the real-world performance and nuanced behavior of these policy interactions. Any insights, especially those backed by metrics or A/B testing results, would be invaluable.
--perf
--perf