A Vendor Shipped 1,000+ Security Fixes. Which Do You Patch First?

Start with what you actually run, not with the advisory. Cut the release down to the products and versions in your inventory, then patch first anything that is known exploited (CISA KEV), reachable from the internet without authentication, or rated highly likely to be exploited by EPSS. Everything else goes into dated tiers, so a release with 1,000 fixes becomes a short list you can finish this week and a schedule for the rest.

That is the short answer. The long answer matters because the numbers really are that large now. Oracle's October 2026 Critical Patch Update, published on 20 October, carried 1,295 new security patches, according to SecurityWeek and endoflife.ai. Counts in coverage vary slightly depending on whether you count patches, unique CVEs or rows in the risk matrices, but every version of the number is far beyond what any team can treat as "patch everything now". This post walks through the filters in order, with commands, a decision table, deadline tiers you can adapt, and the evidence an auditor will want to see.

Key takeaways

• Your list is not the vendor's list. A quarterly release covers dozens of product families. Most organisations run a handful of them, in a few versions. Inventory is the first and biggest filter.
• Exploitation beats severity. A medium CVSS score on a KEV listed flaw outranks a critical score nobody is exploiting. CISA's binding directive BOD 26-04, issued 10 June 2026, now sets federal deadlines by exposure, KEV status, automation and technical impact rather than by CVSS alone.
• "Remote, no authentication" is the most useful column in the matrix. Combined with your own exposure data, it tells you which rows an attacker can reach without stealing a password first.
• EPSS and SSVC fill the gap before KEV. EPSS gives a daily probability of exploitation in the next 30 days. SSVC turns exploitation, exposure, automation and impact into a clear action: defer, scheduled, out of cycle or immediate.
• Many vendor fixes are open source libraries the vendor bundles. The same libraries are probably in your own code and containers, and you can fix those without waiting for anyone.
• Unsupported versions get no row at all. The vendor does not test them, so a missing row is not a clean result.
• Write the decision down. A short record per release, showing inputs, tier and deadline, is what turns triage into evidence.

Why vendor patch releases got so big

Large enterprise vendors bundle fixes on a schedule because their customers need predictable maintenance windows. Oracle publishes its quarterly Critical Patch Updates in January, April, July and October. Since May 2026 it has also published a smaller monthly release, the Critical Security Patch Update, in the months between. Help Net Security reported Oracle's description of each monthly release as "smaller and more focused", and noted that the quarterly releases continue to include all fixes shipped in the monthly ones. According to endoflife.ai, the next monthly releases are due on 17 November and 15 December 2026, and the next quarterly release on 19 January 2027.

Two forces push the totals up. Vendor products embed many open source libraries, so one library flaw can produce a fix in many products. And discovery is faster: CISA's explainer for BOD 26-04, Patch smarter, not harder, describes AI as speeding up both vulnerability discovery and attack.

The result is a release where the headline number tells you almost nothing about your own risk. SecurityWeek's breakdown of the October release shows the spread: Fusion Middleware had 206 fixes, E-Business Suite 194, Siebel CRM 122, Communications 110, PeopleSoft 109, JD Edwards 102, MySQL 98 and Java SE 55. If you run Java SE and MySQL but none of the business applications, your share of that release is a small fraction of the total.

How do you read a vendor risk matrix quickly?

Most enterprise vendors publish a per product table of fixes. Oracle calls these risk matrices and documents every column in a public Risk Matrix Glossary. The layout is typical of the industry, so the habits below transfer to other vendors' bulletins.

Each row is one fix. The columns that matter for triage are:

Two details from Oracle's glossary change how you read the table. First, rows marked "Yes" in the remote without authentication column are treated as higher risk, and each matrix is sorted by that value, so the most dangerous rows sit at the top. Read the top of every matrix that applies to you before anything else. Second, the supported versions column lists only supported releases, and for products released as patch sets it names the last affected patch set. Earlier patch sets should be assumed vulnerable too.

A fast reading routine for each matrix that applies to you:

1. Read every row marked "Yes" for remote without authentication.
2. For each, check whether the protocol it names is reachable from outside your trust boundary.
3. Note every row with a CVSS vector of network, low complexity, no privileges and no user interaction, even if it is marked as needing authentication through a footnote. Credentials leak.
4. Note every row whose component names a third party library. You will use these in a later step.
5. Skim the notes for rows you flagged; footnotes often limit a flaw to one configuration.

This takes minutes per matrix. You are not deciding yet, only building the candidate list.

First filter: which of these products do we actually run, and which versions?

This is the filter that does the most work, and the one most teams skip because their inventory is incomplete. A quarterly release from a large vendor typically spans 30 or more product families. Your exposure is the intersection of that list with what you run.

You need four facts per installation: product, exact version or patch level, where it runs, and who owns it. A configuration management database may hold some of this, but versions drift, so collect them from the systems themselves where you can. Some examples for common products in a large vendor's release:

# Java runtimes on a host (check every JAVA_HOME, not just the one on PATH)
java -version 2>&1 | head -1
find / -type f -name "release" -path "*jdk*" 2>/dev/null | xargs grep -H "JAVA_VERSION="

# MySQL server version
mysql -e "SELECT VERSION();"

# Oracle Database: release banner and applied patches (run as a DBA)
sqlplus -s / as sysdba <<'SQL'
SELECT banner_full FROM v$version;
SELECT patch_id, action, status, description FROM dba_registry_sqlpatch ORDER BY action_time;
SQL

# Patches applied to an Oracle home
$ORACLE_HOME/OPatch/opatch lspatches

For containers, ask the image rather than the person who built it. Vendor runtimes and middleware are often baked into images that nobody has opened since they were built:

# Which Java runtime is inside an image?
docker run --rm --entrypoint sh your-registry/app:prod -c 'java -version 2>&1 | head -1'

# Generate a full component inventory for an image and a repository with the Safeguard CLI
safeguard scan --image your-registry/app:prod
safeguard scan --dir .

The Safeguard CLI writes results as JSON under ./output, which you can join against the advisory's CVE list. If you already keep SBOMs, the SBOM incident response guide shows how to go from a CVE to every affected product quickly.

Once you have the inventory, turn the advisory into a table you can join. Most vendors publish a text or machine readable form of their matrices. Oracle publishes a text form of the October 2026 risk matrices alongside the main advisory. Copy the CVE, product, component, remote without authentication flag, CVSS score and affected versions into a CSV. Then join on product and version. Rows for products you do not run drop out. Rows for versions you do not run drop out. What remains is your actual exposure.

Expect this step to remove most of the release. That is not a shortcut. It is the correct answer for your organisation.

Second filter: internet facing, unauthenticated, known exploited, likely exploited

You now have a list of fixes that apply to software you run. The second filter ranks them by how likely they are to hurt you soon. Four inputs carry most of the signal.

Is it known exploited? Check CISA KEV

The Known Exploited Vulnerabilities catalog is CISA's list of flaws with evidence of exploitation in the wild, and CISA describes it as "the authoritative source" for that question. When we checked it on 23 October 2026 it held 1,754 entries. It is free, updated as CISA confirms exploitation, and published as CSV and JSON.

The JSON schema defines the fields you will use: cveID, vendorProject, product, dateAdded, dueDate, requiredAction, knownRansomwareCampaignUse (Known or Unknown), and since BOD 26-04 a forensicTriage field (Yes or No) that tells federal agencies when a fix alone is not enough and they must check for compromise.

# Download the KEV feed
curl -sSL -o kev.json \
  https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json

# Which of the advisory's CVEs are in KEV? (advisory_cves.txt holds one CVE per line)
jq -r '.vulnerabilities[].cveID' kev.json | sort > kev_ids.txt
sort -u advisory_cves.txt | comm -12 - kev_ids.txt

# Show KEV entries for a vendor, with ransomware use and forensic triage flags
jq -r '.vulnerabilities[]
  | select(.vendorProject=="Oracle")
  | [.cveID, .product, .dateAdded, .knownRansomwareCampaignUse, (.forensicTriage // "n/a")]
  | @tsv' kev.json

Two cautions. A new release often has no KEV hits on the day it ships, because exploitation evidence arrives later. SecurityWeek reported that Oracle had not flagged any October fix as exploited, and endoflife.ai reported that as of CISA's catalog dated 21 October, no Oracle CVE in the advisory was KEV listed. That is a snapshot, not a promise, so re-run the join daily for the life of the release. Second, check the third party CVEs too. endoflife.ai noted that the October advisory lists fixes in Oracle Communications products for Apache Tomcat CVE-2025-24813 and the HTTP/2 Rapid Reset flaw CVE-2023-44487, both already in KEV. A vendor release can contain KEV listed flaws even when none of the vendor's own CVEs are.

Is it reachable without credentials?

Take the rows marked remote without authentication and check them against real exposure. Not "is the server in the DMZ" but "can an untrusted host open a connection to the listener the protocol column names". BOD 26-04 gives a useful definition: an asset is publicly exposed when it is "accessible to unauthenticated or untrusted entities via public networks", regardless of where it physically sits. Use external scan data, cloud security group rules and load balancer listeners as evidence, not architecture diagrams.

How likely is exploitation soon? Check EPSS

For everything not yet in KEV, the Exploit Prediction Scoring System from FIRST estimates "the probability that a published CVE will be exploited in the wild in the next 30 days". It publishes a score between 0 and 1 and a percentile for every CVE, every day, through a free API. Our explainer on understanding EPSS covers how the model works.

# EPSS for specific CVEs (comma separated, up to 2,000 characters per request)
curl -s "https://api.first.org/data/v1/epss?cve=CVE-2023-44487,CVE-2025-24813&pretty=true"

# Only CVEs at or above the 95th percentile, from your list
curl -s "https://api.first.org/data/v1/epss?cve=$(paste -sd, advisory_cves.txt)&percentile-gt=0.95" \
  | jq -r '.data[] | [.cve, .epss, .percentile] | @tsv'

# Thirty days of history for one CVE, to see whether the score is climbing
curl -s "https://api.first.org/data/v1/epss?cve=CVE-2023-44487&scope=time-series"

The EPSS API documentation lists the parameters: cve, date for historic scores back to 14 April 2021, epss-gt and percentile-gt (both inclusive, despite the names), their -lt counterparts, and scope=time-series. The API is marked beta, so pin your scripts to the documented parameters and handle errors.

A caution on brand new CVEs: EPSS needs data to score well, and on release day many CVEs have little signal. Treat a low score on a two day old CVE as "unknown yet", not "safe". The time series view helps you spot scores that are rising.

What happens if it is exploited? Technical impact and asset value

The last input is consequence. A flaw that gives full control of a system holding customer data is worse than one that leaks a configuration value from a test box. CVSS confidentiality, integrity and availability metrics give you the technical side. Your asset register gives you the business side: what data the system holds, what depends on it, and whether it is regulated. The post on setting remediation SLAs by asset criticality and exposure goes deeper on building that register.

Putting the inputs together with SSVC

Four inputs need a rule to combine them, or every analyst will weigh them differently. Stakeholder Specific Vulnerability Categorization (SSVC) is that rule. It was created by Carnegie Mellon's Software Engineering Institute and CISA in 2019, and CISA adapted its own version in 2020, according to CISA's SSVC page.

The CERT/CC deployer decision model is the version written for teams applying patches. Its inputs are:

• Exploitation: none, public proof of concept, or active ("shared, observable, reliable evidence" of real attackers using it).
• System exposure: small (a local service or a highly controlled network), controlled (networked with some access restrictions), or open (internet or another network "where access cannot plausibly be restricted").
• Automatable: whether an attacker can reliably automate the early steps of an attack, yes or no.
• Human impact: low, medium, high or very high, combining safety and mission impact.

Its outputs are four actions: Defer ("do not act at present"), Scheduled (act in the normal maintenance window), Out of cycle (act faster than usual) and Immediate ("focus all resources" on the fix). In the published table, active exploitation never results in Defer, and Immediate is reserved for actively exploited flaws on open exposure with high or very high impact.

CISA's own tree uses different labels for the outcomes: Track, Track*, Attend and Act, where Act means remediate as soon as possible with leadership involved. Pick one version and use it consistently. The comparison of CVE, CVSS, EPSS and SSVC explains how the systems relate, and the guide to reading the CISA SSVC block in an NVD record shows where CISA publishes its own SSVC assessment for many CVEs.

A decision table you can use on Monday

Here is how the inputs map to action. It follows the logic of BOD 26-04 and the SSVC deployer model, simplified for a private sector team. Adjust the deadlines to your own risk appetite and document why.

The first row mirrors BOD 26-04's tightest tier. CISA's directive text sets a three day deadline, plus forensic triage, when a KEV listed flaw sits on a publicly exposed asset, is automatable, and gives total technical impact. The directive also allows the lowest risk items to be fixed "on system upgrade", meaning at the next scheduled major upgrade or rebuild. CISA reports that at one large civilian agency, about 1% of vulnerability instances landed in the three day category and more than 60% were deferred to the next upgrade. That is what risk based prioritisation looks like in practice: a tiny urgent queue and a large, consciously scheduled backlog.

How many of the "1,000 fixes" are really open source components?

Enough that you should count them, because this is where your patch cycle and your own code meet.

Large vendor products are built on open source libraries: web servers, XML and JSON parsers, logging frameworks, HTTP/2 stacks, compression libraries, database drivers. When one of those libraries ships a security fix, every vendor product that bundles it needs a new build. In Oracle's matrices, these rows often name the library in parentheses after the component. Search coverage of the October 2026 advisory showed rows such as an Enterprise Manager Security Framework entry for jackson-databind, and endoflife.ai listed Apache Tomcat and HTTP/2 fixes in Communications products. We could not confirm a reliable percentage for the October release, and one figure circulating for July 2026 was not something we could verify, so treat any single share figure with care and count it yourself.

Counting is straightforward once you have the matrix as a CSV:

# Rows whose component names a bundled library in parentheses
grep -E '\([a-zA-Z0-9._-]+\)' advisory_rows.csv | wc -l

# Which libraries appear most often across the release
grep -oE '\([a-zA-Z0-9._-]+\)' advisory_rows.csv | sort | uniq -c | sort -rn | head -20

This matters for two reasons.

Fixing the vendor product is the vendor's job. You cannot safely swap a jar inside a commercial product. The vendor tests its build with a specific library version, and replacing it yourself can break support. Apply the vendor's patch.

Fixing the same library in your own software is your job, and you can start today. If the vendor needed to patch jackson-databind, Tomcat or an HTTP/2 implementation, check whether your own services use the same library at a vulnerable version. They often do, because teams pick the same popular components. The vendor's release is a free early warning for your own dependency tree.

# Is the same library in your Java services?
mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind
./gradlew dependencies --configuration runtimeClasspath | grep jackson-databind

# Or across a repository and its images in one pass
safeguard scan --dir .
safeguard scan --image your-registry/api:prod

# Look for the library inside built artefacts and images
find / -name "jackson-databind-*.jar" 2>/dev/null

The post on how to build a KEV and EPSS shortlist from your SBOM applies the same filters from this article to your own components.

What if you are on a version outside the support window?

Vendors test fixes against supported releases. Oracle's glossary says product versions that are no longer supported "are not tested for the presence of vulnerabilities", and its matrices list only supported versions. So if you run an unsupported version, you will not find it in the affected versions column, and you will not get a patch. The absence of your version is, in endoflife.ai's words, "the absence of a test result, not a clean result". The same article listed releases outside Premier or Extended Support that received no October patches, including Oracle Database 18c, 12.2, 12.1 and 11.2, MySQL 8.0 and WebLogic 12.1.

What to do:

1. Assume affected. If a supported version of the same product line has a fix for a component you also run, assume your older version has the flaw unless you can prove otherwise from the vendor.
2. Raise the risk tier. An unsupported version on an internet facing host with a remote without authentication flaw in the supported line belongs in your out of cycle tier, with a compensating control in place within days.
3. Check the support calendar for what is next. endoflife.ai noted that WebLogic 12.2.1.4 Premier Support ends on 31 December 2026 and Oracle Database 21c support ends on 31 July 2027. Anything on that list is next quarter's problem; start the upgrade project now.
4. Know what your support contract covers. Paid extended support and third party support arrangements vary in what security fixes they include. Ask in writing which CVEs from this release they cover.
5. Record the exception. An unsupported version you keep running is an accepted risk. It needs an owner, a compensating control, a review date and a target upgrade date.

Our post on how many versions back a vendor patches covers support windows across vendors in more detail.

How do you set patch deadlines by tier so the quarter does not collapse into one panic week?

The classic failure is an all hands scramble in release week and then nothing until the next release. Tiers fix this: each has a deadline, an owner and a change process.

Some practical rules make this hold up across the quarter:

• Split the release into changes by tier on day one. Never hold urgent items back to bundle them with the rest.
• Use the vendor's cadence. With a monthly release between quarterly ones, Oracle customers can pull urgent fixes forward without waiting three months. Plan a small monthly window and a larger quarterly one.
• Re-tier daily for the first two weeks. A fix moves up a tier when it lands in KEV, when its EPSS percentile jumps, or when a public proof of concept appears. Automate the KEV and EPSS check and alert the owner when a tier changes.
• Test once per platform, deploy many times. Keep a reusable regression path per platform version so a Tier 1 change does not need a new test plan.
• Measure time to remediate per tier, not the backlog total. CISA's explainer cites Verizon's 2026 Data Breach Investigations Report finding that only 26% of KEV vulnerabilities were fully remediated in 2025, with a median of 43 days to full resolution. Track your own Tier 0 and Tier 1 times against your deadlines.

The remediation SLA guide covers how to agree these deadlines with system owners so they are not just a security team wish list.

What evidence should you keep to show auditors the prioritisation was deliberate?

Auditors and regulators do not expect you to patch everything immediately. They expect a documented process, applied consistently, with decisions you can explain. BOD 26-04 itself requires federal agencies to update their vulnerability management policies and provide copies to CISA on request; private sector frameworks ask for the same shape of evidence.

Keep these records for each release:

1. The policy. A short document that defines your tiers, the inputs (inventory, KEV, exposure, EPSS, SSVC or your equivalent) and the deadlines. Version it.
2. The intake record. Release date, triage start date, advisory URL and a copy of the matrix.
3. The applicability result. Which rows applied to which assets, and which were ruled out.
4. The triage snapshot. For each applicable fix: KEV status, EPSS on the day, exposure evidence, impact, tier and deadline, with the raw KEV and EPSS data saved.
5. Change records. The ticket or change request for each tier, with the deployment date.
6. Verification. Proof that the patch is actually applied: opatch lspatches output, version output, a rescan result. A closed ticket is not proof.
7. Exceptions. Every risk acceptance with owner, reason, compensating control, review date and expiry.
8. Re-tier log. Any fix that moved tiers after a KEV addition or EPSS change, with the date it moved and the new deadline.

A simple way to make this repeatable is to save the raw inputs with the date every time you triage:

d=$(date +%F); mkdir -p "triage/$d"
curl -sSL -o "triage/$d/kev.json" \
  https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
curl -s -o "triage/$d/epss.json" \
  "https://api.first.org/data/v1/epss?cve=$(paste -sd, advisory_cves.txt)"
cp applicability.csv "triage/$d/"

Run it on release day and daily for two weeks, keep every folder, and you have a dated trail showing exactly what you knew and when.

What can you do this week while the full patch cycle runs?

Patching middleware and databases takes testing, and testing takes time. Meanwhile, reduce the chance that anything in Tier 0 or Tier 1 can be reached.

• Remove exposure. BOD 26-04 treats exposure as dynamic: taking an asset off the internet moves it to a longer deadline. If an admin console, management port or protocol listener named in the matrix does not need to be public, close it at the firewall or security group today.
• Disable what you do not use. If the vulnerable component is an optional protocol, sample application or admin endpoint you do not use, disabling it may take the flaw out of reach. Confirm with the vendor's documentation first.
• Put a filter in front. A web application firewall or reverse proxy rule can block known attack patterns for some web facing flaws. Treat this as a delay, not a fix.
• Watch harder. Raise logging on Tier 0 and Tier 1 systems, alert on new admin accounts, unexpected outbound connections and new processes, and make sure logs leave the host.
• Check for compromise on the worst cases. If a flaw was exploited before you patched an exposed system, a patch does not remove an attacker who is already in. BOD 26-04 pairs its three day tier with forensic triage for that reason.
• Snapshot before you patch, and confirm you can restore, so a failed patch does not become an outage.

Our guide on whether to take a system offline if you cannot patch goes through that decision in detail.

A step by step walkthrough for release day

The whole process in order, as you might run it the morning a large release lands:

1. Get the advisory as data. Convert the vendor's text form of the matrices to a CSV.
2. Refresh inventory. Pull versions from hosts, databases and images, using the commands above.
3. Join advisory rows to inventory on product and version. Save it as the applicability table.
4. List unsupported versions as exceptions, assumed affected.
5. Pull KEV and EPSS for every applicable CVE and save both with the date.
6. Add exposure from external scans and cloud network rules.
7. Tier each row with your decision table or SSVC tree, with a deadline.
8. Open changes: one per Tier 0 and Tier 1 item, one batch for Tier 2.
9. Mitigate Tier 0 and Tier 1 today while patches are tested.
10. Scan your own code and images for the bundled libraries the matrix names.
11. Re-check daily for two weeks and alert owners when a tier changes.
12. Verify and record the patch level after each deployment.

If you only have an hour, do steps 1, 3, 5, 6 and 9.

Common mistakes

• Sorting by CVSS and starting at the top. You end up patching critical scores on products nobody exposes while a medium score in KEV waits. Filter by inventory and exploitation first.
• Trusting the CMDB version field. Versions drift. Collect them from the system, and from images, on release day.
• Treating "not in KEV" as "not exploited". KEV lags. Recheck daily, and use EPSS and public proof of concept reports to fill the gap.
• Reading a missing version as safe. Unsupported versions are not tested. Assume affected.
• Ignoring the third party rows. They may affect your own code too.
• Holding urgent fixes for the quarterly window. Monthly releases exist so you do not have to.
• Deferring without writing it down. A deferral is fine. An undocumented deferral is a finding.
• Patching and walking away. For exploited flaws on exposed systems, check for compromise as well as patching.
• Closing tickets without verification. Proof of the patch level is the evidence, not the ticket status.

FAQ

How do I prioritise patches when a vendor releases hundreds of fixes at once?

Filter to the products and versions you run, then rank what is left by known exploitation (CISA KEV), exposure to untrusted networks without authentication, EPSS probability and impact on the asset. Put the result into dated tiers. Most of the release will fall into normal maintenance windows.

Is CVSS enough to prioritise vulnerabilities?

No. CVSS describes how bad a flaw could be, not whether anyone is exploiting it or whether it is reachable in your environment. Use it as one input alongside KEV, exposure and EPSS. CISA's BOD 26-04 moved federal agencies away from severity driven deadlines for this reason.

What is the difference between EPSS and CISA KEV?

KEV lists vulnerabilities with evidence of exploitation that has already happened. EPSS estimates the probability of exploitation in the next 30 days for any published CVE. Use KEV as a hard trigger and EPSS to rank what has not reached KEV yet.

What does "remote exploit without authentication" mean in an Oracle risk matrix?

It means an attacker on the network could exploit the flaw without any credentials for the target system. Oracle treats those rows as higher risk and sorts each matrix so they appear first. Combine it with your exposure data: the flag only becomes urgent when the listener is reachable.

What does BOD 26-04 require, and does it apply to private companies?

BOD 26-04, issued by CISA on 10 June 2026, replaced BOD 22-01 and BOD 19-02. It sets federal civilian agency deadlines by exposure, KEV status, automation and technical impact, with three days for the highest risk cases. It does not bind private companies, but it is a useful template.

How long should we take to patch critical vulnerabilities?

It depends on exploitation and exposure more than on the label. A reasonable start: about 72 hours for known exploited flaws on internet facing systems, 7 to 14 days for other exploited or likely exploited flaws, 30 to 60 days for the rest.

What should we do if we are running an unsupported version?

Assume it is affected by flaws fixed in the supported line, because the vendor did not test it. Add compensating controls, record a risk exception with an owner and expiry, and start the upgrade. Ask your support provider in writing which fixes they cover.

Why do vendor patch releases include open source CVEs?

Because vendor products bundle open source libraries, and when a library is fixed, the vendor rebuilds every product that uses it. Those rows are also a signal to check your own applications for the same library.

Can we skip a quarterly patch if nothing applies to us?

You can skip rows that do not apply, once you have checked inventory and recorded the result. Skipping without the check is how forgotten installs stay exposed.

How do we prove to auditors that our patch prioritisation is risk based?

Keep the policy, the dated applicability table, the KEV and EPSS data you used, tiers and deadlines, change records, verification output and every exception. A dated triage snapshot per release is usually enough to show the process is deliberate and consistent.

Fix it without waiting for upstream

Your vendor's patch has to come from your vendor. But a large share of every vendor release is open source libraries, and the same libraries sit in the services and images you build. For those, you do not need to wait for anyone.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

Where Safeguard fits, and where it does not

Safeguard does not patch commercial products or apply a vendor's database or middleware update; that stays with your platform team. It helps with the open source half: SBOMs from repositories, images and SBOM files, matching against vulnerability databases including CISA KEV, ranking by reachability, EPSS and KEV, and showing which projects contain a given component and version, so "do we ship the library the vendor just patched?" is one query.

See how Safeguard would help

None of these demos patches a vendor product. They show the parts of this workflow that touch your own code and images: finding the libraries a vendor release flagged, fixing them with approval, and asking questions of your inventory.

The first demo is a real CLI session. Asked to fix a lodash CVE, the CLI reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. The same flow applies when a vendor's advisory names a library your own services also bundle: you ask, review each step, and merge on your terms.

Click through it at your own pace, or open it full screen.

The second demo sets up the runner on your own machine, approves it with its device code, then scans from the terminal. On release day, that is how you scan the images and repositories that bundle vendor runtimes without sending source code anywhere you have not chosen.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. With read access to your projects and vulnerabilities, you can ask which projects contain a library from the vendor's third party rows, and keep the assistant limited to the tools that question needs.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard or read the CLI documentation.

Quick check

Sources

• Oracle Critical Patch Update Advisory, October 2026
• Oracle: Text form of the October 2026 risk matrices
• Oracle: Risk Matrix Glossary
• SecurityWeek: Oracle patches over 1,200 vulnerabilities with October 2026 CPU
• endoflife.ai: Oracle CPU October 2026 and unsupported versions
• Help Net Security: Oracle rolls out monthly security patch updates
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: KEV JSON schema
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA: Patch smarter, not harder
• CISA: Stakeholder Specific Vulnerability Categorization
• CERT/CC: SSVC deployer decision model
• FIRST: Exploit Prediction Scoring System
• FIRST: EPSS API

Last reviewed: 23 October 2026. KEV, EPSS and vendor advisories change daily; check the linked sources for current status.