Priority scoring
Every finding gets one priority score from 0 to 100, built from five weighted components. The formula is visible, the weights are yours, and every score keeps a copy of the inputs and weights used at the time it was calculated. There is no model to trust. There is arithmetic to check.
The five components
Exploitability
Is this being exploited in practice? Driven by Sinterly's own verdict rather than the scanner's label, using the CISA Known Exploited Vulnerabilities catalogue, EPSS probability, and the mapping from weakness class to known attack patterns. Where no evidence exists the verdict is unverified and the score falls back to the reported severity and CVSS, so an unverified finding never scores worse than it would have without the verdict engine.
One rule overrides everything else: a CVE in the KEV catalogue pins this component to its maximum. Something being exploited in the wild is not a matter of degree. The override is recorded alongside the score, so the displayed components always explain the displayed total.
Reachability
Can the vulnerable code actually be reached? Sinterly does not analyse your source, so this reflects what your scanners report, including taint traces where a tool provides one. Where it cannot be established, the verdict is unverified and the component falls back rather than guessing.
Business context
How much does the affected system matter? Driven entirely by the tier you set on the target, from A for public-facing and revenue-generating down to D for internal systems with no public surface. This is the component most under your control and the one most worth getting right.
Cost of delay
What does waiting cost? Exposure compounds faster for some classes than others. Access control and authentication weaknesses escalate quickly; findings with a known CVE at high severity carry more urgency than the same severity without one.
Remediation effort
Cheap fixes to serious problems rise; expensive fixes to marginal problems fall. This is driven by real fix data where your scanner supplies it. A published fix that stays within the current major version is a cheap win. A fix that requires a major version migration is not. Where no fix data exists, a class-based estimate is used instead.
Weights and versioning
The five weights must sum to one and are edited on the Scoring page by an AppSec Lead. Saving creates a new version rather than overwriting the old one.
This matters more than it sounds. Each historical score keeps the weights used when it was calculated, so tuning the formula today never falsifies what a score meant last month. Every change is recorded in the audit log.
What the score is not
- It is not a formal risk rating, and it is not comparable between organisations.
- It is not what the CI gate uses. The gate acts on explicit conditions, never on a score threshold, because a threshold produces an argument about the number every time it fires.
The backlog in effort and money
A score of 68 tells a security engineer something and tells a finance director nothing. Sinterly also expresses the same two economic components in units that travel outside the security team.
Effort, always available
Each finding carries an estimate of code time and process time. Summed across your open backlog, that gives engineer-days and sprints of one engineer's capacity. No input from you is required.
These are planning estimates derived from scanner fix data and issue class. They are not a measurement of your codebase, and the product says so wherever the figure appears.
Money, only when you supply the rates
Sinterly does not know what an hour of exposure costs your business, and it will not guess. An AppSec Lead supplies the rates, and until they do you see engineer-days and no currency at all.
| Input | What it produces |
|---|---|
| Engineer day cost, fully loaded | The cost to clear the backlog |
| Cost per day of exposure, per tier A to D | The cost of carrying the backlog another day or another sprint |
| Productive hours per day, and sprint length | Makes the arithmetic match how your team actually works |
Rates are set through the API today rather than a settings screen. An AppSec Lead can post them with their session token:
curl -X PUT https://api.sinterly.com/api/admin/economics \
-H "Authorization: Bearer <your session token>" \
-H "Content-Type: application/json" \
-d '{"currency": "GBP",
"engineer_day_cost": 600,
"tier_a_delay_cost_per_day": 250}'Every field is optional and a partial update leaves the rest alone, so you can answer the parts you are confident about and come back to the others.
Every field is optional. If you can only answer for tier A, you get tier A figures and honest silence for the rest, with the missing inputs named. Until you supply anything, you see engineer-days and no currency at all.