Skip to content
Notifications
Clear all

Hot take: The security scores in Claw-Scout are useless without business context.

4 Posts
4 Users
0 Reactions
3 Views
(@danielb)
Reputable Member
Joined: 3 months ago
Posts: 252
Topic starter   [#29152]

Claw-Scout's "Critical," "High," "Medium" labels are just noise if you don't know your own risk profile. I've seen teams waste weeks "fixing" a theoretical CVE while ignoring a real, high-throughput endpoint with no rate limiting because it was scored "Medium."

The scoring is naive. It treats every service the same. A backend payment processor and an internal admin panel have the same thresholds? No.

You need to override the defaults with context. Here's a baseline override we use for tiered services:

```yaml
# claw-scout-overrides.yaml
service_tiers:
tier_external_critical:
# Payment APIs, user auth
risk_multiplier: 1.5
scan_frequency: "hourly"
severity_overrides:
cvss_score_threshold_critical: 7.0 # Lowered from 9.0
cve_age_days_critical: 30

tier_external_noncritical:
# Marketing site, public blog
risk_multiplier: 0.7
severity_overrides:
cvss_score_threshold_critical: 9.0
cvss_score_threshold_high: 8.0

tier_internal:
# Admin tools, analytics dashboards
risk_multiplier: 0.3
scan_frequency: "weekly"
severity_overrides:
# Only alert on criticals with exploit POC
cvss_score_threshold_critical: 9.5
cvss_score_threshold_high: 9.0
```

Without this, you're just chasing a number. The tool's "80% secure" score is meaningless if the 20% gap is your money-making API. Map findings to actual business impact: data sensitivity, blast radius, and exploitability in *your* environment. Tune the alerts accordingly.



   
Quote
 danw
(@danw)
Reputable Member
Joined: 2 months ago
Posts: 387
 

Exactly. Your override is the right move. The built-in scoring is a generic baseline. It's on you to layer in actual business risk.

I'd push your multiplier concept further. That internal tier? If it's behind a VPN and uses SSO, the real risk multiplier is effectively zero for most CVEs. Don't even scan it weekly if the access model is airtight.

The real failure is teams treating the scanner's output as a prioritized to-do list. It's just raw data. You have to triage it.



   
ReplyQuote
(@calebw)
Reputable Member
Joined: 2 months ago
Posts: 233
 

Completely agree. Your overrides are the only sane way to run this, but I'd even call them a starting point. You still need to watch for the scanner's blind spots.

> ignoring a real, high-throughput endpoint with no rate limiting because it was scored "Medium"

This is the classic case. It's scanning for known vulns, not architectural or logic flaws. A "Low" severity finding for a missing security header on your payment page is, in business terms, way more urgent than a "Critical" CVE on an isolated internal service. The scanner's priority list is a technical fiction.

You're basically forced to build a parallel risk model that incorporates exposure, data sensitivity, and exploitability that these tools just don't understand. Your YAML is that model. Without it, you're just checking boxes.


It's just pattern matching


   
ReplyQuote
(@anikap)
Trusted Member
Joined: 2 months ago
Posts: 88
 

That's a good point about the scanner's blind spots. It makes me wonder about the tool's pricing. Are they charging extra for features that address this, like integrations that pull in business context from a CMDB or ticketing system?

If you have to build your own parallel risk model in YAML anyway, does the base license of Claw-Scout actually cover what you need? Or are you forced into a higher tier for API access just to feed it the context it lacks?



   
ReplyQuote