For teams working through competing priorities
A list of critical findings does not explain which systems are affected, whether two tools describe the same issue or what the business can safely change. Security and IT teams need enough context to choose work and defend that decision.
ThreatShield connects application and vulnerability evidence with reporting and remediation workflows. It can support an organisation consolidating existing tools, reviewing an application estate or building a more accountable patching process. The first step is to establish which inventories and vulnerability sources can actually provide evidence.
What the available evidence can show
Supported integrations include Tenable, Qualys and Rapid7, alongside endpoint sources and on-premises application collection. Coverage differs between those paths. The reporting workflow includes a consolidated register for supported endpoint findings, on-premises software findings and Microsoft Defender device-to-vulnerability associations.
Where source fields allow, that register brings together a host, product and CVE, while retaining source observations and disagreements. Different names or uncertain device identity can leave separate rows that need review. Source connection status, collection success and the presence of usable records matter as much as the apparent finding count.
Prioritisation that explains its inputs
Severity is a starting point. Available on-premises vulnerability enrichment can also use CISA Known Exploited Vulnerabilities context, EPSS and public exploit availability. Those inputs support a more informed review of urgency alongside the affected system and its operational importance.
Not every provider supplies the same intelligence. A row without an exploitation-based priority is unmeasured on that basis; it is not automatically lower risk. Version matches, fixed releases and conflicting observations may need investigation before a team chooses a patch, configuration change or other response.
From a finding to a reviewed outcome
Confirm the affected system and proposed change, assign the work and review service impact. Supported remediation uses approved recipes and the applicable tenant, host and policy controls. Unattended dispatch also depends on configured authorisation, maintenance windows and other action limits. Read-only engagements remain advisory.
Recipe coverage varies, and some findings require a manual change plan. Deployment or assignment is not evidence that an application is installed or the exposure removed. Review fresh inventory or assessment evidence after the work, retain unresolved findings, and keep unavailable sources distinct from a verified clean result.
How it works, step by step
- Establish the sources. Confirm which endpoint, inventory and vulnerability tools can actually provide evidence, and how current their data is.
- Consolidate the findings. Bring host, product and CVE together in one register, keeping source observations and disagreements visible.
- Prioritise with context. Read severity alongside CISA KEV, EPSS and public-exploit availability where available, and the affected system’s importance.
- Choose and authorise the response. Decide on a patch, configuration change or other action, and move supported changes through approval, recipe and maintenance controls.
- Verify the outcome. Collect fresh inventory or assessment evidence after the work, retaining unresolved findings and unavailable sources.
What the vulnerability workflow can show
Coverage differs between connected sources. Where the evidence is available, the workflow can bring together:
- A consolidated register linking a host, product and CVE across supported endpoint, on-premises software and Defender device associations.
- Severity alongside CISA Known Exploited Vulnerabilities context, EPSS and public exploit availability, where the provider supplies it.
- Version matches, fixed releases and conflicting observations that need investigation before a decision.
- Duplicate or uncertain device identity that leaves separate rows for review.
- Rows without an exploitation-based priority, flagged as unmeasured rather than automatically low risk.
- Source connection status and collection success, so a low count is not mistaken for a clean result.
A missing finding does not prove a system is fixed. A disconnected source, a failed collection or a device that stopped reporting can make a finding disappear.
Framework alignment
Vulnerability work maps directly to well-known control expectations: CIS Control 7 (Continuous Vulnerability Management), the NIST Cyber Security Framework Identify and Protect functions, and the security-update-management theme of UK Cyber Essentials. The consolidated register and prioritisation give a team the evidence those controls ask for.
Meeting a control depends on the sources connected and the actions authorised in your environment, not on the mapping itself. ThreatShield keeps the source evidence behind each finding so remediation can be demonstrated rather than assumed.
Questions about Vulnerability management
Can we keep our existing vulnerability tools?
ThreatShield supports connections for Tenable, Qualys and Rapid7, as well as other endpoint and inventory sources. Confirm the required product, API access and available data when scoping the connection.
Can every vulnerability be fixed automatically?
No. Automated work is limited to supported, authorised actions that pass the relevant policy controls. Missing recipes, higher-impact changes or unresolved evidence require another reviewed next step.
Does a missing finding prove that a system is fixed?
Only comparable, successful collection can support that conclusion. A disconnected source, failed collection or device that stopped reporting can also make a finding disappear.
Can we consolidate findings from more than one scanner?
Yes. The register is designed to bring supported endpoint, on-premises software and Microsoft Defender findings together, linking a host, product and CVE where the source fields allow, while keeping disagreements between tools visible.
Does read-only vulnerability management still add value?
Yes. On a read-only or advisory engagement the workflow still consolidates, prioritises and reports findings with their evidence. Automated remediation is a separate, authorised capability that depends on the relevant policy controls.