Vulnerability scanners find problems. GLPI tracks assets and manages work. The gap between these two systems is where vulnerabilities go to be forgotten. A scanner reports 847 findings. Someone exports a spreadsheet. The spreadsheet gets emailed around. Three weeks later, nobody knows which findings were fixed, which were accepted as risk, and which were never looked at. GLPI can close this gap by serving as the central tracker for the full lifecycle: discovery, triage, remediation, verification.
What GLPI brings to vulnerability management
GLPI is not a scanner and should not pretend to be one. What it provides is the asset context that scanners lack and the workflow engine that spreadsheets lack. Every vulnerability finding needs to be connected to a specific device, assigned to a specific person, tracked through a specific process, and closed with evidence. GLPI already does all of this for incidents and service requests — the same mechanics apply to vulnerability remediation.
Storing vulnerability data with plugins
Additional Fields plugin
The Additional Fields plugin lets you add custom data fields to any GLPI object type. For vulnerability tracking, create a field block on Computer and NetworkEquipment with the following fields:
- CVE ID (text field)
- Severity (dropdown: Critical, High, Medium, Low)
- Scanner source (dropdown: Nessus, OpenVAS, Qualys, Manual)
- Discovery date (date field)
- Remediation deadline (date field)
- Status (dropdown: Open, In Progress, Mitigated, Accepted Risk, False Positive)
This approach embeds vulnerability data directly on the asset record. Anyone looking at a computer in GLPI can immediately see its vulnerability status.
Generic Object plugin
For more structured tracking, the Generic Object plugin lets you create an entirely new object type — for example, "Vulnerability Finding" — with its own fields, search criteria, and lifecycle. You can then link findings to assets using GLPI’s standard item linking. This is cleaner for organizations that track hundreds of findings and need dedicated reporting.
Integration with external scanners
The practical question is how vulnerability data gets from the scanner into GLPI. There are two main approaches.
CSV import
Most scanners export findings as CSV. GLPI’s Data Injection plugin can import CSV files and map columns to GLPI fields. Set up a mapping template once, and subsequent imports follow the same pattern. This works well for periodic scans — run the scan weekly, export CSV, import into GLPI.
API integration
For continuous scanning or larger environments, use the GLPI REST API to create findings programmatically. A middleware script reads the scanner’s API (Nessus and Qualys both have well-documented APIs; OpenVAS uses GMP protocol), matches findings to GLPI assets by IP or hostname, and creates or updates records via POST /apirest.php/Ticket or updates custom fields via PUT /apirest.php/Computer/{id}.
The matching step is critical. If the scanner reports a vulnerability on IP 10.0.1.45, the script needs to resolve that to the correct GLPI computer record. Match on IP address first, fall back to hostname, and flag anything that does not match — an unmatched finding means either a rogue device or an inventory gap, both of which need attention.
Creating remediation tickets automatically
The most effective workflow creates a GLPI ticket for every Critical or High finding automatically. The ticket includes the CVE ID, affected asset (linked via the Items tab), scanner output, and a remediation deadline based on severity (e.g., Critical = 72 hours, High = 2 weeks). GLPI’s business rules can auto-assign these tickets to the group responsible for the affected entity or location.
Medium and Low findings can be grouped — one ticket per scan cycle summarizing all medium findings, linked to the relevant assets. This prevents ticket flooding while still tracking remediation.
Measuring mean time to remediate
With vulnerability findings tracked as tickets, GLPI’s built-in statistics give you mean time to remediate (MTTR) for free. Filter tickets by the vulnerability category, and the Statistics module shows average resolution time by severity, by entity, by assigned group. This is the metric that security leadership cares about most, and it requires zero additional tooling when the data lives in GLPI.
You can also track trends: is MTTR improving quarter over quarter? Are certain teams consistently slower? Are specific asset types generating repeat findings? The data is already there — you just need to query it.
The complete loop
Scanner discovers a vulnerability. Finding is imported into GLPI and linked to the affected asset. A remediation ticket is created and assigned. The technician patches or mitigates, closes the ticket with a solution note. The next scan confirms the fix. The finding status is updated to Mitigated. The full lifecycle is documented with timestamps, responsible persons, and evidence — exactly what auditors expect to see.