Answer CIP-013 Vendor Software Questions and Cut OT Exposure

When an auditor asks how your utility knows what is inside the vendor software running in your BES Cyber Systems, the defensible answer is a working loop, not a binder: get a software bill of materials (SBOM) and machine readable advisories from each in-scope vendor, verify the source and integrity of every package before it crosses the Electronic Security Perimeter, match the components against known and exploited vulnerabilities every time the data changes, and record a dated decision for each finding inside the 35 day patch cycle you already run. Your CIP-013 plan says what you will do; that loop is the evidence that you did it.

The first two thirds of this post work with whatever tools you have. Safeguard enters at "How Safeguard does this". Nothing here is legal or audit advice; read each NERC standard and your Regional Entity's guidance alongside it.

Key takeaways

• CIP-013-2 R1 asks for documented processes covering vendor disclosure of known vulnerabilities (Part 1.2.4) and verification of software integrity and authenticity for all vendor software and patches (Part 1.2.5). R2 asks you to implement them, and R3 asks for a review every 15 calendar months.
• The evidence for those parts mostly lives elsewhere: CIP-010-4 R1 baselines (Part 1.1) and pre-change source and integrity checks (Part 1.6), and CIP-007-6 R2 patch evaluation every 35 calendar days with a dated action within the next 35 days.
• FERC Order No. 912 (issued 18 September 2025, effective 24 November 2025) directs NERC to strengthen the supply chain standards on plan sufficiency and on protected cyber assets. It declined to require validation of vendor data but encourages it voluntarily.
• An SBOM and a CSAF or VEX document from each vendor turn "disclosure of known vulnerabilities" from an email thread into data you can check. CISA's 2026 Minimum Elements add component hashes, which line up with integrity verification.
• In Safeguard: TPRM (GA), SBOM upload and analysis (GA), CSAF and VEX upload (GA), vulnerability management with EPSS and KEV (GA), policies and gates with Block, Warn and Notify (GA), the compliance suite's NERC CIP framework (GA), the Portal SBOM repository (GA), and air-gapped deployment with Zero AI mode (GA).
• Safeguard does not analyse firmware binaries or appliance images. You bring the SBOM your vendor or your build produces.

The situation

You run OT security for a utility with transmission and some generation. Your high and medium impact BES Cyber Systems run on vendor software: an energy management system, relay engineering tools, a historian, RTU configuration software, jump hosts and access control systems (EACMS and PACS), plus integration services your own engineers wrote.

The trigger is a set of questions that arrive together. An audit notification lands with a request for evidence under CIP-013-2 R2, and the sample asks you to show how you received vendor vulnerability disclosures and verified software integrity for the patches installed in the last audit period. Your procurement team is negotiating a new substation automation contract and wants to know what to ask the vendor for. And your CIP Senior Manager has read about Order No. 912 and wants to know whether the plan you approved last year will still hold when NERC's revised standard arrives.

A bad week looks like this. Vendor advisories arrive as PDFs. Your patch tracker says you evaluated the quarterly update, but not which components it changed. The hash for the last installer came from the same page as the installer. Two vendors have never sent an SBOM. And a CISA ICS advisory names a library you suspect sits inside your historian, but the only way to find out is to call the vendor. That is what happens when vendor software is tracked as a product name and a version, and the components inside it are invisible.

The rules behind the questions

The quotations below are short and the clause numbers come from the standards as published by NERC. Your Regional Entity's audit approach and any Reliability Standard Audit Worksheet (RSAW) for your audit are what actually set expectations, so treat this as a map, not an interpretation.

CIP-013-2: the supply chain plan

CIP-013-2 applies to high and medium impact BES Cyber Systems and their associated EACMS and PACS. R1 requires one or more documented supply chain cyber security risk management plans. Two parts of R1 matter most for vendor software:

• Part 1.1 asks for processes used in planning procurement to identify and assess cyber security risks from vendor products or services, both from procuring and installing vendor equipment and software and from moving between vendors.
• Part 1.2 lists six topics your procurement processes must address, as applicable. For software, the important ones are 1.2.4, disclosure by vendors of known vulnerabilities related to the products or services provided to you, and 1.2.5, verification of software integrity and authenticity of all software and patches provided by the vendor for use in the BES Cyber System and associated EACMS and PACS. Parts 1.2.1 and 1.2.2 cover vendor incident notification and coordinated response, 1.2.3 covers revoking vendor access, and 1.2.6 covers vendor remote access.

R2 requires you to implement the plan. The standard's note is worth reading twice: implementation does not require renegotiating existing contracts, and the actual terms of a contract and the vendor's performance against it are outside the scope of R2. In practice that means your evidence is about what you did: what you asked for, what you received, how you checked it and what you decided. R3 requires review and CIP Senior Manager (or delegate) approval at least once every 15 calendar months. The compliance section asks you to retain evidence for three calendar years.

CIP-010-4: baselines and pre-change verification

CIP-010-4 is where vendor software becomes concrete. R1 Part 1.1 requires a baseline configuration that includes the operating system or firmware where no independent operating system exists (1.1.1), any commercially available or open-source application software including version (1.1.2), any custom software (1.1.3), logical network accessible ports (1.1.4) and security patches applied (1.1.5).

Part 1.6 applies to high impact systems and to medium impact systems, with their EACMS and PACS. Before a change that deviates from the baseline for items in Parts 1.1.1, 1.1.2 and 1.1.5, and when the software source makes a method available, you verify the identity of the software source (1.6.1) and the integrity of the software obtained from it (1.6.2). The measure accepts a change record that shows the verification happened before the change, or a documented automatic mechanism.

R3 Part 3.1 adds a paper or active vulnerability assessment at least once every 15 calendar months.

CIP-007-6 R2: the 35 day patch clock

CIP-007-6 R2 is the cadence most OT teams already live by. Part 2.1 requires a patch management process that identifies the sources you track for patches. Part 2.2 requires evaluating security patches for applicability at least once every 35 calendar days. Part 2.3 requires, within 35 calendar days of the evaluation, applying the patch, creating a dated mitigation plan or revising an existing one. Part 2.4 requires implementing each mitigation plan within its stated timeframe unless the CIP Senior Manager or delegate approves a revision or extension.

The link to supply chain is direct: the "sources" in Part 2.1 are usually your vendors, and the quality of what they send decides how much of Part 2.2 is real evaluation and how much is reading release notes.

CIP-005-7 R2 Parts 2.4 and 2.5 (vendor remote access) belong in the same vendor file, but they are access controls, so this post leaves them aside.

FERC Order No. 912: what is coming

On 18 September 2025 FERC issued Order No. 912, effective 24 November 2025. It directs NERC to submit new or modified Reliability Standards that address the sufficiency of responsible entities' supply chain risk management plans for identifying and responding to supply chain risks, and the applicability of the supply chain standards to protected cyber assets (PCAs). The order names CIP-005-7, CIP-010-4 and CIP-013-2 as the current supply chain standards. It gives NERC 18 months; the order's opening paragraph counts from issuance and a later paragraph from the effective date, so watch NERC's project page for the actual filing.

FERC declined to require entities to validate data received from vendors, but encouraged them to do so voluntarily. Checking a vendor SBOM against independent vulnerability data is that kind of validation, and you can start now.

The formats that make vendor data checkable

Three documents carry the data you need.

• SBOMs. CISA's 2026 Minimum Elements for a Software Bill of Materials, released on 29 July 2026 with NSA, FBI and international partners, replaces the NTIA 2021 minimum elements. It adds a component hash value and hash algorithm, an SBOM author signature, tool name and version, SBOM version and generation context, and component license, and it updates the author, producer, identifier and version elements. It notes that components can include firmware. The hash elements matter for CIP-010 Part 1.6, because a hash the producer publishes inside a signed SBOM is a second channel for integrity checks.
• CSAF advisories. The OASIS CSAF 2.0 standard defines machine readable security advisories. CISA publishes its IT and OT advisories in CSAF in its CSAF repository, and republishes vendor CSAF files too. If a vendor gives you CSAF, a new advisory is a file you can match against your inventory rather than a PDF you read.
• VEX. A VEX statement says whether a product is affected by a given vulnerability. CSAF 2.0 has a VEX profile with product status values such as known affected, known not affected, fixed and under investigation, and machine readable justification flags such as vulnerable_code_not_present and component_not_present. CISA's Minimum Requirements for VEX (April 2023) sets out the minimum fields. VEX is how a vendor tells you a scary match does not apply, in a form you can keep as evidence.

NIST's SP 800-82 Rev. 3 (OT security, September 2023) and SP 800-161 Rev. 1 (supply chain risk management) are not mandatory under NERC but are good sources of plan language.

How teams handle vendor software today, and where it breaks

Most utilities meet CIP-013 with a procurement questionnaire, contract language and a vendor contact list. That satisfies R1 well enough. The trouble starts at R2, where you must show the plan running.

The deeper problem is a mismatch of units. Your compliance program counts products; vulnerabilities live in components. Without component data, every library advisory becomes a round of vendor calls, and your Part 2.2 evaluation becomes a record of who you called.

Step by step: build the vendor software loop

These steps work with any tooling. Where a step needs a tool, it names the category, not a product.

1. Scope the vendor list from your BES Cyber System inventory

Start from your CIP-002 categorization, not accounts payable. For each high and medium impact BES Cyber System and its EACMS, PACS and (given Order No. 912) PCAs, list every vendor whose software or firmware is installed, including field device configuration tools.

Tier each vendor by what its software does in the system:

Write down why each vendor sits where it does; that reasoning is Part 1.1 evidence.

2. Ask for the right artifacts, in writing

Ask critical and high tier vendors for four things, and keep a copy: the request itself is R2 evidence.

1. An SBOM per product release in CycloneDX or SPDX, meeting CISA's 2026 Minimum Elements, with component hashes where the vendor has access to the executables, and signed by the SBOM author if they can.
2. Security advisories in CSAF 2.0, or at least a machine readable feed, with product identifiers that match the SBOM.
3. VEX statements for vulnerabilities that match components in the SBOM but do not affect the product, with a justification.
4. A published method for integrity verification of software and patches: a signing key or certificate published through a channel other than the download page, or hashes delivered inside the signed SBOM or advisory.

A request template that works:

Subject: Software transparency request for [product], [version]

As part of our supply chain cyber security risk management plan, please provide
by [date, 30 days out]:

1. An SBOM for [product] [version] in CycloneDX (1.4 or later) or SPDX (2.2 or later),
   meeting the CISA 2026 Minimum Elements, including component hashes where available.
2. Your security advisories for this product in CSAF 2.0, or the URL of your CSAF feed.
3. VEX statements (CSAF VEX profile, CycloneDX VEX or OpenVEX) for any known
   vulnerabilities in listed components that do not affect this product.
4. The method we should use to verify the source and integrity of software and
   patches you provide, delivered through a channel separate from the download.

If you cannot provide an item, please tell us when you expect to, or what you can
provide instead. We will update our records with your reply.

Firmware for relays, RTUs and controllers belongs in the same request. If the vendor cannot produce a firmware SBOM, record that and lean on its advisories and integrity method. An SBOM from the producer's own build beats one reconstructed later from a binary.

3. Check what comes back before you trust it

Treat every SBOM as a claim to test. Before it goes into your records, check:

• Validity. Does it parse against the CycloneDX or SPDX schema it claims?
• Identity. Does it name the product and version you actually run? Does the SBOM author match the vendor?
• Completeness. Do components carry versions and package identifiers (PURL or CPE)? CISA's elements call for specific versions, and a range or placeholder defeats CIP-010 baseline monitoring.
• Hashes. Are component hashes present, with the algorithm named?
• Signature. If signed, does the signature verify against a key you got from somewhere other than the file?
• Age. When was it generated, and against which build?

Return incomplete SBOMs with a specific reason. A dated rejection is good R2 evidence; a silently accepted bad SBOM is not.

4. Match components to vulnerabilities, and rank by exploitation

Run the accepted SBOM against vulnerability data from more than one source (NVD, the GitHub advisory database, OSV) and enrich each match with exploitation signals: the CISA Known Exploited Vulnerabilities catalog and an EPSS score. Then apply the vendor's VEX statements, so that matches the vendor has marked not affected, with a justification, are separated from the rest.

Rank what remains in this order: known exploited first, then high EPSS, then severity. Severity alone puts too many findings at the top of an OT list where most findings cannot be patched quickly anyway.

5. Decide each finding inside the CIP-007 clock

For every remaining finding on a critical or high tier product, the decision options mirror CIP-007-6 Part 2.3:

The last row is easy to miss: adapters and scripts your engineers write around vendor systems are your software, and their dependencies are yours to fix.

6. Verify source and integrity at the moment of change

At install time, do the CIP-010 Part 1.6 checks against the method the vendor gave you: verify the signature or compare the hash from the separate channel, and compare the components in the new release's SBOM to the old one. A component diff between two SBOM versions is a practical way to see what the patch really changed, and it catches surprises such as a new third-party library in a "maintenance" release.

7. Monitor between releases

Vulnerability data changes daily; vendor releases come quarterly at best. Re-match stored SBOMs on a schedule (daily for critical vendors) and alert on a new critical match or a CISA KEV addition. Each alert starts a Part 2.2 evaluation.

8. Close the loop at plan review

At each R3 review, bring the CIP Senior Manager three things: which vendors provided which artifacts, how findings were decided, and which vendors did not respond. That makes the review a decision about the program, which is the direction Order No. 912 points.

Illustrative scenario: a transmission owner's substation and EMS vendors

This is a composite example, not a customer. The utility, its vendors and every number below are invented to show the workflow; the numbers are example inputs, not results.

Utility X is a fictional transmission owner and operator with a control center, a backup control center and about 60 substations, some of which contain medium impact BES Cyber Systems. Its OT security lead keeps a list of 14 vendors with software in scope: an EMS vendor, two protection relay vendors whose engineering tools run on workstations in the control center, an RTU vendor, a historian vendor, a jump host vendor, a physical access control vendor and seven smaller ones.

The trigger is an audit notification that samples CIP-013-2 R2 evidence for the last three patch cycles on the EMS and the historian, plus a procurement team about to sign a substation automation contract.

Weeks one and two. The lead maps the 14 vendors to systems from the CIP-002 list, adds PCAs, tiers them (4 critical, 5 high, 5 medium) with a reason for each, and sends the request template to the 9 critical and high vendors with a 30 day deadline. The new contract gets the same four items in its security schedule.

Week four. 5 vendors send an SBOM, 2 send CSAF, 1 sends VEX, 4 send nothing yet. One SBOM fails schema validation and one lacks versions; both go back with the reason.

Week five. After VEX and sorting by KEV and EPSS, a short list remains, two on the KEV catalog. One is fixed in a scheduled vendor patch; the other gets a dated mitigation plan.

Ongoing and at audit. Monitoring runs daily on critical vendors' SBOMs, and a new ICS advisory becomes a search of stored SBOMs rather than phone calls. The evidence pack for sampled cycles shows request, SBOM, validation result, findings, VEX, dated decisions and pre-change integrity checks, plus requests and follow ups for vendors who did not respond.

Nothing here proves compliance; that is the Regional Entity's call. It shows a plan producing the records the measures describe.

How Safeguard does this

This section uses only Safeguard's offering documentation and docs.safeguard.sh; every capability named is generally available (GA), and screens and commands appear only where the docs show them. The summary page is the eliminate vulnerability exposure use case.

1. Decide where Safeguard runs

Many utilities will not let OT inventory data leave their environment. Safeguard's deployment options (GA) are SaaS, private VPC or dedicated tenancy, full on-prem, and fully air-gapped. The air-gapped deployment docs describe a signed snapshot bundle (vulnerability feed deltas from sources including NVD, the GitHub advisory database, OSV, CISA KEV and EPSS, plus policy template updates and platform binaries) delivered into your perimeter by a channel you choose, including a one-way diode, signed removable media, a scheduled DMZ sync or a pull replica, at a cadence from hourly to quarterly. A receiver in the DMZ verifies signatures, and no component inside the perimeter calls outbound.

Zero AI mode (GA) runs the platform with no LLM at all. Safeguard is designed for FedRAMP High and has a SOC 2 Type II audit in progress; neither is a NERC statement, and your CIP program decides where the platform sits.

2. Build the vendor directory in TPRM

TPRM, Safeguard's Third-Party Risk Manager (GA), keeps the vendor list. The vendor management docs show the flow: go to Vendors, click Add Vendor, enter the company, contact, website and products used, set a risk tier, and save. Tiers are Critical, High, Medium and Low; TPRM can suggest a tier from data access, system criticality, user count and compliance requirements, and a manual override asks you to document the justification. A CSV bulk import exists for an existing list. Each record tracks contract status, SBOM status and last assessment.

The TPRM overview suggests SBOM expectations per tier, which you can adjust.

3. Send SBOM requests and track them

From a vendor, click Request SBOM, choose products and a template, set a deadline and send; Bulk Request does the same for several vendors at once (SBOM requests docs). The standard template asks for SPDX or CycloneDX and the fields required for EO 14028; custom templates live under Settings → Request Templates, so you can add the CSAF, VEX and integrity method asks from the template above.

Each request moves through Sent, Viewed, In Progress, Submitted, and then Validated or Rejected. Automated reminders go out 7 days before the deadline and at the deadline, with an escalation 7 days after. Vendors can submit by email attachment, a secure upload portal, API or direct integration. That status history is the kind of correspondence the CIP-013 M2 measure lists as implementation evidence.

4. Upload and validate the SBOM

For SBOMs you already hold, the existing SBOM docs describe the upload: go to Integrations, click Connect on the Upload SBOM card, enter project name, version and format, then drop the file. Supported inputs are CycloneDX 1.3 to 1.6 and SPDX 2.2 and 2.3, plus JSON output from some common open source SBOM and scanning tools, which the docs list by name. The docs note that the /v1 REST upload path shown on that page is not yet available, so use the UI.

After upload, Safeguard validates format, schema, required fields and component data quality, then enriches the SBOM with vulnerability matches, EPSS scores, CISA KEV status, license and supplier data. The docs show quality metrics after upload: completeness, component coverage, PURL accuracy, version specificity and license coverage. Those map well to the step 3 checks and give you a recorded reason when you return an SBOM to a vendor.

The docs' best practices match step 3: verify the SBOM came from the vendor and check signatures if present. Deciding authenticity stays your step.

On an engineering workstation, including one with no route to the platform, the Safeguard CLI (GA) can check and scan a vendor SBOM locally, as the CLI usage docs show:

# Check the document against its specification
safeguard validate sbom.json

# Validate a folder of vendor SBOMs and keep a report
safeguard validate ./sboms --recursive
safeguard validate sbom.json --strict -o report.json

# Scan it for vulnerabilities, writing results under ./output
safeguard scan --sbom sbom.json

The docs say validate checks CycloneDX, SPDX and VEX (CSAF and OpenVEX) documents against their specifications, and that scan --sbom writes vuln.json, license.json and collection.json under ./output. The CLI does not upload SBOMs to the platform; that happens in the UI. These commands are shown as the docs give them and were not run for this post.

5. Bring in vendor advisories and VEX

The CSAF and VEX upload docs accept CSAF 2.0, CycloneDX VEX, OpenVEX and the CSAF VEX profile. In Integrations, filter by Upload, click Connect on the Upload CSAF/VEX card, name the upload, drop the file, then set the project name and version. The docs describe two uses that match this workflow: importing vendor security bulletins and CVE advisories in CSAF to track vulnerabilities that affect your software, and uploading VEX to mark vulnerabilities as not affected, document mitigation status and reduce false positives.

6. Score and compare vendors

TPRM risk assessment (GA) gives each vendor a 0 to 100 score where higher is better, built from vulnerability risk (critical and high counts, EPSS, known exploited vulnerabilities), compliance risk (EO 14028 field coverage, missing fields, SBOM age, format validity), component risk and operational risk such as response time to requests (risk assessment docs). Generate Report produces an executive summary, score breakdown, vulnerability details, compliance gaps and recommendations, and you can compare vendors side by side.

Accept Risk records a justification, a review date and approvals, a natural home for a dated decision on a finding the vendor cannot fix yet. Remediation tracking records vendor commitments and progress, the vendor side of a CIP-007 mitigation plan.

7. Turn your rules into policies and gates

Policies and gates (GA) let you express "no known exploited vulnerability accepted without a decision" as a rule. The policies and gates docs show the builder under Settings → Policies: click Create Policy, define conditions with the visual builder or YAML, set severity and an action, then save and enable. Example conditions in the docs include no critical CVEs and no vulnerabilities above CVSS 7.0, and plain English policy creation (GA) lets you describe the rule in words.

Each policy has one action when it fails, as the policy outcomes docs set out: Block fails the gate, Warn passes it with a warning naming the policy, and Notify passes it and sends a notification to your configured channels. A policy is evaluated when it is linked to a gate and again after new assessment data arrives for the product, so a fresh vulnerability match on a stored vendor SBOM re-evaluates the gate without anyone re-running a scan. Exceptions run through a separate workflow: request with a justification and an expiry, approver decision, audit trail. The docs note that policy outcomes are switched on per workspace by Safeguard, so ask if you do not see an Outcome column.

For vendor products, a failed Block gate signals that a release should not enter your change process until someone decides. Safeguard does not sit in your OT change path and cannot stop an installer; the gate result feeds the decision you record. For your own integration services, gates can run in CI with safeguard ci scan --wait --fail-on-gate plus the gate name, as the docs describe, which fails the job when the gate fails.

8. Monitor between releases

TPRM monitoring (GA) watches stored vendor SBOMs for new vulnerabilities, severity changes, exploit availability updates, CISA KEV additions and component health changes (monitoring docs). Under Settings → Monitoring you set alerts for a new critical CVE, a KEV addition, a risk score dropping below a threshold and an SBOM older than a threshold. Re-scans can run daily, weekly, monthly or quarterly, and re-assessment can trigger on new disclosures, major version updates, contract renewals and security incidents. Alerts go to channels such as email, Slack, Teams, PagerDuty or a webhook.

Each KEV alert is a prompt to open a CIP-007 Part 2.2 evaluation; it decides nothing on its own.

9. Compare versions at change time

The Portal (GA, here meaning the SBOM publish and share product, not the free entry tier) keeps an SBOM repository with versions, tags and comparison. The SBOM repository docs show Compare: pick two versions of the same product and see added and removed components, version changes, new vulnerabilities and resolved vulnerabilities. Run it on the old and new vendor SBOMs before a patch goes into a change ticket, and attach the result. It is a quick way to check that a patch fixed what the advisory said and did not add anything unexpected.

10. Map the evidence to NERC CIP

The compliance and GRC suite (GA) includes a NERC CIP framework. Its scan requirements check each product's software inventory for things the standards presuppose: a component inventory for the CIP-010 R1 baseline, versions on components (and specific versions rather than ranges), integrity hashes for CIP-010 Part 1.6 and CIP-013 Part 1.2.5, known suppliers for CIP-013 R1, and components identifiable against patch and vulnerability sources for CIP-007 R2. The framework also lists catalog controls across the CIP family and NERC-specific policy templates, including a supply chain risk management policy. You evidence the controls with automated tests, uploaded evidence, policies or an attestation.

Read those as data quality checks: they show whether the inventory can support the requirement, not whether you met it.

11. Fix what is yours

For integration code your engineers own, autonomous remediation (GA) can open tested, policy gated fix pull requests through Griffin, single or in bulk. It ships switched off, with every category set to Manual, so nothing changes until you turn it on and choose a strategy. It applies to source you build, never to a vendor's product.

What to measure

Measures to track in your own program, not promised outcomes.

• Coverage. Share of critical and high tier vendors with a current SBOM (generated against the release you run) on file.
• Artifact quality. Share of accepted SBOMs with versions on all components, package identifiers and component hashes.
• Advisory format. Number of vendors providing CSAF or another machine readable advisory feed.
• VEX use. Number of matched findings closed with a vendor VEX statement, and how many of those you challenged.
• Clock health. Days from a KEV addition affecting a stored SBOM to a recorded CIP-007 Part 2.3 decision.
• Integrity checks. Share of changes in the period with a recorded pre-change source and integrity check under CIP-010 Part 1.6.
• Vendor responsiveness. Median days from SBOM request to submission, and the list of vendors who have not responded.
• Mitigation plan aging. Open mitigation plans past their target date, and extensions approved.

What Safeguard does not do

• It does not analyse firmware binaries, appliance images or controller logic. Safeguard works from the SBOM your vendor or your build produces, plus advisories and VEX. If the vendor cannot provide an SBOM for a relay firmware image, Safeguard cannot build one from the image.
• It does not scan your OT network or field devices. It is not a passive network monitor, asset discovery tool for industrial protocols or intrusion detection system for the ESP. Keep those programs separate.
• It does not verify a vendor's signature for you at install time. The CIP-010 Part 1.6 check happens in your change process against the vendor's method. Safeguard stores SBOMs that may carry hashes and shows component changes between versions; your technician still verifies the file being installed.
• It does not patch vendor software. Remediation pull requests apply to code you build. A fix inside an EMS, historian or relay tool has to come from the vendor.
• It does not make you compliant or answer for you in an audit. The NERC CIP framework checks data quality and maps evidence. The CIP Senior Manager approves the plan, your team writes the decisions, and your Regional Entity judges compliance.

Common mistakes

• Starting from the procurement vendor list. Start from CIP-002 categorization, with EACMS, PACS and PCAs.
• Accepting any SBOM. Without versions and package identifiers it cannot be matched. Return it with the missing element.
• Trusting the download page hash. Same channel as the file, so it proves little. Ask for a separately published key.
• Treating every match as a patch request. Apply VEX, sort by KEV and EPSS, and challenge weak justifications.
• Forgetting your own code. Adapters and scripts around vendor systems carry their own dependencies, and no vendor will fix them.
• Recording decisions in email. Auditors sample dated decisions with owners; keep them where history is kept.
• Waiting for the Order No. 912 standard. The current standards already ask for disclosure and integrity verification.

FAQ

Does CIP-013 require an SBOM from vendors?

No. CIP-013-2 does not name SBOMs. It requires processes addressing vendor disclosure of known vulnerabilities (Part 1.2.4) and software integrity verification (Part 1.2.5). An SBOM with CSAF and VEX is one practical way to make that disclosure checkable.

What does CIP-013-2 Part 1.2.5 ask for?

Processes, used in procuring BES Cyber Systems and their EACMS and PACS, that address verification of software integrity and authenticity for all software and patches the vendor provides. The day-to-day check happens under CIP-010-4 Part 1.6, before a change that deviates from the baseline, when the vendor makes a method available.

What changed with FERC Order No. 912?

Order No. 912 (issued 18 September 2025, effective 24 November 2025) directs NERC to develop standards on the sufficiency of supply chain plans and on protected cyber assets within 18 months. The current standards stay in force until revisions are approved.

How do I handle OT vendors who will not provide an SBOM?

Record the request, the follow ups and the response. Ask for what they can give instead: CSAF advisories, a component list for the affected product, or a date for an SBOM. Write the SBOM into the next contract or renewal, and treat their products as higher uncertainty in your patch evaluation.

Can an SBOM cover firmware?

Yes. CISA's 2026 Minimum Elements note that components can include firmware, and both CycloneDX and SPDX can describe it. Whether you get one depends on the vendor. Safeguard does not create SBOMs from firmware images, so the SBOM has to come from the vendor or its build.

What is VEX, and should I trust a vendor's VEX?

VEX is a machine readable statement of whether a product is affected by a vulnerability, with a justification when it is not. Treat it as evidence from the vendor, not as proof. Accept justifications that are specific, such as the component not being present, and ask questions when a critical KEV entry is marked not affected without detail.

How does Safeguard help with CIP-013 vendor software questions?

TPRM holds vendors and SBOM requests; uploaded SBOMs are validated and enriched with EPSS and KEV data; CSAF and VEX are ingested; policies act with Block, Warn or Notify; monitoring flags new critical or exploited vulnerabilities; and the NERC CIP framework checks inventory quality. It does not decide compliance.

Can Safeguard run inside an air-gapped utility environment?

Yes. Air-gapped deployment is GA, with signed snapshot bundles delivered by a channel such as a one-way diode or signed media, and Zero AI mode if you want no model inference.

Where remediation fits

Most of this post is about vendor software you cannot change, but the same CIP-007 clock covers the integration services and scripts your own engineers build around those systems. For that code, the options below shorten the time between a published fix and a running one.

Fix it without waiting for upstream

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 categories include dependencies, licenses, security posture and findings, and each one is set separately. 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.

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

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) 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. 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

The first demo shows the local runner: you set it up on your own machine, approve it with its device code, then scan from the terminal. For a utility, that is the pattern for scanning integration code on a workstation you control, with results going back to the platform rather than your source.

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

The second demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. For an OT security lead, it is a way to ask plain language questions of the vendor and SBOM data already held in Safeguard, with access limited to the tools you allow.

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

The third demo is a real Safeguard CLI session: asked to fix a lodash CVE in a repository, the CLI reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. It does not touch vendor software; it shows what fixing your own integration code looks like.

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

Quick check

Related reading

• NERC CIP and the utilities software supply chain
• VEX, the vulnerability exploitability exchange, explained
• Firmware supply chain security guide
• Onboard a new software vendor at an insurer, starting with the SBOM
• Auto-fixing vulnerable dependencies in a manufacturing MES

Sources

• NERC: CIP-013-2, Cyber Security, Supply Chain Risk Management
• NERC: CIP-010-4, Configuration Change Management and Vulnerability Assessments
• NERC: CIP-007-6, Systems Security Management
• NERC: CIP-005-7, Electronic Security Perimeter(s)
• Federal Register: FERC Order No. 912, Supply Chain Risk Management Reliability Standards
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• CISA: Software Bill of Materials
• CISA: Minimum Requirements for VEX
• CISA: CSAF repository
• CISA: ICS advisories
• OASIS: Common Security Advisory Framework Version 2.0
• NIST SP 800-82 Rev. 3, Guide to Operational Technology Security
• NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
• Safeguard docs: Third Party Risk Manager
• Safeguard docs: Vendor management
• Safeguard docs: SBOM requests
• Safeguard docs: Risk assessment
• Safeguard docs: Monitoring
• Safeguard docs: Existing SBOM integration
• Safeguard docs: CSAF/VEX upload
• Safeguard docs: Policies and gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: SBOM repository
• Safeguard docs: CLI usage
• Safeguard docs: NERC CIP framework
• Safeguard docs: Air-gapped deployment
• Safeguard: Eliminate vulnerability exposure use case

To try the flows above, download Safeguard at safeguard.sh/download and read the docs at docs.safeguard.sh.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.