Guide: Auditing your Xray setup - common misconfigurations we found

Hey folks, been diving into our Xray setup at work recently while trying to trace some performance oddities in our container pipelines. We're heavy users, and like any complex tool, it's easy to end up with a config that *seems* fine but has some subtle gaps or inefficiencies.

I thought I'd share a few of the common misconfigurations we found during our audit. Maybe they'll help someone else.

### 1. Overly Broad Watches (The Performance Hit)
The default "All Repositories" watch is convenient but can be a killer for scan latency and resource use, especially if you have a mix of release and snapshot repos. Xray will trigger on *every* deployment.

We split ours up. For example, we created targeted watches for:
* Production release repositories (high priority, blocking)
* Snapshot/development repos (lower priority, non-blocking)
* External proxy repos like Docker Hub (different policy set)

This reduced unnecessary scanning chatter significantly.

### 2. Ignoring the "Fail on Download" Flag
This one's in the **Advanced** settings of your policy. If you have a "Security" policy set to `Fail on Download: false`, your builds might pass even if Xray finds critical CVEs. The violation is logged, but the artifact is still downloadable. This can create a false sense of security.

Check your critical policies:
```json
// In your policy definition, you want this for critical security rules:
"fail_on_download": true,
"block_download": true
```

### 3. Unoptimized Database Cleanup
Xray's DB can grow huge. The default cleanup (`xray.cleanup` cron job) might not be aggressive enough if you have high throughput. We noticed disk space issues.

We adjusted the retention periods in `$XRAY_HOME/config/xray.yaml`:
```yaml
cleanup:
maxArtifactsRetentionWeeks: 104 # ~2 years was too much for us
maxIndexesRetentionWeeks: 52
maxSummariesRetentionWeeks: 4
```
Monitor your DB size after changing this.

### 4. Resource Allocation for Large Scans
Running Xray on a VM with default Java heap settings? Big scans (like a monolithic base Docker image) can cause GC pauses and timeouts.

We added these to the `system.yaml`:
```yaml
shared:
javaOpts: "-Xms4g -Xmx8g -XX:+UseG1GC"
```
But the real fix was also ensuring our **Analysis** service nodes (where the unpacking/scanning happens) had enough CPU cores and RAM. Don't starve the workers.

### 5. Missing Custom Contextual Policies
We rely heavily on licenses. The built-in "Unknown License" policy caught everything, but we needed more nuance. For example, we allow `LGPL-2.1-only` in libraries but not in our distributed SaaS product binaries.

Creating a custom policy with a **Rules** -> **License** -> **Custom Condition** (like `License == "LGPL-2.1-only" AND Path Matches "**/dist/bin/**"`) saved us from manual reviews.

Anyone else found similar pitfalls? Or have tips on tuning the internal queues or EBPF tracing for Xray's service mesh? I'm curious about the actual system call overhead during massive graph DB updates.