Risk Score Calculation from Vulnerability Calculators
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-17-2025 11:21 PM
Can we calculate risk score by having field value in range in risk calculator criteria and not exact value...likewise x field value is 0.8...so instead of that can we have the field value as 0.7-0.9...as such I am taking in range and it's not working...I mean weightage is not being considered...likewise it does by taking exact value...so if there's any feasibility to take the value in range instead of exact value...please let me know...any lead would be appreciated...Thank you!...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-24-2025 05:24 PM
Hey there - curious, why are you using a custom field for EPSS (string), versus using the native integration with CISA KEV, that includes EPSS (decimal)?
If you are able to use the baseline CISA KEV integration (which includes EPSS as a decimal), the Risk Score Calcualtor ? Risk Rule > Field value, will work with the ranges.
I don't believe the ranges are going to work using a <string> field.
This is the format for the baseline EPSS Score when using the CISA KEV Store App (that includes EPSS as a decimal field):
You can check out the Script Include called "VulnerabilityCalculatorCommonBase". I believe around Line 32, it calls out the field formats that would likely work for "Ranges"
If you must stick with the custom EPSS (String) field, you may have to look at using a more involved scripted calculator to convert the string to do the weighting / calculation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-24-2025 09:49 PM
Actually, the data for EPSS is coming from host detection payload...i.e. from QDS Factor...so that's why using a custom field. Btw Just FYI, I tried checking with decimal data type and it's working fine. The calculator is taking into consideration the weightage for the field now. Thankyou!...so very much Andy for the quick turnaround. Hope I can proceed with the same...isn't it?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-25-2025 07:24 AM
Awesome -- glad you are able to move that forward, Piyush!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-25-2025 11:50 PM
Btw Andy one more thing I wanted to know...is there anything like we can't have/make more than 1 vulnerability calculator for same table having different target field due to any reason or so. I just wanted to know pros and cons of it...any performance issue or something like not a good practice. Please let me know.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-26-2025 08:01 AM
Hey Piyush,
I would say, this is one of those "just because you can, should you" scenarios.
Similar bit with VR Assignment Rules (scripted), you can technically set other values on target VIT records like you could with VR Risk Calculators (scripted).
The challenge with that, is it becomes tech-debt that you have to maintain - i.e. if another developer would have to jump in and review why a custom field was set to a value or not set, how would they ever know where to start triaging / diag from? Their first intuition likely would not be to go dive into an Assignment Rule or Risk Calculator first. I am also not sure how you currently document configurations, customizations and tech-debt - and if we are lacking in that space - this type of approach may not be the best path in terms of managing technical debt long term.
The other factor to consider, is if we use something like Assignment Rules (Scripted) or Risk Calculators (Scripted), to do something it is not intended to (like setting a custom field value) - we need to consider when those particular operations run (e.g. on record insert, on update of a certain field, when someone clicks the "re-apply" button). If we embed some special logic to set a custom field here - we may see odd behavior, have to maintain extra defensive logic in our script to determine when not to override logic. Don't lose sight of regression testing as well -> what happens when the business/stakeholders want to tweak the logic for setting that custom field, instead of regression testing just that one component (the custom field); now you have to regression test the entire Risk Score Calculator again, even though the change you made may not even have anything to do with the scoring logic - but we embedded an extra operation into the it. Then, the ultimate factor is performance as your data volume grows - when considering how these configurations work - and determining if it is really worth using these as the vehicle (i.e. Risk Calculator) to set a custom field value.
Hope this gives you insight on that.
