How Do I Know If My Vendors Have Patched a Critical Vulnerability?

You know a vendor has patched a critical vulnerability when you hold evidence you can check yourself: a published advisory ID, the exact fixed package build, a signed VEX statement for your product version, or an updated SBOM that shows the fixed component. A reassuring email is not evidence, and a version string on its own often misleads, because many distributions fix flaws without changing the upstream version number.

This guide is for third party risk managers, IT and security leads, and procurement and compliance teams. It covers which vendors matter, what to ask, what a credible answer looks like, response times and contract terms, silent vendors, and how to record the outcome as audit evidence for SOC 2, ISO 27001, DORA or NIS2.

Key takeaways

• Start from your own inventory, not from your vendor list. The vendors that matter are the ones whose product or service actually runs the affected component in a path that touches your data or your network.
• Version strings are weak evidence. Debian, Ubuntu and Red Hat backport security fixes into older versions, so "PHP 8.1.2" can be patched or vulnerable depending on the package build suffix.
• Strong evidence is specific and checkable: an advisory ID (USN, DSA, RHSA or the vendor's own), a fixed build number, a CSAF or OpenVEX document with a status for your product, or a fresh SBOM.
• VEX has four statuses that matter: not affected, affected, fixed and under investigation. A "not affected" claim should always carry a justification.
• Put response times in the contract before the incident: acknowledgement, a status statement, then a fix or mitigation, each with a clock.
• When a vendor goes silent, act on your side first: isolate, restrict exposure, use compensating controls, and escalate through the contract.
• Record each vendor's answer, the evidence, the date and the decision in one place. That record is what an auditor will ask for.

Why this question gets asked every time a big flaw lands

When a critical flaw lands in a component that runs almost everywhere, every customer asks every vendor the same question in the same week, as the October 2026 PHP flaws showed. Ubuntu published fixed packages for CVE-2026-109618 and CVE-2026-109619 on 21 October 2026, after a leak moved the coordinated disclosure forward by a day, according to Ubuntu's notice. The Hacker News told readers to inventory PHP inside vendor appliances, Windows software and control panels, and to "check your Linux distribution and hosting provider for backported packages." Good advice, but it stops where teams get stuck: how do you confirm the hosting provider, appliance maker or SaaS vendor has done it? This post answers that for any widely deployed component. For the incident itself, see our posts on finding and patching every PHP runtime and the PHP2Shell flaws explained.

Which vendors actually matter for a given vulnerability?

Not every vendor is in scope for every flaw, and a questionnaire to 400 suppliers buries the answers you need. Sort vendors by how the affected component reaches you.

The four exposure classes

Underneath all four sit embedded open source components, which you rarely see without an SBOM.

Narrow the list with three questions

For each vendor, answer three questions before you send anything:

1. Does the vendor's product plausibly contain the component? A payroll SaaS written on a JVM stack is unlikely to bundle PHP. A hosting control panel almost certainly does. An SBOM, if you have one, turns "plausibly" into "yes" or "no".
2. Is the component reachable from an attacker's position? An internet facing web tier is a higher priority than an internal batch job.
3. What does the vendor hold or touch? A vendor with your customer data or a network path into your environment goes to the top of the list, whatever its size.

"Yes, yes, sensitive" gets a direct message and a deadline in the first hours; "unlikely, no, low" can wait for a public advisory. This risk based tiering is the general approach of NIST SP 800-161 Rev. 1, the US federal guide to cybersecurity supply chain risk management.

Do not forget the vendors behind your vendors

Your hosting provider may run a third company's control panel, and your SaaS vendor runs on a cloud platform. You usually cannot audit those fourth parties, but you can ask your direct vendor whether its own suppliers are affected and whether it has confirmed their status.

What should you ask a vendor, and what counts as a credible answer?

"Are you affected?" invites "We take security seriously and are monitoring the situation." Ask questions that can only be answered with facts.

A message you can send today

Subject: Status request for CVE-2026-109618 and CVE-2026-109619 (PHP)

We use the following of your products or services: <product, plan, region, account ID>.

Please confirm, for each product and version we use:
1. Status: not affected, affected, fixed, or under investigation.
2. If not affected: the reason (component not present, vulnerable code not present,
   vulnerable code not reachable, or mitigated), in one or two sentences.
3. If fixed: the fixed product version or build, the date it reached our environment,
   and your advisory ID or link.
4. If affected or under investigation: the interim mitigation you recommend and the
   date of your next update.
5. Whether you publish a CSAF or VEX document, or an updated SBOM, for this issue.

Please reply by <date and time, with timezone>. Contact for this request: <name, email>.

Each numbered item maps to a VEX field, so a vendor that publishes VEX can answer with a link.

Grading the answers

Credible answers are specific to your product and version, dated, and checkable against something outside the vendor's own words: an advisory, a package build, a signature or your own scan.

Watch the wording of "not affected"

"Not affected" is often true and often lazy. VEX forces a reason, and so should you. The OpenVEX specification lists five justifications for a "not affected" status:

• component_not_present: the product does not include the component at all.
• vulnerable_code_not_present: the component is present, but the vulnerable code is not, for example because it was compiled out.
• vulnerable_code_not_in_execute_path: the vulnerable code is present but the product never calls it.
• vulnerable_code_cannot_be_controlled_by_adversary: the code runs, but an attacker cannot reach or control its input.
• inline_mitigations_already_exist: something in the product blocks exploitation.

The first two are easiest to verify. The last three rest on the vendor's analysis and deserve an explanation; for a mitigation, ask what happens if it later changes.

Why are version strings unreliable, and what evidence is better?

Backporting keeps the old number

Linux distributions keep stable releases as unchanged as possible, so they apply security fixes to the version they already ship instead of moving to the new upstream release. Debian's security FAQ says the relevant changes "should be backported" rather than moving to a new upstream version. Red Hat's page on backporting is blunter: the version number alone "will not tell them if they are vulnerable or not."

So two servers can both report PHP 8.1.2 while only one is patched. The difference is the package build suffix: Ubuntu's notice lists 8.1.2-1ubuntu2.28 as the fixed build for 22.04, with the upstream part unchanged. This cuts both ways:

• A scanner or a curious customer who reads a Server or X-Powered-By header that says PHP 8.1.2 may conclude the host is vulnerable when it is patched. Red Hat warns that tools judging by version number alone produce false positives because they ignore backported fixes.
• A vendor who says "we run PHP 8.1 from our distribution" may be patched or a week behind. The version cannot tell you which.

Two other traps sit next to backporting:

• Patched on disk, not in memory. Ubuntu's notice says that even when unattended upgrades apply fixes within 24 hours, the application still needs a restart or reboot.
• End of life branches. A branch past its upstream end of life gets no upstream fix. Distributions may keep patching it under extended support (Ubuntu covers 20.04 and older through Ubuntu Pro with ESM, per its notice), but a vendor outside any such program has nothing to install.

The evidence ladder

Use this ladder to grade any confirmation, from weakest to strongest:

For SaaS you often top out at rank 4 or 5. Know which rank you hold and record it honestly.

Step by step: confirm a fix on systems you can reach

Where you have shell access, check the package build rather than the banner. Swap in the package you care about.

Debian and Ubuntu

# List installed PHP runtime packages and their exact builds
apt list --installed 2>/dev/null | grep -E '^php[0-9.]+(-[a-z]+)?/'

# Or with dpkg, showing the full version string including the distro suffix
dpkg -l | awk '/^ii/ && $2 ~ /^php[0-9.]+/ {print $2, $3}'

# Read the changelog and look for the CVE identifier
apt-get changelog php8.1 | grep -n -i 'CVE-2026-109618'

# On Ubuntu with the Pro client, ask whether a CVE is fixed on this machine
pro fix CVE-2026-109618

Compare the build with the fixed build listed in the distribution's advisory. Debian's FAQ recommends exactly that: compare the installed version number against the version in the Debian Security Advisory, then check the security tracker page for the CVE.

Red Hat family (RHEL, Rocky, Alma and similar)

# Is there an advisory for this CVE that applies to this host?
dnf updateinfo list --cve CVE-2026-109618

# Does the installed package changelog mention the CVE?
rpm -q --changelog php | grep -i 'CVE-2026-109618'

Container images

A patched host does not patch the images that run on it. Check inside the image the vendor ships or the one you deploy:

docker run --rm --entrypoint sh registry.example.com/vendor/app:2026.10 \
  -c 'dpkg -l 2>/dev/null | grep -E "^ii +php" || apk info -v 2>/dev/null | grep ^php'

Confirm the running process, not just the disk

# Which PHP processes are running, and since when?
ps -eo pid,lstart,cmd | grep -E '[p]hp(-fpm)?'

# When were the packages last upgraded?
grep -E ' upgrade php' /var/log/dpkg.log | tail -n 5

If the process start time is earlier than the package upgrade time, the old code is still running. Restart the service or reboot.

What to do with a vendor's SBOM

An SBOM tells you whether the component is present and at what version. It does not tell you whether the vendor has backported a fix, unless the SBOM records the distribution build or the vendor includes pedigree data. Treat it as a presence check first.

# CycloneDX JSON: find PHP components and print name, version and package URL
jq -r '.components[]? | select(.name | test("^php"; "i")) | "\(.name)\t\(.version)\t\(.purl // "-")"' vendor-sbom.cdx.json

# SPDX JSON: the same idea
jq -r '.packages[]? | select(.name | test("^php"; "i")) | "\(.name)\t\(.versionInfo // "-")"' vendor-sbom.spdx.json

A package URL such as pkg:deb/ubuntu/php8.1@8.1.2-1ubuntu2.28 carries the distribution build, which is what you need. A bare php 8.1.2 does not. When you request SBOMs, ask for package URLs with the full distribution version.

How fast should a vendor respond, and what should the contract say?

There is no single legal clock for every vendor and flaw, so agree on clocks in advance and measure against them.

A practical response timeline

These are suggested contract targets for critical, internet facing flaws, not figures from any regulation. Tune them to your risk appetite.

Known exploitation should shorten every clock. CISA's Known Exploited Vulnerabilities catalog lists flaws with reliable evidence of exploitation in the wild, and CISA recommends that organizations outside the federal government "immediately address KEV catalog vulnerabilities" in their vulnerability management plans. The same page notes that federal agencies now follow remediation timeframes set by BOD 26-04, issued 10 June 2026, which carries forward the KEV criteria from BOD 22-01. Tie your vendor's clock to KEV listing so urgency rises automatically when exploitation is confirmed.

Clauses worth having

Your legal team will word these; this list covers what the security schedule should say.

1. Notification. The vendor tells you, within a set time, about critical vulnerabilities affecting the service you buy, whether or not you ask.
2. Status on request. The vendor answers status requests within a set time, per product version, using the four VEX statuses.
3. Machine readable advisories. Advisories in CSAF, with VEX statements where they apply, at a stable URL.
4. SBOM delivery. An SPDX or CycloneDX SBOM per major release, with package URLs that include the distribution build.
5. Remediation targets. Time to fix or mitigate by severity, shorter for KEV listed flaws, with notice when a target will slip.
6. Supported components. No end of life runtimes in your path without telling you first.
7. Subcontractors. The same duties pass down the chain.
8. Incident assistance and audit. Help and logs if the flaw was exploited, and a way to obtain evidence of all of the above.
9. Disclosure channel. A published vulnerability disclosure policy and a security.txt file.

What DORA and NIS2 already require

If you are a financial entity in the EU, some of this is law. DORA Article 30 sets the key contractual provisions for ICT third party service providers. It requires the provider to assist with ICT incidents related to the service "at no additional cost, or at a cost that is determined ex-ante," and, for critical or important functions, it requires notice periods and reporting obligations, security measures suited to the financial entity's regulatory framework, and unrestricted rights of access, inspection and audit. It also covers subcontracting conditions and exit plans.

For essential and important entities under NIS2, Article 21 lists supply chain security, meaning the security aspects of relationships with direct suppliers and service providers, as a required risk management measure. Article 21(3) asks entities to take into account "the vulnerabilities specific to each direct supplier and service provider" and the quality of suppliers' secure development procedures. Tracking whether a supplier has patched a critical flaw is that duty in practice.

In the US, CISA's voluntary Secure by Design pledge asks software makers to publish a disclosure policy, issue CVEs promptly for critical and high impact flaws needing customer action, and give customers evidence of intrusions such as logs. A signatory has publicly committed to much of the clause list above, which is useful use.

How do trust centers, VEX statements and SBOMs shorten the cycle?

The slow part of vendor confirmation is the round trip: you ask, they triage, they answer in prose, you interpret, you ask again. Published, machine readable statements remove most of that loop.

SBOMs: answer "is it in there?" before you ask

With a current SBOM for each installed product, you can tell whether the component is present in minutes, for every vendor at once. Requests then go only to vendors that ship it, and you can name the version you found: "your SBOM for release 7.4 shows php8.1 at 8.1.2-1ubuntu2.27; please confirm the fixed build." Vendors answer specific questions faster. SBOMs describe a release at a point in time and say nothing about exploitability, so for SaaS a VEX statement or advisory matters more.

VEX: the vendor's answer, in a format machines read

VEX, short for Vulnerability Exploitability eXchange, is a statement from a supplier about whether a specific product version is affected by a specific vulnerability. CISA published minimum requirements for VEX in April 2023. Three formats are in common use, and they line up closely:

A few details from the specifications are worth knowing when you read vendor documents:

• In CSAF 2.0, the OASIS standard published in November 2022, a VEX document must include at least one of fixed, known_affected, known_not_affected or under_investigation. A known_not_affected product must have an impact statement as a machine readable flag or as a human readable justification. A known_affected product must have a remediation, which can honestly be no_fix_planned or none_available.
• In OpenVEX, every statement links a product, a vulnerability and a status, and a not_affected statement requires either a justification or an impact statement. The spec discourages relying on free text alone, because machines cannot read it.
• In CycloneDX, VEX data lives in the analysis object of a vulnerability, either inside the BOM or in a separate document. The resolved_with_pedigree state marks a fix backed by commit or diff evidence in the component pedigree, which is the closest any format comes to proving a backport.

A short OpenVEX document from a vendor might look like this:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://vendor.example/vex/2026-10-php.json",
  "author": "Vendor Example Product Security",
  "timestamp": "2026-10-21T18:00:00Z",
  "version": 2,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2026-109618" },
      "products": [
        { "@id": "pkg:generic/vendor-example/edge-portal@7.4.2" }
      ],
      "status": "fixed",
      "status_notes": "php8.1 updated to 8.1.2-1ubuntu2.28 in 7.4.2"
    },
    {
      "vulnerability": { "name": "CVE-2026-109618" },
      "products": [
        { "@id": "pkg:generic/vendor-example/reporting-api@3.1.0" }
      ],
      "status": "not_affected",
      "justification": "component_not_present"
    }
  ]
}

Note the version field. OpenVEX requires it to increase every time the content changes, so you can tell an "under investigation" document from its later "fixed" update.

Finding and checking CSAF advisories automatically

CSAF also defines how to find a vendor's advisories without asking. A CSAF provider publishes a provider-metadata.json file at /.well-known/csaf/provider-metadata.json on its main domain, and its security.txt can carry a CSAF: field pointing to it. A trusted provider adds hash files and OpenPGP signatures for each document, and retrievers are expected to check them before using the content.

# Discover a vendor's CSAF metadata
curl -s https://vendor.example/.well-known/csaf/provider-metadata.json | jq '.role, .distributions'

# Or look for the CSAF field in security.txt
curl -s https://vendor.example/.well-known/security.txt | grep -i '^CSAF:'

# Verify a downloaded advisory's hash and signature
sha512sum -c vex-2026-10-php.json.sha512
gpg --verify vex-2026-10-php.json.asc vex-2026-10-php.json

If a vendor publishes CSAF, poll its feed instead of emailing.

Trust centers

Many vendors run a security page or trust center listing their position on high profile CVEs, which helps most for SaaS. Check the entry's date, its product scope, and whether it links to an advisory or VEX file you can keep. Save a dated copy, because the page will change.

What do you do when a vendor goes silent?

Some vendors will not answer by your deadline. Treat silence as "affected, unknown" until proven otherwise.

An escalation path that works

1. Check public sources first: advisory page, CSAF feed, status page, release notes, security.txt. Many vendors publish before they answer emails.
2. Use the contract channel. Resend to the security contact in your agreement, copy your account manager, and cite the clause.
3. Escalate by role. Your CISO or head of procurement contacts their counterpart.
4. Reduce exposure on your side, in parallel with steps 1 to 3.
5. Record the silence. Every attempt, with date and channel, is audit evidence that you tried.
6. Rerate the vendor. Repeated silence on critical issues is a risk finding in its own right; bring it to renewal.

Compensating controls you can apply without the vendor

None of these replace the fix; they buy time. For the options when a vendor says it will not fix at all, see what to do when a vendor will not fix a vulnerability.

How do you record the outcome for SOC 2, ISO 27001, DORA or NIS2 evidence?

Auditors want a process, consistently applied, with dated evidence and a decision for each vendor that mattered.

What the frameworks look for

• SOC 2. The vendor management criterion in the Trust Services Criteria asks how the organization assesses and manages risks from vendors and business partners. A record of in scope vendors, requests, graded responses and actions is what an auditor samples.
• ISO/IEC 27001:2022. Annex A has a cluster of supplier controls covering security in supplier relationships, security within supplier agreements, the ICT supply chain, and monitoring and review of supplier services, plus a control for managing technical vulnerabilities. A vendor confirmation record supports both.
• DORA. Article 30 gives you the contractual hooks: assistance with incidents, notice and reporting duties, and audit rights. Your record shows you used them.
• NIS2. Article 21 asks you to take supplier specific vulnerabilities into account. A record per supplier per critical flaw is the plainest demonstration.

The record to keep

Keep one row per vendor per vulnerability. A spreadsheet works for a handful of vendors; at scale, use a system that holds the evidence files next to the row.

For vendors that did not answer, the row records each attempt, the compensating controls applied, and the risk decision with the name of the person who accepted it.

Where Safeguard fits

For the vendor side of the problem, Safeguard's Third-Party Risk Manager (TPRM) is generally available. It lets you onboard vendors, request SBOMs, projects or products from them, score and continuously monitor supplier risk, view mitigations others have applied, run scans through vendor integrations, and apply policies and gates. Vendor SBOMs sit in the same platform as your own scans, and the platform shows which projects contain a given component and version, so when a critical flaw lands you can narrow status requests to the suppliers whose SBOMs include it. CSAF and VEX upload is also generally available, so a vendor's "fixed" or "not affected" statement can sit next to the SBOM it refers to.

Safeguard does not patch a vendor's hosted service, appliance or operating system, and it cannot see inside a SaaS product that has not shared an SBOM. For those vendors, the contract clauses, status request and evidence ladder above remain the method. Safeguard's Trust Center, for answering your own customers, is in early access.

Common mistakes

Trusting the banner. A Server header says nothing about backports, and some vendors hide or fake it.

Sending the same questionnaire to every vendor. Tier first, then send short, specific questions to the top tier.

Accepting "not affected" with no reason. One sentence of justification forces a real check.

Confusing "patch released" with "patch running." Ask when the fix reached your environment, and check that processes restarted.

Forgetting containers and embedded copies. A patched host can run an unpatched image, and appliances often bundle their own library copies.

Not recording silence. Unlogged requests and controls leave nothing to show an auditor.

Ignoring end of life components. Ask about support status, not just version.

FAQ

How do I check if my hosting provider has patched PHP?

Ask for the exact PHP package build serving your site and its deployment date, and compare it with the fixed build in the distribution's advisory. With shell access, check it yourself with dpkg -l or rpm -q. The upstream version alone is not enough, because distributions backport fixes.

Why does my scanner say a server is vulnerable when the vendor says it is patched?

Many scanners compare upstream version numbers, but Debian, Ubuntu and Red Hat often backport fixes into the old version. Check the full package build against the distribution advisory, or use a scanner that reads distribution advisories.

Is an SBOM enough to know if a vendor is affected?

No. An SBOM tells you whether a component is present and at what version. It does not tell you whether the vendor backported a fix or whether the vulnerable code can be reached. Pair the SBOM with an advisory or a VEX statement.

How long should a vendor take to respond to a critical vulnerability?

There is no universal legal deadline for every vendor. A reasonable contract target is acknowledgement within one business day and a clear status within two to three business days for critical, internet facing flaws, with faster action when the flaw appears in CISA's KEV catalog.

What should I put in a vendor contract about vulnerability notifications?

Include a duty to notify you of critical vulnerabilities, a deadline to answer status requests, remediation targets by severity, delivery of SBOMs and machine readable advisories, rules for subcontractors, incident assistance, and audit rights. Under DORA, several of these are mandatory for financial entities.

What do I do if a vendor does not reply about a critical CVE?

Check their public advisories first, then escalate through the contract contact and your account manager. Meanwhile reduce exposure yourself with firewall rules, access restrictions or isolation, record every attempt, and raise the vendor's risk rating.

How do I prove to an auditor that we checked vendors after a critical CVE?

Keep one dated record per vendor per vulnerability: how you decided the vendor was in scope, the request, the response, the evidence with its strength, your action and the residual risk decision. That maps to SOC 2 vendor management, ISO 27001 supplier and vulnerability controls, DORA Article 30 and NIS2 Article 21.

Where can I find a vendor's security advisories automatically?

Look for a security.txt file at /.well-known/security.txt, which may include a CSAF: field, and for a CSAF provider-metadata.json at /.well-known/csaf/provider-metadata.json. If the vendor publishes CSAF, you can poll its feed instead of emailing.

Fix it without waiting for upstream

Vendor confirmation covers the products you buy. The same question applies to the open source components you build and ship yourself, and for those you do not have to wait on anyone's reply.

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.

See how Safeguard would help

None of these demos is a vendor confirmation walkthrough, so each intro says how the flow carries over.

The first shows how to connect Claude to the Safeguard MCP server with OAuth and choose which tools Claude can use. Once connected, a risk manager can ask about platform data in plain language, for example which projects contain a given component, instead of building a report by hand.

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

The second is a real Safeguard CLI session: install, open the interactive terminal, and fix a lodash CVE, with the assistant asking before each command, moving package.json to lodash 4.17.21, running install and tests with approval and pushing nothing. The same CLI scans a supplier's SBOM file with safeguard scan --sbom vendor-sbom.cdx.json, a quick check of their component list before you send a request.

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

The third sets up the Safeguard runner on your own machine, approves it with its device code, then scans from the terminal. It suits teams that want scans of supplier SBOMs and internal images to run on hardware they control.

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

To try it on your own SBOMs and repositories, download Safeguard and read the CLI documentation. For related reading, see where to get patched open source: upstream, vendor or managed and using SBOMs in incident response to find affected products fast.

Quick check

Sources

• Ubuntu: php2shell vulnerability fixes available
• The Hacker News: PHP2Shell, two unpatched critical PHP flaws
• Debian security FAQ
• Red Hat: Backporting security fixes
• OpenVEX specification
• OASIS: Common Security Advisory Framework (CSAF) 2.0
• CISA: Minimum Requirements for Vulnerability Exploitability eXchange (VEX)
• CycloneDX: Vulnerability Exploitability eXchange use case
• CISA: Known Exploited Vulnerabilities catalog
• CISA: Secure by Design pledge
• DORA Article 30: Key contractual provisions
• NIS2 Directive Article 21: Cybersecurity risk management measures
• NIST SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management Practices
• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure (security.txt)

Last reviewed: 22 October 2026. Vendor advisories and regulatory guidance change; check the linked sources for the current position.