A common operational challenge when scaling artifact scanning within a Kubernetes-native, GitOps-driven pipeline is alert fatigue. JFrog Xray's default watch behaviors, while comprehensive, often generate a volume of findings that can obscure genuinely critical runtime threats—specifically, vulnerabilities with a CVSS score >= 9.0. The goal is to implement a surgical watch policy that triggers alerts *only* for these critical CVEs, thereby integrating seamlessly with a paging system or a high-severity Slack channel, without the noise of lower-severity reports.
This configuration hinges on a precise understanding of Xray's Policy and Watch schema. The following step-by-step guide utilizes a declarative, Infrastructure-as-Code approach, defining the resources in JSON suitable for version-controlled management.
**Step 1: Define a Critical Severity Policy**
A Policy is the rule engine. We'll create one that targets vulnerabilities, specifically filtering for the `Critical` severity band (which Xray maps from CVSS scores).
```json
{
"name": "critical-cve-only",
"description": "Flags only Critical severity CVEs (CVSS >= 9.0)",
"type": "security",
"rules": [
{
"name": "critical-severity-rule",
"criteria": {
"min_severity": "Critical",
"max_severity": "Critical"
},
"actions": {
"fail_build": false,
"notify_watch_recipients": true,
"block_download": {
"unscanned": false,
"active": true
}
},
"priority": 1
}
]
}
```
*Note: `block_download` is set to active as a proactive containment measure for critical flaws. This can be adjusted based on organizational risk posture.*
**Step 2: Construct a Targeted Watch**
The Watch applies the policy to a defined set of resources. Precision here is key—scope it to the relevant repositories, builds, or release bundles.
```json
{
"name": "watch-critical-production-images",
"description": "Monitors production Docker repositories for Critical CVEs",
"active": true,
"resources": {
"repositories": [
{
"name": "docker-prod-local",
"filters": [
{
"type": "package-type",
"values": ["Docker"]
}
]
}
]
},
"assigned_policies": [
{
"name": "critical-cve-only",
"type": "security",
"filters": []
}
],
"watch_recipients": [
{
"name": "security-response-team",
"type": "group"
}
]
}
```
**Step 3: Operational Integration and Caveats**
- **GitOps Integration:** These JSON definitions should be managed in a Git repository, with changes applied via Xray's REST API or a Terraform provider (if available) as part of your infrastructure pipeline.
- **Scope Refinement:** The watch's resource filters can be extended using `path-ant-patterns` or `property-sets` to further isolate, for instance, only images with the `prod` label. This is crucial in a multi-tenant cluster environment.
- **Performance Consideration:** While limiting to critical CVEs reduces alert volume, ensure Xray's indexing schedule aligns with your image promotion cadence. A vulnerability must be indexed before the watch can evaluate it.
- **False Positive Management:** This policy is severity-gated, not CVE-gated. It will include all critical CVEs, including those that might be false positives or not applicable to your specific runtime context. A complementary process for triage and exemption management is still required.
The resultant setup ensures that operational paging is reserved for the most severe threats, aligning the security feedback loop with the urgency implied by the CVSS metric. This granular control is essential for maintaining the signal-to-noise ratio in large-scale, automated deployments.
Your policy filter's missing the actual severity criteria. You need the "filters" block inside the rule.
```json
"rules": [
{
"name": "critical-severity-only",
"criteria": {
"filters": [
{
"type": "severity",
"value": "Critical"
}
]
},
"actions": [
{
"type": "fail_build"
}
]
}
]
```
Also, this won't catch CVSS 9.0 exactly if Xray's internal mapping is off. Test with a known CVE.
Benchmarks don't lie.