Vulnerability Intelligence (VULNINT): Intelligence Discipline Guide

There are more vulnerabilities than you will ever patch. Vulnerability intelligence exists to tell you which few hundred actually matter this week.

What Vulnerability Intelligence is as a discipline

Vulnerability intelligence is the collection and analysis of information about software and hardware weaknesses, their exploitability, and their exploitation in the wild. It ingests advisories and CVE records, vendor bulletins, patch notes and code commits, proof-of-concept publication, exploit-kit and ransomware adoption reporting, honeypot and scan telemetry showing real exploitation attempts, and researcher discussion. The analytical product is not a list of identifiers but a prioritised assessment tying specific weaknesses to your deployed technology, your actual exposure and observed adversary interest.

Sub-methods include advisory monitoring, exploit-availability tracking, confirmation of exploitation in the wild, and asset correlation against inventory and software bill-of-materials data. Maturity moves from severity-score-driven patching, through evidence-based prioritisation using exploitation and exposure data, to predictive triage that flags likely targets before public exploitation begins. It consumes attack surface intelligence to know what is exposed and feeds cyber intelligence with the detection requirements for the techniques used against unpatched systems.

Why it matters

This discipline answers which weakness in your estate will actually be used against you, and roughly when. Severity scores describe theoretical impact in a vacuum: a critical-rated flaw in an unreachable internal component is less urgent than a medium-rated authentication bypass on an internet-facing edge appliance with a reliable public exploit. Vulnerability intelligence supplies the exploitation evidence and exposure context that turn an unmanageable backlog into a defensible, ordered remediation plan.

What analysts actually look for

These are the concrete, observable signals that carry weight in this area of work:

CVE records with affected version ranges, weakness class and patch availability, plus the gap between disclosure and vendor fix
Public proof-of-concept and weaponised exploit availability, with assessed reliability and the preconditions for successful exploitation
Confirmed exploitation in the wild, dated, with the campaign or actor associated and the specific products being targeted
Honeypot and scan telemetry showing attempt volume, source infrastructure and elapsed time from disclosure to mass scanning
Vendor patch and commit analysis exposing silently fixed issues and the actual code change, enabling detection and variant hunting
Exposure correlation showing which of your internet-facing assets run the affected version and configuration right now
Compensating control coverage, meaning whether segmentation, configuration or filtering meaningfully reduces practical exploitability
Adoption by ransomware affiliates and access brokers, the single strongest predictor of imminent mass exploitation

Where the data comes from

Authoritative and openly available collection points. Always confirm licensing and terms before operational or commercial use:

NIST NVD — Canonical CVE records with product mappings, severity scoring, weakness classification and reference links
CISA Known Exploited Vulnerabilities catalogue — Authoritative list of flaws with confirmed in-the-wild exploitation and mandated remediation deadlines
EPSS (FIRST) — Empirical probability of exploitation within thirty days, far better than severity alone for ordering work
Exploit-DB and Metasploit modules — Public exploit availability and maturity, showing how reliably a flaw can actually be triggered
Vendor advisories — Microsoft MSRC, Cisco PSIRT and Oracle bulletins give authoritative affected-version and patch information
GitHub Security Advisories and OSV.dev — Dependency-level vulnerability data mapped precisely to package ecosystems and version ranges
Shadowserver and GreyNoise — Internet-wide scanning and exploitation telemetry showing what is actively being probed right now
MITRE CWE — Weakness taxonomy for spotting recurring classes and driving systemic fixes instead of per-issue patching

A working method

A repeatable sequence beats ad-hoc searching. This is a practical starting workflow:

Know what you run — Maintain an asset and software inventory with versions and bill-of-materials data. Prioritisation without inventory is guesswork dressed as process.
Ingest broadly, filter hard — Take advisories from national, vendor and ecosystem sources, then immediately discard everything with no match against your technology.
Score with evidence — Combine exploitation status, probability scoring, exposure and asset criticality. Use severity as one input, never as the ranking itself.
Confirm exposure — Verify with scan and attack-surface data whether the affected component is genuinely reachable and running the affected configuration.
Decide the response — Patch, mitigate, isolate or accept, each with a named owner and a date, recording compensating controls where patching is not viable.
Detect what you cannot fix — For unpatchable systems, build detections for the exploitation technique itself and monitor for attempt traffic against them.
Verify and retro-hunt — Confirm remediation actually landed, then hunt for evidence the flaw was exploited before the patch was applied.

How this connects across the intelligence taxonomy

Intelligence work does not respect neat boundaries. The mission domain you are working, the disciplines you practise, and the data points you pivot on are one connected system. These are the direct relationships for this entry — every link is also a tag, so you can follow any thread across the whole library.

Applied in these mission domains

Operates on these data points

IP Address — Internet Protocol address identifying a device or server on a network.
Malware Family — A named class of related malicious software.
Domain Name — Human-readable address that maps to IP infrastructure via DNS.
File Hash — Cryptographic fingerprint of a file, used for malware identification.
Detection Signature — A YARA/Sigma/Snort rule encoding detection logic for a malware family or behavior.
CVE / Vulnerability — Common Vulnerabilities and Exposures identifier for a known flaw.
Event / Incident — A discrete real-world occurrence — protest, strike, breach, seizure — with time, place, and actors.
TLS / JA3 Fingerprint — A hash of TLS client-hello parameters used to fingerprint clients, malware, and C2 frameworks.
SSL/TLS Certificate — A digital certificate binding a public key to an identity.

Related disciplines

Attack Surface Intelligence — Your Own Exposed Attack Surface
Breach Intelligence — Exposed Credentials and Compromised Data
Certificate Intelligence — TLS Certificates and Certificate Transparency
Cyber Intelligence — Adversary Activity in Networks and Systems
Dark Web Intelligence — Hidden Services and Closed Criminal Venues
Domain Intelligence — Domains, DNS, and Registration Intelligence

Inside the platform: where Vulnerability Intelligence lives

The Quantus platform is 204 pages behind a 147-item sidebar organised into six working groups: Command (24 items), Dashboards (15), Threat Theaters (14), Intelligence Domains (15), Investigate (34), and Administration (45). This entry is not a page in isolation — it is a thread running through several of them.

The modules that matter most here:

discipline.php?d=VULNINT — Discipline hub
source-catalog.php?disc=VULNINT — Source catalogue filtered to this discipline
ip-profile.php — IP Address profile
hash-profile.php — Malware Family profile
url-profile.php — Domain Name profile
search.php — Advanced search, filter and pivot
correlate.php — Correlation graph
cases.php — Case management

Each dashboard is local-first: it renders from the platform’s own database rather than depending on a live third-party call, so it still works when an upstream API is unreachable or rate-limited. Heavy aggregates are cached with a hard query time cap and degrade to the last good value instead of hanging the page.

Automation, playbooks and AI skills

Analysis that only happens when someone remembers to run it is not a capability. The platform ships a 30-step automation pipeline (cron.php) that collects, ingests, resolves, enriches, correlates and scores on a schedule — 25 seeders, 11 resolvers and 7 enrichment runners, all idempotent and cursor-based so a run can be interrupted and resumed without duplicating or losing work.

AI skills that apply

The 16 one-click operations in ai-skills.php are deterministic jobs, not free-text generation. The ones that matter here:

Correlate Infrastructure
DNS Audit
Threat Hunt
Detection Rules
Enrichment Runner
Summarise (Copilot)
Generate Report

Alerting closes the loop: rules in alerts.php fire on new indicators matching a saved query, so a first sighting in this area raises a notification rather than waiting to be noticed at the next review.

Feeds, data sources and the API

The collection layer runs a feed registry of free, machine-readable sources — bulk blocklists and trackers (Maltrail, IPsum, FireHOL, the full abuse.ch corpora, phishing databases, Emerging Threats, Spamhaus, DigitalSide, ThreatView), authoritative government feeds (CISA KEV, OFAC, UN and EU sanctions lists), and reference datasets (RIR allocations, ip-to-ASN and geolocation tables, MITRE ATT&CK, EPSS). collect.php pulls them server-side on a schedule; feeds.php and source-catalog.php show what is registered, what it covers and when it last ran.

Anything the platform holds is reachable programmatically. The REST API in api.php exposes 11 endpoints — status, stats, search, lookup, recent, export, bulk_check, top_threats, by_category, categories, check — and export.php streams 18 formats in bounded chunks, so a million-row export neither exhausts memory nor times out:

STIX 2.1, MISP, OpenIOC 1.1, CEF (ArcSight), LEEF 2.0 (QRadar), Zeek/Bro intel, Snort/Suricata rules, Palo Alto EDL, BIND RPZ, hosts blackhole, iptables, CSV, JSON, NDJSON/JSONL, XML.

That covers the CTI standards (STIX 2.1, MISP, OpenIOC), SIEM ingestion (CEF, LEEF, Zeek), detection engines (Snort/Suricata), and direct enforcement (Palo Alto EDL, BIND RPZ, hosts, iptables) — so intelligence developed here can be actioned in the tools you already run, without a manual reformatting step. A TAXII 2.1 server and a MISP/RSS feed are also served for pull-based sharing.

Use cases

Three ways this entry earns its keep in day-to-day work:

Triage under time pressure. An artifact or report lands and you need a defensible read in minutes, not days. Know what you run is the first move; the platform pre-computes the enrichment so the analyst spends the time on judgement rather than lookups.
Building the picture. A single indicator is rarely the story. Score with evidence turns one artifact into a network — shared infrastructure, repeated selectors, the same operator behind different names — via the correlation graph and the cross-entity link engine.
Producing something actionable. Analysis that ends in a document nobody can use is wasted. Verify and retro-hunt feeds the case file, the detection rule, the block list or the referral — with sourcing attached so the recipient can verify it.

Case management (cases.php), watchlists, saved searches and scheduled reports mean the work persists between sessions and survives an analyst leaving the team.

How each sector uses Vulnerability Intelligence

The same entry is worked very differently depending on who you are, what authority you hold, and what you are ultimately producing. A military analyst is supporting a commander’s decision; a journalist is meeting a publication standard; an NGO caseworker is protecting a person. The underlying artifacts are shared — the constraints, outputs and thresholds are not.

🎖 Military and defence

Defence practitioners run vulnerability intelligence to protect mission systems and to assess adversary exposure within lawful bounds. The defensive function prioritises remediation across weapons platforms, command systems and enterprise infrastructure using exploitation evidence rather than severity scores, and feeds risk acceptance decisions where a system cannot be patched without affecting readiness. Products support accreditation, maintenance planning and force protection. Constraint: exploit development and offensive use sit under a wholly separate legal and command authority, and any testing against operational systems requires written authorisation with a defined scope, a window and rollback arrangements agreed with the system owner beforehand.

🕵 National intelligence

National services use vulnerability intelligence for warning and for capability assessment: which weaknesses are being exploited, by whom, against which sectors, and what that implies for national infrastructure. The distinctive work is fusing public advisory and exploitation data with sensitive reporting on adversary tooling and with telemetry from partners, producing warning earlier than public catalogues. There is also a policy dimension in equities decisions about disclosure. Handling separates the technical detail, which is normally releasable and is most useful when released fast, from the source of exploitation knowledge, which is not. Products are written to enable defenders without disclosing collection.

👮 Law enforcement

Investigators use vulnerability intelligence to understand how an intrusion occurred, which supports both the offence and the loss assessment, and to establish whether a victim organisation could reasonably have prevented it. Establishing that a specific vulnerability was exploited requires forensic evidence from the victim system, not inference from the presence of an unpatched product. Any testing of a live system during investigation requires authority and must be conducted so it does not alter evidence. Where a supplier is investigated for negligence or for misleading claims, advisory timelines, patch availability dates and disclosure records become documentary evidence.

🔍 Private investigation and corporate security

Corporate practitioners run vulnerability intelligence as the prioritisation layer above scanning: deciding which of many thousands of findings are addressed this week. The authority is ownership of the estate, and the discipline is matching exploitation evidence against your actual exposure rather than remediating by score. Exploit code may only be run against systems you own or are authorised in writing to test, with scope, timing, rollback and a named approver, and never against a supplier or customer system without a signed authorisation. Output drives patch prioritisation, compensating controls, exception management and executive reporting on residual risk.

📰 Journalism and OSINT media

Journalists report on vulnerabilities in the context of breaches, product safety and vendor accountability. Verification requires distinguishing a theoretical weakness from one being exploited, checking whether a patch existed and when, and confirming exploitation claims with an independent researcher rather than relying on a vendor or a finder with an incentive. Do not publish working exploit detail. Coordinate timing with the vendor and any coordinating body where publication before a fix would put users at risk, and give the vendor a specific right of reply on the timeline, which is usually the contested part of the story.

🌍 NGO, humanitarian and human rights

Civil society technical support organisations use vulnerability intelligence to protect high-risk users and to advocate for accountability where products endanger them. The operational side is triage for organisations with minimal capacity, translating a large advisory stream into the few actions that matter for their actual systems. The advocacy side documents vendor behaviour, patch availability in older devices still used by at-risk communities, and the export of exploitation capability. Do-no-harm applies to disclosure timing, because publishing a weakness in a tool used by activists without a fix available can expose exactly the people the work protects.

🎓 University and research

Researchers study vulnerability discovery, disclosure economics, exploitation prediction and patch adoption. Methodology must address the well-known biases in the data: advisory records are inconsistent, affected version ranges are frequently wrong, and exploitation observation depends on sensor placement. Reproducibility requires publishing the dataset snapshot and matching logic, since records are amended retrospectively. Ethics approval and institutional legal review are required for any work involving live systems, and coordinated disclosure is expected for anything discovered, with publication timed to give vendors and users a reasonable window. Never publish weaponised proof of concept as part of a paper.

Playbook: working Vulnerability Intelligence end to end

A repeatable sequence, from the moment the requirement lands to the moment a product is delivered and the case is closed out. Each phase states what you are trying to establish, not merely what to click — the point is a defensible chain of reasoning, not a checklist.

Phase 1 — Establish the asset context first

Vulnerability intelligence is meaningless without knowing what you run. Establish the software inventory including versions, the exposure state of each asset, the business criticality and the data it holds, and the compensating controls already in place. A prioritisation exercise against an inventory that omits a third of the estate prioritises the wrong things confidently. Where inventory is incomplete, that gap is the first finding. A good output is an asset and software inventory with exposure and criticality attributes. Stop when the coverage is quantified rather than assumed, and the gaps are on the risk register.

Phase 2 — Build the advisory intake

Ingest the relevant streams: national vulnerability records, vendor advisories for the products you actually run, ecosystem-specific package advisories, and coordinating body alerts. Filter at intake by whether the product exists in your inventory, because unfiltered intake produces volume that guarantees the important item is missed. Capture affected version ranges and patch availability dates. A good output is a filtered intake feeding a queue sized to your remediation capacity. Stop when every product with material exposure has an advisory source and nothing else is being ingested.

Phase 3 — Match vulnerabilities to your estate accurately

Determine which advisories actually apply, which is harder than it appears: affected version ranges in advisory data are frequently wrong or incomplete, vendor backporting means a version string can be misleading, and containerised and embedded software is often invisible to conventional scanning. Use software bills of materials and package-level data where available. A good output is a matched exposure list with a confidence per match and the basis recorded. Stop when the false match rate is low enough that engineering teams trust the list, because a list they distrust will be ignored.

Phase 4 — Assess exploitation status

Establish for each candidate whether exploitation is theoretical, whether proof of concept code is public, whether it is in exploit kits or ransomware tooling, and whether it is being exploited in the wild against organisations like yours. This is the single most important prioritisation input and it changes daily. Use authoritative exploited catalogues, exploit prediction scoring and honeypot and scan telemetry. A good output is an exploitation status per vulnerability with a source and a date. Stop when the top of the queue is ordered by exploitation reality rather than by score.

Phase 5 — Prioritise on exposure and consequence

Combine exploitation status with your own context: is the affected asset internet-facing, what privilege does exploitation grant, what data or control does the asset hold, and what compensating controls exist. A critical scoring vulnerability on an isolated internal system with no exploit is a lower priority than a moderate one being exploited against your internet-facing estate. Set remediation timescales by tier in advance so each item is not renegotiated. A good output is a ranked remediation queue with agreed deadlines. Stop when the ranking is defensible to both engineering and the risk owner.

Phase 6 — Authorise any testing formally

Where exploitability must be confirmed by testing, obtain written authorisation before any exploit is executed. The authorisation names the systems in scope, the time window, the specific activity permitted, the approver, the rollback plan and the contact if something breaks. Test in a representative environment rather than production wherever possible. Never run exploit code against a supplier, customer or third party system without their own signed authorisation. A good output is a signed authorisation and a test plan. Stop and escalate rather than proceeding if the authorisation does not cover what you intend to do.

Phase 7 — Verify exploitability safely

Where testing is authorised, confirm exploitability with the least intrusive method that answers the question: version and configuration checks first, then a non-destructive proof that the condition exists, and only then a full exploitation attempt if it is genuinely necessary. Record everything: the tooling, the version, the target, the timestamps and the result. Restore state afterwards and confirm the system is healthy. A good output is a documented exploitability finding with the evidence and the restoration confirmed. Stop at the least intrusive step that resolves the question.

Phase 8 — Deploy mitigations, not only patches

Where patching is slow or impossible, apply compensating controls deliberately: network restriction, disabling the affected feature, virtual patching at a proxy or firewall, configuration hardening, credential and privilege reduction, and enhanced monitoring for exploitation attempts. Record each as a temporary control with an owner and a review date so it is not forgotten and quietly removed. A good output is a mitigation record tied to the specific vulnerability and asset. Stop when the exploitation path is broken, verified by testing where authorised, rather than when a control is nominally in place.

Phase 9 — Detect exploitation attempts

Build detection for attempted exploitation of the vulnerabilities that matter most, using network signatures, application logs, host behavioural detection for post-exploitation activity, and honeypot or canary assets. Detection matters because remediation always lags, and knowing whether you are being attacked through a specific path changes the urgency completely. Test detections before relying on them. A good output is detection coverage for the highest-priority exposures with measured false positive rates. Stop when each unremediated high-priority exposure has either a detection or a documented gap.

Phase 10 — Verify remediation

Confirm closure by re-testing rather than by accepting a status update or a scanner result alone, since patch deployment frequently fails silently, requires a restart that never happened, or is reverted by configuration management. Track reopen rates. Where risk is accepted rather than remediated, record a named accepter, the rationale, the compensating controls and an expiry date. A good output is a verified closure rate rather than a remediation percentage. Stop pursuing an item only when re-testing confirms the exposure is gone or a time-limited acceptance exists.

Phase 11 — Handle vulnerabilities you discover

Where your own testing or research finds a previously unknown vulnerability in a third party product, follow coordinated disclosure: report to the vendor or their published disclosure channel with enough detail to reproduce, agree a timeline, and involve a coordinating body if the vendor is unresponsive or the impact is broad. Do not publish working exploit code, do not sell it, and do not test the finding against other organisations systems. A good output is a reported finding with an agreed timeline and a tracked fix. Stop when the fix is released or the agreed disclosure deadline is reached.

Phase 12 — Measure and tune the programme

Track outcome measures: time to remediate for exploited vulnerabilities specifically, coverage of the estate by scanning and inventory, the proportion of exploited-in-the-wild items remediated within the agreed window, and recurrence of the same exposure. Review incidents to see whether the exploited weakness had been identified and deprioritised, which is the most useful feedback the programme generates. A good output is a periodic review producing specific changes to prioritisation logic. Stop the cycle only when the metrics show exploited vulnerabilities are consistently closed within the window.

The platform ships this as a step-checked workflow in playbooks.php, so progress is recorded against a case rather than held in someone’s head.

Source register: what to collect from, and how

Sources are listed with their access model so you can plan around cost and licensing before you build a dependency on them. Open means no account required; registration means a free account or API key; licensed means paid or institutional access. Always confirm current terms — licensing changes, and a source that was free for research may not be free for commercial or evidential use.

Source	Access	What it gives you	How it is used here
CISA Known Exploited Vulnerabilities catalog	Open	Authoritative catalogue of vulnerabilities with confirmed exploitation in the wild, with remediation due dates for federal agencies.	The single highest-value prioritisation input, since it lists what is actually being exploited rather than what scores highly.
NVD	Open	United States national vulnerability database providing enriched records with severity scoring, affected product data and references.	Baseline record for each vulnerability with scoring and product matching data, used with awareness of enrichment lag.
CVE Program	Open	The identifier assignment programme and record repository defining the canonical vulnerability identifiers and their descriptions.	Authoritative source of the identifier and its original description before downstream enrichment adds errors.
EPSS from FIRST	Open	Exploit prediction scoring system estimating the probability that a vulnerability will be exploited in the near term.	Probabilistic prioritisation for the large majority of vulnerabilities that are not yet in an exploited catalogue.
OSV.dev	Open	Open vulnerability database for software packages with precise machine-readable affected version ranges across ecosystems.	Accurate package-level matching for dependencies, where general vulnerability records are frequently wrong.
GitHub Advisory Database	Open	Curated advisories for open source packages with ecosystem-specific version ranges and remediation guidance.	Dependency vulnerability matching integrated with development workflows and software composition analysis.
CISA advisories and alerts	Open	Government advisories covering active exploitation campaigns, industrial control systems and prescribed mitigations.	Authoritative early warning and mitigation guidance, particularly for operational technology and edge devices.
NCSC United Kingdom	Open	National technical authority publishing vulnerability guidance, alerts and prioritisation advice for organisations.	Sector-relevant alerting and the national reporting route for United Kingdom organisations.
GreyNoise	Registration	Classification of internet-wide scanning and exploitation traffic, distinguishing mass exploitation from targeted activity.	Direct observation of whether a vulnerability is being actively scanned for or exploited across the internet now.
Shadowserver	Registration	Non-profit scanning and reporting operation delivering daily exposure and exploitation reports to network owners.	Independent notification of exposed and vulnerable assets within your own address space.
Zero Day Initiative	Open	Coordinated disclosure programme publishing advisories, upcoming disclosure timelines and vendor response records.	Early visibility of vulnerabilities in disclosure and a record of vendor responsiveness for supplier assessment.
Exploit Database	Open	Archive of publicly available proof of concept and exploit code with references to the associated vulnerabilities.	Establishes whether working public exploit code exists, which materially changes prioritisation.
MITRE CWE	Open	Catalogue of software and hardware weakness types with relationships, mitigations and detection methods.	Classifies root causes so systemic weaknesses can be addressed rather than patched one instance at a time.
MITRE ATT&CK	Open	Adversary technique knowledge base including exploitation techniques and the post-exploitation behaviour that follows.	Connects an exploited vulnerability to the behaviour a defender should hunt for after successful exploitation.
FIRST CVSS	Open	Common vulnerability scoring system specification defining base, threat and environmental metric groups.	Provides the scoring framework, used correctly by applying environmental metrics rather than relying on the base score.

Prefer sources that publish a methodology and a revision history. A dataset that changes silently is a liability in any product that has to survive challenge.

Tooling

Tools commonly used against Vulnerability Intelligence. None of these replace judgement, and each carries its own failure modes — know what a tool infers versus what it observes.

Authenticated vulnerability scanners — Enumerate installed software and configuration to identify exposure accurately. Limitation: coverage gaps on appliances, embedded systems and unmanaged assets are where the risk concentrates.
Software composition analysis — Identify vulnerable dependencies in applications from manifests and build artefacts. Limitation: transitive and vendored dependencies are frequently missed entirely.
Software bill of materials tooling — Produce and consume component inventories for accurate matching against advisories. Limitation: quality depends on generation at build time, and supplier-provided documents are often incomplete.
Vulnerability management platforms — Aggregate findings, apply prioritisation logic and track remediation with ownership. Limitation: default prioritisation by base score produces the wrong queue without threat context.
Exploit frameworks used under authorisation — Confirm exploitability where testing is formally authorised and scoped. Limitation: destructive by nature and unlawful without written authorisation naming the systems.
Virtual patching at proxies and firewalls — Block exploitation paths where patching is delayed or impossible. Limitation: signature-based blocking is bypassable and creates false confidence.
Canary and honeypot assets — Detect exploitation attempts against specific vulnerable technologies in your environment. Limitation: only sees attackers who reach them, so coverage placement matters more than count.
Patch and configuration management systems — Deploy fixes at scale and report deployment state. Limitation: reported success frequently overstates reality where restarts or reverts are involved.
Exploitation telemetry services — Show whether a vulnerability is being actively exploited across the internet right now. Limitation: sensor placement biases what is observed toward mass exploitation.

AI skills and automation in detail

These are deterministic jobs with defined inputs and outputs, not open-ended prompting. Each is idempotent and cursor-based: interrupt one and it resumes where it stopped rather than duplicating work or losing progress.

Correlate Infrastructure — Builds the cross-entity link graph: shared hosting, reused certificates, overlapping registrants, repeated selectors.
DNS Audit — Bulk-resolves A/AAAA/MX/NS/TXT/CNAME/SOA records and stores them as observations, building passive DNS from your own collection.
Threat Hunt — Runs saved hypotheses against the corpus and surfaces what matches, with the query preserved as a versioned artifact.
Detection Rules — Generates YARA, Sigma and Snort/Suricata logic from the selected indicators, ready to deploy.
Enrichment Runner — Walks the indicator set through a chosen provider in time-boxed, cursor-based batches that resume rather than restart.
Summarise (Copilot) — Produces a narrative summary beside the underlying records. It explains; it never creates indicators or assigns attribution.
Generate Report — Assembles a sourced product from the current case or query, with provenance attached to each element.

A note on the boundary: the only skill that involves a language model is Summarise (Copilot), and it writes prose about records that already exist. Nothing else on this list involves generation of any kind. No indicator, relationship or attribution in the platform originates from a model. See the full skill list.

Tradecraft notes

The distinctions that separate a competent analyst from a fast one:

Prioritise on exploitation evidence, not severity score. A moderate-scoring vulnerability being exploited against internet-facing systems today outranks a critical one with no exploit, and programmes that remediate by score reliably patch the wrong things first.
Affected version data is frequently wrong. Backporting means a version string does not tell you whether the fix is present, so matching by version alone produces both false exposure and, more dangerously, false assurance.
Never run exploit code without written authorisation naming the systems, the window and the approver. Verbal permission from a system owner is not authorisation, and the person who runs the exploit carries the consequences.
The most useful review question after an incident is whether the exploited vulnerability was known and deprioritised. That answer tells you more about the prioritisation logic than any coverage metric will.
Verify remediation by re-testing rather than by deployment reports. Patches fail to apply, require restarts that never happen, and get reverted by configuration management, and the status dashboard will show green throughout.
Treat compensating controls as time-limited items with owners and review dates. Undocumented temporary mitigations become permanent, then get removed during unrelated work by someone who does not know why they existed.
Detection matters because remediation always lags. For the exposures you cannot close quickly, knowing whether the specific exploitation path is being attempted against you changes the decision entirely.
Where you discover a vulnerability yourself, use coordinated disclosure and never test it against another organisation systems. Verifying that a third party is also vulnerable is unauthorised access, however helpful the intention.

Measuring whether it is working

Capability claims should be falsifiable. These are the measures that show whether work on Vulnerability Intelligence is producing anything, and they are worth baselining before you change process or tooling.

Median time to remediate vulnerabilities with confirmed exploitation in the wild, measured separately from all other vulnerabilities.
Proportion of known exploited vulnerabilities closed within the agreed window, and the number past their deadline with a named owner.
Estate coverage by authenticated scanning and by software inventory, with the uncovered proportion explicitly quantified.
Reopen rate on remediations verified by re-testing, which measures whether deployment reporting reflects reality.
Proportion of incidents where the exploited vulnerability had been identified and deprioritised, reviewed for prioritisation logic failure.
Number of compensating controls past their review date, which indicates whether temporary mitigations are being managed.
Count of exploit executions conducted without a written authorisation, which should be zero and is a control failure rather than a performance measure.

Beware of measuring volume alone. Indicator counts and report counts rise easily and say little; time-to-attribution, proportion of findings that survive review, and how often a product changed a decision say a great deal.

Common pitfalls

Ranking by severity score alone, which correlates poorly with real exploitation and buries the flaws being used today
Trusting affected-version data uncritically, since product mappings are frequently incomplete or wrong for less common software
Deprioritising appliances and edge devices because they sit outside the patch pipeline, which is exactly why they are targeted
Patching without hunting, when a remediated internet-facing flaw may already have been exploited weeks earlier
Treating a published proof of concept as a working exploit, or its absence as safety, when private exploitation often comes first
Losing dependency vulnerabilities inside transitive package trees that never surface in host-level scanning

Legal and ethical considerations

Analysis of advisories, exploit code and telemetry is lawful, but running an exploit requires authorisation: testing against production or third-party systems without written permission breaches computer-misuse law regardless of intent. Some jurisdictions restrict distribution of exploit tooling, so proof-of-concept code needs access control. Respect coordinated disclosure obligations and embargoes, because premature publication creates liability and real harm. Where a vulnerability affects customers, contractual and regulatory notification duties may apply, and remediation records should be retained as evidence of due diligence.

Data integrity: no fabrication, no drift, no hallucination

Intelligence that cannot be traced back to a source is not intelligence, it is assertion. Everything in this entry — and everything in the platform behind it — is built on a small number of non-negotiable rules.

Provenance on every record

Every indicator carries the source that supplied it, a first-seen and last-seen timestamp, and a sighting count. Where several feeds report the same artifact, each contribution is recorded separately rather than collapsed, so you can see whether a finding rests on one source or twelve. Source attribution travels with the data into every export, so a recipient can audit a claim without asking you for the working.

Nothing is invented to fill a gap

If the platform has no data for Vulnerability Intelligence, it says so. Empty is displayed as empty — never padded with plausible-looking placeholder values, sample records or illustrative examples that a reader might mistake for observations. A dashboard with no rows is a true statement about collection coverage, and it is treated as a gap to close, not a blemish to hide.

Scoring is deterministic and reproducible

Threat scores, reputation grades and risk tiers are computed from stated inputs with fixed weights, not estimated. The same inputs always produce the same output, and the formula is visible rather than a black box. Aggregates are cached with an explicit time-to-live so a figure on screen is never silently stale — and when a heavy query exceeds its time budget the platform serves the last known-good value and labels it, rather than inventing a fresh number or hanging.

Where AI is used, and where it is not

Language models summarise and explain. They do not create indicators, assign attribution or manufacture relationships. No IP address, wallet, hash or identity in the platform originates from a model — every one is ingested from a named feed, resolved from a reference dataset, or entered by an analyst with a source recorded. Copilot output is presented as narrative alongside the underlying records, never in place of them, so a reader can always check the summary against the evidence.

Guarding against drift

Enrichment is additive and timestamped rather than overwriting. Reference data — sanctions lists, allocations, taxonomies — is re-synchronised from the authority on a schedule instead of being edited in place, so local copies cannot quietly diverge from the source of truth. Attribution is recorded with a confidence level and the reporting it rests on, and inferred relationships are labelled as inferred. When a source retracts or corrects, the correction propagates rather than leaving a stale assertion behind.

What this means for you

You can put a finding from this platform in front of a regulator, a court, a board or a partner agency and show where each element came from. That is the standard the tooling is built to — because in this work, being confidently wrong is more damaging than being usefully uncertain.

By the numbers

The taxonomy this entry belongs to is not a marketing list — it is the actual structure of the platform: 52 mission domains, 52 intelligence disciplines and 65 data points, each with a live dashboard behind it. Supporting that: 18 indicator types, 14 playbooks, 16 AI skills, 18 export formats and a 30-step automated pipeline.

This particular entry connects directly to 9 data points, 5 mission domains, 6 closely related entries — every one of them a tag you can follow, and a dashboard you can open.

Questions analysts actually ask

Should we prioritise by CVSS?

Not by the base score alone, which is the most common failure in the discipline. The base score describes intrinsic characteristics and says nothing about whether anyone is exploiting it or whether the affected asset matters to you. Use exploitation evidence first, from an authoritative exploited catalogue and from exploitation telemetry, then exploit prediction scoring for the remainder, then your own environmental context including internet exposure, privilege granted and data held. If you use the scoring framework, apply the environmental and threat metric groups properly rather than quoting the base score, which is what the specification actually intends.

How do I handle a vulnerability with no patch available?

Treat mitigation as the primary response rather than waiting. Restrict network reachability to the affected service, disable the vulnerable feature or component where the business can tolerate it, apply blocking at a proxy or firewall, reduce the privilege the service runs with, and increase monitoring specifically for the exploitation path. Record each control with an owner and a review date so it is revisited when a patch appears. Escalate to the vendor and, where the impact is broad, to the national CERT. Where nothing can be done, document the accepted risk with a named accepter and an expiry.

When may I run exploit code?

Only against systems you own or have written authorisation to test, with a defined scope, a time window, an approver, a rollback plan and an emergency contact. Verbal agreement from a colleague is not authorisation. Never run exploit code against a supplier, customer or partner system without their own signed authorisation, even to demonstrate a risk to them, because doing so engages computer misuse offences regardless of intent. Prefer non-destructive verification of the vulnerable condition over full exploitation, and prefer a representative test environment over production wherever the question can be answered there.

How do I deal with wrong affected version data?

Verify rather than trust. Distribution vendors backport security fixes without changing the version string, so a version-based match generates both false positives and, more seriously, false negatives where you believe you are patched. Use package-level databases with precise ranges for dependencies, check vendor security advisories directly for the products that matter most, and where the stakes justify it verify the presence of the fix rather than the version. Record the basis of each match so engineering teams can see why an item was raised, since unexplained false positives destroy the credibility of the whole queue.

What is the right remediation timescale?

Set it by tier in advance and by exploitation status rather than negotiating each item. A workable structure is days for confirmed exploited vulnerabilities on internet-facing assets, a small number of weeks for high-probability items and exploited vulnerabilities on internal assets, and the routine patching cycle for everything else. Agree the tiers with the risk owner and with engineering before you need them, publish them, and measure against them. The specific numbers matter less than having them agreed in advance, because the alternative is a fresh argument about urgency during every serious event.

Are software bills of materials worth the effort?

Yes for anything you build, and increasingly for what you buy. They are the only reliable route to answering the question that matters during a widespread dependency incident, which is whether a specific component is present anywhere in your estate. Without one, that question takes days to answer badly. The caveats are real: generation must happen at build time to be accurate, supplier-provided documents are often incomplete, and a document that is not ingested into a matching process is just a file. Treat it as an input to automated matching, not as a compliance artefact.

What do I do if I discover a vulnerability in a vendor product?

Follow coordinated disclosure. Report to the vendor security contact or their published disclosure channel with sufficient detail to reproduce, propose a disclosure timeline, and keep a record of the correspondence. If the vendor is unresponsive or disputes a clear issue, escalate to a coordinating body such as a national CERT, which will broker the process. Do not publish working exploit code, do not sell the finding, and do not test it against any other organisation systems to see how widespread it is. If you publish at the end of the agreed period, publish enough for defenders and no more.

Standards, frameworks and further reading

Work that references a recognised framework is easier to defend, easier to hand over, and easier for a partner to consume:

ISO/IEC 29147 on vulnerability disclosure, which governs how findings are reported to vendors and coordinating bodies.
ISO/IEC 30111 on vulnerability handling processes, which governs how a vendor should triage, remediate and communicate about reported issues.
CVSS version 4.0 published by FIRST, which governs the scoring framework including the threat and environmental metric groups.
EPSS published by FIRST, which governs probabilistic estimation of near-term exploitation likelihood.
CISA Binding Operational Directive 22-01, which governs remediation deadlines for known exploited vulnerabilities on federal systems and sets a widely adopted benchmark.
NIST SP 800-115 on technical security testing, which governs planning, authorisation and conduct of exploitability testing.
The UK Computer Misuse Act 1990 and equivalent legislation, which govern why unauthorised exploitation of any third party system is unlawful.
The EU Cyber Resilience Act and equivalent product security regimes, which govern vendor obligations to handle and disclose vulnerabilities in products.

References

Primary sources and authoritative references for this entry. Publishers revise and retire material, so treat the retrieval date as part of the citation and re-check before relying on any of it in a formal product.

Known Exploited Vulnerabilities catalog — Cybersecurity and Infrastructure Security Agency. Authoritative catalogue of vulnerabilities confirmed exploited in the wild
National Vulnerability Database — National Institute of Standards and Technology. Enriched vulnerability records with scoring and product matching data
CVE Program records — CVE Program. Canonical vulnerability identifiers and original descriptions
Exploit Prediction Scoring System — FIRST. Probabilistic model of near-term exploitation likelihood
Open Source Vulnerabilities database — OSV.dev. Package-level vulnerability data with precise affected version ranges
GitHub Advisory Database — GitHub. Curated open source package advisories with ecosystem version ranges
Common Weakness Enumeration — MITRE. Catalogue of weakness types used to address systemic root causes
Coordinated disclosure advisories — Zero Day Initiative. Published advisories and vendor response timelines from a major disclosure programme
Vulnerability management guidance — UK National Cyber Security Centre. National guidance on prioritisation and remediation practice
Internet exploitation telemetry — GreyNoise. Observed scanning and exploitation activity distinguishing mass from targeted behaviour

Link integrity: every reference above was verified with a live request when this page was generated. Where a publisher had moved or withdrawn a document, the link was repointed at a preserved copy in the Internet Archive and marked as archived. Anything with no reachable copy anywhere had its link removed rather than left to rot — the source is still credited, it simply cannot be linked.

Put it into practice

The Quantus Intel threat intelligence platform operationalises this entry: prioritises by exploitation evidence correlated against your live asset inventory and external exposure. Explore the platform, or browse the rest of the library by following any tag above.