Knowing that a CVE exists is useful. Knowing whether it affects your IBM i, which licensed program and option is involved, which PTF fixes it, whether that PTF is already installed, and being able to download the fix is much more useful.
That has always been the objective behind the CVE capabilities we provide with NG4i.
We have written about these capabilities before, but a major redesign of the database behind them gives us a good reason to revisit what NG4i can do — and where we are taking it next.
Why rebuild the CVE database?
Our IBM i CVE database has been growing since May 2022. It now contains 576 CVEs, including IBM announcements through September 2, 2026, together with the many PTFs associated with them.
The data currently spans IBM i V7R2 through V7R6 and tracks the IBM-supplied licensed programs (LPPs) and options affected by those vulnerabilities.
That sounds straightforward until you consider the relationships involved.
A single CVE may affect several IBM i releases. It may affect multiple licensed programs, several options within those programs, and require different PTFs depending on the release, product and option installed.
The original database served us well, but as the amount and complexity of the information increased it became increasingly difficult to maintain and, importantly, to validate.
Adding V7R6 also highlighted another problem. The original design was too closely tied to individual IBM i releases, meaning that supporting a new release required more manual database and application changes than it should.
So rather than continuing to extend the old structure, we redesigned it.
A database designed around the relationships
The new database separates the CVE itself from the products it affects and the PTFs that resolve it.
Conceptually, the structure is now:
CVE → LPP → LPP Option → OS/Product Version → PTF
This is much closer to the way the information actually needs to be understood on an IBM i system.
It also gives us considerably better data integrity. Instead of duplicating CVE information to represent different products, options or releases, we can maintain the CVE once and establish the relationships between it and the relevant fixes.
The result is a database that is easier to validate, easier to query and much easier to extend.
When another IBM i release arrives, we no longer want the database redesign exercise that accompanied V7R6. The new structure has been built with that future growth in mind.
We have also replaced much of the SQL scripting, copying and pasting previously required to maintain the information with a formal data-entry interface. That should make adding and checking new IBM security bulletin information considerably easier.
None of that is particularly exciting to an NG4i user by itself.
What it allows NG4i to do with the information is!
A CVE list isn’t the same as an answer
IBM provides its own CVE SQL service, which can be queried using:
SELECT * FROM TABLE (SYSTOOLS.CVE_INFO())
This provides useful information about known CVEs, but there is still work for the administrator to do.
Knowing that a CVE exists doesn’t necessarily tell you the complete remediation path for your system. You still need to establish which IBM i product and option is involved, identify the appropriate PTF, determine whether that product or option is actually installed on your partition and then establish whether the required fix is already present.
There are other practical considerations as well. The IBM service isn’t available on some earlier IBM i releases, and because information has to be retrieved from IBM, obtaining the data can take time.
Our objective with NG4i is different.
We want to take the vulnerability information and turn it into something an IBM i administrator can act upon.
Let NG4i do the matching
NG4i can use our CVE/PTF information together with knowledge of the licensed programs and options installed on the IBM i.
That means the administrator doesn’t have to manually work through every CVE and determine whether each associated product applies to the partition.
NG4i can identify the relevant fixes based on what is actually installed.
More importantly, once a required PTF has been identified, NG4i can automate the next step as well.
The required PTFs can be downloaded to either a *SAVF or an *IMGCLG with a single request.
So instead of a process that looks like:
Find CVE → research affected product → identify option → find PTF → check system → locate fix → download it
we can reduce much of that effort to:
Identify → Check → Download
That is where CVE information starts becoming operationally useful.
Reporting for auditing and remediation
Sometimes you don’t want automation; you want evidence.
NG4i can produce reports showing the CVEs, affected LPPs, LPP options and associated PTFs.
The information can be written to a traditional IBM i spool file or placed into a database file where it can be consumed by your own applications and processes.
This provides a useful record for security reviews, remediation exercises and internal reporting without requiring someone to manually assemble information from multiple sources.
Want the data? Have the JSON
The information isn’t locked inside an NG4i command or report either.
CVE information can also be returned in JSON format, providing a simple way for other applications, scripts and management platforms to consume it.
That opens up plenty of possibilities for customers wanting to incorporate IBM i vulnerability information into their own security dashboards, reporting systems or automation.
The redesign of the underlying database makes this capability even more useful because the relationships between CVEs, products, options, releases and PTFs are now explicitly maintained.
Start with a CVE and ask NG4i what you need
We’ve also added another useful way of looking at the problem.
Sometimes you aren’t interested in every outstanding vulnerability. A security team, auditor or customer may simply give you a CVE number and ask:
“Does this affect our IBM i, and have we fixed it?”
A new NG4i command allows you to provide a specific CVE ID and retrieve the PTFs associated with it.
NG4i can then compare those requirements with the system itself.
The resulting report can show that:
- the affected LPP and option are installed and the required PTF is missing;
- the required PTF is already installed; or
- the LPP option associated with the CVE isn’t installed on that IBM i.
That last point is important.
A list of hundreds of CVEs can look alarming, but a vulnerability associated with software that isn’t installed on your partition isn’t the same problem as an outstanding PTF for a product you are actively running.
Likewise, simply removing already-remediated CVEs from a report hides useful information. When investigating a specific CVE, being able to demonstrate that the corresponding fix is already installed provides a much more useful answer.
More than vulnerability reporting
We have deliberately concentrated our database on vulnerabilities affecting IBM-supplied LPPs and options rather than trying to reproduce every CVE that could conceivably be associated with an IBM i environment.
Products such as ACS, WebSphere and Merlin, for example, have not historically been maintained to the same level within this database.
The new structure gives us considerably more flexibility to expand that coverage where it provides value.
It also provides a stronger foundation for integrating CVE information with the other monitoring and automation capabilities available through NG4i and AAG.
For us, that’s the important part of this project.
The database redesign isn’t really about having a nicer database.
It’s about making the path from “there is a new IBM i vulnerability” to “we know whether it affects us and what we need to do about it” as short as possible.
IBM provides the vulnerability information via CVE notifications.
NG4i helps turn that information into action.
A recent CVE announcement resulted in hundreds or PTFs and lots of CVEs, using the tools provided by NG4i we successfully downloaded the PTFs and had them installed in a few hours (IBM downloads took most of that time) because all of the sorting and downloading was automated by the NG4i tools.
IMPORTANT NOTE:
A recent comment we received was saying that automating this process is unsafe, they failed to understand that we just download whats needed, the decision to what to install still rests with the system admin.
If you want to know more let us know, happy to demo the products and show just how cost effective keeping your system covered can be.