A vulnerable dependency in oil and gas vendor software: what do you do?

When a scan flags a vulnerable library inside vendor software on a rig, platform or plant, you usually cannot upgrade it yourself. The right sequence is: confirm it is really there, ask the vendor whether the flaw affects the product, check exposure, add compensating controls, then patch in a planned window.

This is a decision path, not a description of any event. It uses NIST and ISA/IEC 62443 guidance and CISA's definitions of SBOM and VEX. Process safety decisions stay with the people who own the process.

Why can't you just update it?

The software belongs to the vendor, who tested the whole product with the library version it ships. Swapping one component can break behavior, void support or invalidate testing. ISA/IEC 62443 reflects this split: product suppliers build and maintain secure products, integrators build and maintain solutions, and asset owners run them. Part 4-1 covers secure product development lifecycles for suppliers, and other Part 2 documents address patch management.

So your influence is information, controls and contracts, rather than editing code.

Step 1: Is it real?

A flagged component can be a false match: a similar package name, a library present but unused or a version string that was backported. Ask where the finding came from. If it came from your scan of a vendor SBOM, check the SBOM's version against the advisory. A software bill of materials is, in CISA's words, "a list of ingredients that make up software components." A mismatch between SBOM and what is installed is itself a finding.

Step 2: Ask for VEX

CISA describes a Vulnerability Exploitability eXchange as "an attestation, a form of a security advisory" indicating whether products are affected by known vulnerabilities. Ask the vendor: is this product affected? If not, why, for example because the vulnerable function is never called. If yes, what is the fix and when. A reasoned "not affected" statement can close the item. Silence moves you to the next steps.

Step 3: What is the exposure?

Questions to answer with your own network team:

• Can the vulnerable service be reached from outside its zone?
• Does it face the internet, a business network, a vendor remote link or only a local control network?
• Does exploiting it need credentials, user action or physical access?
• Is the flaw on CISA's Known Exploited Vulnerabilities list? That list is described as the authoritative source of flaws exploited in the wild and a good input to prioritization. A listed flaw on a reachable system moves up the queue.

Step 4: Compensate

NIST's OT guide recommends countermeasures chosen with performance, reliability and safety in mind. Typical options: tighten firewall rules between zones, disable the affected service if it is not needed, restrict remote access and require approval and logging for vendor sessions, and add monitoring on traffic to the system. Confirm any change with the vendor so it does not disturb operation.

Step 5: Patch in a window

When the vendor ships a fix, test it where possible, schedule it with operations for a planned outage, keep a rollback and record the result. Re-scan afterward and update the register.

Step 6: Record the decision

For every flagged item, record: component, system, finding date, vendor statement, exposure, controls, decision and review date. An auditor or insurer will ask for this, and your future self will too.

How do tools fit in?

Safeguard's CLI can scan an SBOM in SPDX or CycloneDX form against its advisory database and write findings per component, which gives you the list to take to the vendor. It does not decide exploitability on the vendor's product. Treat it as the way to turn "we have a pile of SBOMs" into "here are the eleven items to ask about."

What to do

1. Collect SBOMs for vendor software on each site, and note the version installed.
2. Scan them and list flagged components.
3. Verify each finding against what is installed.
4. Send the vendor a list and request VEX statements and patch timelines.
5. Check exposure and KEV status, and rank items.
6. Apply compensating controls, with vendor agreement.
7. Schedule patches for planned windows.
8. Keep the decision register and review it monthly.
9. Add SBOM and VEX delivery to your next contract renewal.

Quick check

Sources

• CISA: Software Bill of Materials
• CISA Known Exploited Vulnerabilities Catalog
• NIST SP 800-82 Rev. 3, Guide to Operational Technology Security
• ISA/IEC 62443 series of standards
• Safeguard CLI documentation

Last reviewed: 18 October 2026.