SecPod

Learn Search

Search across all Learn content

← Back to Security Research
Understanding SanerNow Risk Prioritization Engine

Understanding SanerNow Risk Prioritization Engine

With Advanced Vulnerability Management, SanerNow reveals a hundred thousand vulnerabilities in an account of devices. Risk Prioritization helps reduce the risk findings to a list of CVEs and CCEs that should be acted upon immediately for an organization. The aspects that assist Automated Decision Ma...

Sep 12, 2023By Preeti Subramanian5 min read

With Advanced Vulnerability Management, SanerNow reveals a hundred thousand vulnerabilities in an account of devices. Risk Prioritization helps reduce the risk findings to a list of CVEs and CCEs that should be acted upon immediately for an organization. The aspects that assist Automated Decision Making for Prioritization encompasses Exploitability, Automatable, Technical Impact, and Mission Prevalence for the organization. The CISA Stakeholder-Specific Vulnerability Categorization (SSVC), a customized decision tree model assists in prioritizing vulnerability response for customers by evaluating vulnerabilities. The goal of SSVC is to assist in prioritizing the remediation of a vulnerability based on the impact exploitation would have on the organization(s). The decision tree determines four possible outcomes for a risk – Track, Track*, Attend, and Act.

ValueDefinitionMarked as
EssentialThe vulnerable component directly provides capabilities that constitute at least one MEF for at least one entity; component failure may (but does not necessarily) lead to overall mission failure.High
SupportThe vulnerable component only supports MEFs for two or more entities.Medium
MinimalNeither support nor essential apply. The vulnerable component may be used within the entities, but it is not used as a mission-essential component, nor does it provide impactful support to mission-essential functions.Low

Exploitability

The prioritization primarily works with SecPod’s Unique Risk Categorization Algorithm that applies data analytics that correlates multiple factors such as our Risk to Malware Vulnerability Enumeration (MVE) Mapping, Exploit references, CISA Known Exploit Vulnerabilities (KEVs), and Google Project Zero findings, abridging critical vendors and crucial findings categorization to compute Risk Exploitability Score for each finding. Further, the calculated Exploitation Score of risk is graded into High, Medium, or Low based on a range. 

Automatable

Automatable captures the answer to the question, “Can an attacker reliably automate, creating exploitation events for this vulnerability?” Each risk is checked to be evaluated for Automatable i.e. Yes or No. Automatable value ‘Yes’ for risk is concluded if the risk can be reliably automated with steps 1- 4 of the kill chain, otherwise, it is set to ‘No’. 

11% of risks can reliably automate steps 1- 4 of the kill chain
11% of risks can reliably automate steps 1- 4 of the kill chain

Multiple factors help determine that Steps 1-4 of Kill Chain can be reliably automated such as

(1) determining if a device is internet-facing and enumerable on the network

(2) If CVE weaponization is possible through chaining

(3) delivery that checks if channels cannot be blocked by widely deployed network security configurations

(4) If there is an exploitation mitigation mechanism that is already in place that frustrates attackers from automating the attack, this considers MITRE ATT&CK Techniques, Tactics, and Mitigation mapping with CVEs and CCEs, and evaluating these automated checks with scan. 

A set of questionnaires also aids in answering some of the data points that cannot be automated through scan. These help ensure the Automatable value. 

Technical Impact

The technical impact is similar to the Common Vulnerability Scoring System (CVSS) base score’s concept of “severity.” When evaluating technical impact, the definition of scope is particularly important. The decision point, “Total,” is relative to the affected component where the vulnerability resides. If a vulnerability discloses authentication or authorization credentials to the system, this information disclosure should also be scored as “Total” if those credentials give an adversary total control of the component.  

Risk Prioritization Scanner detects Technical impact through various means, CVSS Score Metrics, Information disclosure CWEs mapped to CVEs, Intelligent Text Search Algorithm to determine credential exposure, and other techniques, to conclude the value of the Technical Impact of Risks on Devices.

technical impact
technical impact

Mission Prevalence

This has an impact on the Mission Essential Functions of Relevant Entities. A mission essential function (MEF) is a function “directly related to accomplishing the organization’s mission as set forth in its statutory or executive charter.” Identifying MEFs is part of business continuity planning or crisis planning. In contrast to non-essential functions, an organization “must perform a [MEF] during a disruption to normal operations.” The mission is the reason an organization exists, and MEFs are how that mission is realized.Nonessential functions support the smooth delivery or success of MEFs rather than directly supporting the mission.  

A set of questionnaires is implemented for users and answers can be manually entered with auto-fill from a device list, group list, asset list, etc. or even uploaded as new line-separated device names. 

Which devices are essential for Mission Prevalence in the account?

Which devices not essential yet support Mission Prevalence in the account?

Which devices have minimal impact on Mission Prevalence in the account?

Which are the organization’s perimeter-facing devices?

Which devices are business mission-critical?

Which devices are storage-centric?

What are the mission-critical software assets on devices in the account?

mission prevalence
mission prevalence

The Decision Tree

risk prioritization decision tree
risk prioritization decision tree
Mitigation of risks prioritized
Mitigation of risks prioritized

The values of Exploitability, Automatable, Technical Impact, and Mission Prevalence help reach a decision and prioritize whether the risk should be acted upon immediately. 

Track – No action required, remediation tracking within standard update timelines. 

Track* – Vulnerability has specific characteristics, and requires closer monitoring for changes, and remediation tracking within standard update timelines. 

Attend – Requires attention from the organization’s internal; supervisory level individuals, necessary actions may include required assistance or information about the vulnerability, and involve a notification internally or externally. Attend Sooner. 

Act – Requires attention. Act as soon as possible. 

A detailed listing of Risk Prioritization is shown in a tabular format. Search, sort, and Filters are in place for sieving risks, intellectualizing, understanding the impact on devices, and applying mitigation. 

Mitigation of Risks Prioritized

Each risk can be fixed using SanerNow’s Patch Management (PM) feature. A single click on the Fix symbol next to the Risk ID from the dashboard can redirect to the PM patching interface or CCE patching interface. 

Remediation tasks or automation scripts can be created easily and tracked using the Patch Management Interface. Special features such as Test and Deploy, and timed remediation can be achieved through this feature-rich interface. 

Featured Posts

Open WHIPSHOT and SLAPSHOT: Citrix NetScaler Zero-Days Exploited to Plant Root Web Shells and Internal Tunnels
WHIPSHOT and SLAPSHOT: Citrix NetScaler Zero-Days Exploited to Plant Root Web Shells and Internal Tunnels

CVE Research

WHIPSHOT and SLAPSHOT: Citrix NetScaler Zero-Days Exploited to Plant Root Web Shells and Internal Tunnels

Oct 1, 2026

Open OpenSSL’s DTLS State Handling Error Opens the Door to Heap Data Exposure
OpenSSL’s DTLS State Handling Error Opens the Door to Heap Data Exposure

CVE Research

OpenSSL’s DTLS State Handling Error Opens the Door to Heap Data Exposure

Oct 1, 2026

Open Patch Analysis & Exploitation Timeline: Critical WSO2 and Adobe Flaws Show 1-Day vs. 133-Day Exploitation Window , September 24, 2026 KEV Additions
Patch Analysis & Exploitation Timeline: Critical WSO2 and Adobe Flaws Show 1-Day vs. 133-Day Exploitation Window , September 24, 2026 KEV Additions

CVE Research

Patch Analysis & Exploitation Timeline: Critical WSO2 and Adobe Flaws Show 1-Day vs. 133-Day Exploitation Window , September 24, 2026 KEV Additions

Two critical vulnerabilities added to CISA KEV on September 24, 2026 reveal sharply different exploitation timelines. CVE-2026-71362 saw publicly documented exploitation roughly one day after Adobe's patch release, while CVE-2026-5430 had a 133-day vendor-remediation-to-observed-exploitation interval.

Oct 1, 2026

Open Patch Analysis & Exploitation Timeline: Same-Week KEV Additions, Year-Apart Patch Dates - Linux Kernel, September 18, 2026
Patch Analysis & Exploitation Timeline: Same-Week KEV Additions, Year-Apart Patch Dates - Linux Kernel, September 18, 2026

CVE Research

Patch Analysis & Exploitation Timeline: Same-Week KEV Additions, Year-Apart Patch Dates - Linux Kernel, September 18, 2026

Three Linux kernel vulnerabilities entered CISA’s KEV catalog on September 18, 2026, although their Linux 6.12 fixes were available 91–386 days earlier. This analysis separates patch availability, CVE publication, and known-exploitation status without treating KEV dates as first-attack dates.

Sep 28, 2026