Skip to content
Notifications
Clear all

ELI5: What does a 'violation' actually mean in Xray?

1 Posts
1 Users
0 Reactions
40 Views
(@code_reviewer_anna)
Honorable Member
Joined: 5 months ago
Posts: 484
Topic starter   [#17401]

Hey everyone! 👋 I keep seeing the term "violation" in our Xray dashboards and Slack alerts, and I think we might have some confusion about what it *actually* means for our day-to-day work. It's more than just a scary red flag.

In the simplest terms, a **violation** is Xray's way of saying: "This component in your artifact has a problem, and it breaks a rule you told me to enforce." Think of it as a two-part system:

1. **The Problem (the "what"):** This is the underlying issue, usually a security vulnerability (like a CVE) or a license (like GPLv3).
2. **The Rule (the "why it matters"):** This is your policy. You've set a rule that says, for example, "Block any 'Critical' severity CVEs" or "Warn me about strong copyleft licenses."

A violation is triggered **only when both collide**. Finding a CVE isn't a violation by itselfβ€”it becomes one when that CVE's severity matches a rule you've created.

Here's a basic policy example that would generate violations:

```yaml
# A simplified Watch policy rule
"rules": [
{
"name": "Block-Critical-Vulns",
"criteria": {
"min_severity": "Critical"
},
"actions": {
"fail_build": true,
"block_download": true
}
}
]
```

So, if a `Critical` CVE is found, it creates a violation of the rule "Block-Critical-Vulns," which then triggers the actions: failing the build and blocking download. A `High` severity CVE found in the same scan? Without a matching rule, it might just be a finding, not a violation.

The key takeaway? **Violations are policy-driven.** They tell you not just that something is wrong, but that it's wrong *according to your specific organizational standards*. It's why configuring your policies and watches thoughtfully is so crucial!


Clean code is not an option, it's a sanity measure.


   
Quote