GLPI is not a vulnerability scanner. It does not run Nessus probes or OpenVAS checks. But it is the one place in your infrastructure that already knows what devices you have, what software runs on them, where they sit in the network, and who is responsible for them. That makes the CMDB the natural place to track vulnerability findings per asset — and the natural place to answer the question every CISO asks after a new CVE drops: "Which of our devices are affected?"
The problem with scanner-only workflows
Most vulnerability scanners produce reports. PDFs, CSVs, dashboards. The security team reviews them, creates tickets manually, and hopes the IT operations team picks them up. The disconnect between "we found a vulnerability" and "someone fixed it on this specific device" is where things fall apart.
Scanners know about vulnerabilities. GLPI knows about assets. Connecting the two closes the loop.
Setting up vulnerability tracking in GLPI
GLPI does not ship with a dedicated vulnerability tracking module, but you can build one using features already available.
Option 1: custom fields via the Additional Fields plugin
Install the Additional Fields plugin and create a field block on Computer (or NetworkEquipment, or any asset type). Add fields like CVE ID, severity (Critical / High / Medium / Low), discovery date, scanner source, and remediation status. This gives every asset a visible vulnerability history directly on its detail page.
Option 2: dedicated ticket category for vulnerabilities
Create a ticket category tree: Security > Vulnerability > [by severity]. When a scanner finds a critical issue, a ticket gets created under this category, linked to the affected asset via the "Items" tab. The ticket tracks remediation — assignment, progress, validation, closure.
Option 3: combine both
Use custom fields for the raw vulnerability data (what was found, when, by which scanner) and tickets for the remediation workflow (who is fixing it, what is the deadline, is it done). This separates the finding from the fix, which matters for audit trails.
The import workflow
The practical workflow looks like this:
- Scanner runs on schedule (Nessus, OpenVAS, Qualys — any tool that exports CSV or has an API).
- A script parses the scanner output and matches findings to GLPI assets by hostname, IP address, or serial number using the GLPI REST API.
- For each match, the script either updates the custom vulnerability fields on the asset or creates a ticket linked to that asset — or both.
- Tickets land in the queue of the responsible technician (GLPI can auto-assign based on entity, location, or asset group).
- Remediation gets tracked per asset. When the technician patches the system, they close the ticket and update the vulnerability status.
The GLPI REST API handles all of this. The endpoints for creating tickets (POST /apirest.php/Ticket) and updating assets (PUT /apirest.php/Computer/{id}) are well-documented and stable.
Answering "which devices are affected by CVE-X?"
With vulnerability data stored in GLPI, this becomes a search query. Filter assets by the CVE ID custom field, or search tickets by the CVE reference in the title. GLPI's saved searches let you bookmark these queries and share them with the security team.
You can also build reports: how many open critical vulnerabilities exist across the fleet, which entities have the highest counts, what is the average time from discovery to remediation. This is the kind of data that ISO 27001 auditors ask for and that NIS2 incident reporting requirements expect you to have ready.
What this gets you
The CMDB becomes the single source of truth for both asset inventory and security posture. Vulnerability findings are not trapped in scanner reports — they are linked to real assets with real owners. Remediation is tracked through the same ticketing system the IT team already uses, which means no new tools and no new workflows to learn.
GLPI will not replace your scanner. But it will make sure that what your scanner finds actually gets fixed, on the right device, by the right person, within a trackable timeline.