Security Exposure
Security Exposure answers which of your Java installations are behind on security updates, and what to move them to. It judges every installation seen in the last 30 days against the latest quarterly Critical Patch Update (CPU) and against the CISA Known Exploited Vulnerabilities (KEV) catalog, and it recommends the Azul build to move to. Both Admins and Members can read it.
The Vulnerability Dataset
Security Exposure works from a vulnerability dataset: a zip file that holds, for each Java major release, the build that every vendor train shipped for each recent CPU, the lifecycle of the release, and the known exploited vulnerabilities with the versions that fix them. Your installation gets the dataset in one of three ways:
-
An Admin uploads the zip under Settings > Vulnerability Data.
-
An Operator, or a scheduled job of yours, copies the zip into the folder named by
VULN_DATA_DIR. Your installation scans that folder hourly and activates the newest zip that passes its checks. -
An Operator sets
VULN_DATA_METADATA_URLto anhttpsaddress, and your installation checks it hourly and downloads a newer dataset. This is the only way in which Security Exposure makes an outbound connection, and it is off by default.
See Vulnerability Data for the Admin screen and Configuration Options for the variables.
Until a dataset is loaded, Security Exposure says that it needs vulnerability data instead of showing zeros. An Admin sees a Load vulnerability data button, and anybody else is told that an Admin loads it. When a dataset is loaded but no recognized installation was seen in the last 30 days, the screen says that there is nothing to check yet.
How an Installation Is Judged
-
An installation’s version is compared with the builds of its own vendor’s train.
-
An installation is current when its build is at or after the latest CPU. Missed CPUs counts the quarterly CPUs it has not taken, and the time without a patch runs from the first CPU after its level.
-
A Java major release that the dataset marks as unsupported or end of life is reported as end of life.
-
A known exploited vulnerability counts against a build only when the dataset states the version that fixes it and the build is below that version. A known exploited vulnerability without a stated fixed-in version is not counted, and is listed without the KEV mark.
-
An installation whose version could not be read, or whose release the dataset does not cover, is not assessed. The overview says how many were left out and why, beside the installation count.
-
The risk of a build follows the highest counted known exploited vulnerability: Critical from a CVSS score of 9, High from 7, Medium from 4. Without a counted vulnerability, risk follows the status: end of life is High, behind is Medium, and current is Low.
Reading the Screens
Each level is one screen with a breadcrumb back to the one above, and the filters travel in the address, so any screen can be bookmarked or sent to a colleague.
| Level | What it shows |
|---|---|
Overview |
The figures for the whole estate (installations, how many are behind, how many are exposed to a known exploited vulnerability, how many are end of life, and how many are current) and one row per Java major release, with its risk, vendors, and the build that sets the risk. Filter by vendor, tag, and risk. |
Java major release |
One row per installed build, with its risk, vendors, tags, installation count, months without a patch, missed CPUs, and the known exploited vulnerabilities counted against it. Filter by platform as well. Tick the builds you want to act on. |
Build |
What is wrong with that build and the Azul build that fixes it, or, for a build at the latest CPU with no counted known exploited vulnerability, that it is up to date. Also the vulnerabilities that affect it and where it is installed. See The Build Page. |
Recipe |
The ticked builds as a plan: what moves to what, and every installation to update. |
The Build Page
A build that is behind the latest CPU, or exposed to a known exploited vulnerability, states what is wrong and offers the Azul build that fixes it.
A build at the latest CPU with no counted known exploited vulnerability is stated as up to date, at that CPU. The Azul build is still shown as recommended, with the same way to a recipe, and the page says what the move means: a change of vendor rather than a security fix, because version numbers from different vendors' trains are not comparable. When the build is itself the recommended Azul build, the page says so instead of proposing a move.
A major release that has reached end of life has no recommended build. Its build pages say to migrate those installations to a supported major release.
The page lists the vulnerabilities that affect the build, 10 to a page, sortable by CVSS score and by publication date, with counts by severity above the table. Known-exploited only narrows the table and its counts to the known exploited vulnerabilities counted against the build. It is on by default, and your browser remembers your last choice for every build page. A vulnerability is marked KEV only when it is counted against the build, so the table never marks one that the build’s KEV count leaves out.
The Recipe
The recipe turns the builds you ticked into work somebody can be handed. It always moves them to Azul’s build: there is no option to stay on the current vendor, and builds from several vendors and platforms can go in one recipe. Choose whether to move to the build of the current CPU or of the previous one, and download the result in two forms:
-
Plain text: what moves to what, the known exploited vulnerabilities it fixes and how far behind each build is, and for each host the installations and the steps: confirm what uses it, install the Azul build, remove the old one, and re-scan. It contains no commands.
-
CSV: one row per installation of the chosen builds, with the Azul build it moves to, for up to 50,000 installations. Open it in a spreadsheet to sort and share.
A major release that has reached end of life has no patch to move to, so it has no recipe.
Keeping the Data Fresh
The dataset is built from the published CPU and KEV data, so its age is the age of Security Exposure’s view. Check the ljvmi_vuln_data_generated_timestamp_seconds metric, or the Vulnerability Data card, and load a newer dataset when it is more than a few weeks old. See Monitoring and Health for the ljvmi_vuln_data_* metrics.
The overview, the release and build figures, the vulnerabilities of a build, and the hosts of a build are also available to automation with an API token, and loading, checking, and rolling back the dataset with an Admin’s token. The recipe downloads are not, because they are files for a person to hand over. See The Integration API.