I've been evaluating their platform updates, and the new "risk score" dashboard widget is prominently featured. While the intent—to prioritize findings—is good, the calculation feels opaque compared to their previous severity models.
The documentation mentions it combines flaw severity, exploitability, and "business context." But the weights and the specific data points for exploitability aren't exposed. For example:
* Is it using CVSS 3.1? Which metrics?
* How does "business context" from the questionnaire actually adjust the numeric score?
* Does a flaw in a library with a public exploit always outweigh a critical flaw in an internal admin tool?
I compared two nearly identical SQL injection flaws in different apps within our portal. One got a risk score of 320, the other 285. The only differing factor I could find was the "application type" set in the policy. That's a significant variance based on a fairly subjective input.
This makes automated gating in CI/CD tricky. We used to gate on "severity 4 or 5." Now, what threshold do we use for this composite score? Without knowing the formula, we can't confidently predict how code or policy changes will affect the score.
Has anyone from Veracode or the community managed to reverse-engineer the major levers? Or gotten clearer guidance on how to map these scores back to actionable, technical remediation steps?
Show your work.
Mike D.
You've identified the core problem for procurement and security governance. Opaque scoring models are a non-starter for contract enforcement and operational SLAs.
In my last negotiation, I made them attach the full scoring algorithm as a schedule to the MSA. They resisted, but we got it. Turns out their "business context" multiplier was a 1.0-2.0 scalar based on tags their system applied automatically, not our questionnaire answers. That's why your scores varied.
Without the formula, you can't define a pass/fail threshold in a contract. Tell them to provide the calculation or you'll discount the feature's value to zero during renewal. Use the lack of transparency as a lever to reduce price.
List price is for suckers
Getting the algorithm attached to the MSA is the right move, but it's only the first step. The real test is if they actually update that schedule when they change the scoring logic, which most vendors do silently.
I've seen the "automatic tags" scenario before. They often pull from vague data sources like public repository age or package popularity, which has little to do with my actual runtime environment. If their scalar is based on flawed data, the agreed-upon formula is worthless.
Your procurement tactic is solid, but the operational follow-through is key. You need a clause requiring notification and justification for any changes to that scoring schedule.
SecDevOps