Oil and gas pipeline software supply chain security: a 90-day plan

Oil and gas pipeline operators secure their software supply chain by doing four things in order: list every piece of software inside their Critical Cyber Systems, get a component inventory (an SBOM) and an advisory feed from each control system vendor, rank patches with CISA's Known Exploited Vulnerabilities catalog as the TSA directive requires, and write down the compensating measures for OT systems that cannot be patched. The rules behind this are TSA Security Directive Pipeline-2021-02G (in force from 3 May 2026 to 2 May 2027), SD Pipeline-2021-01G, API Standard 1164 and the IEC 62443 series, with a TSA rule proposed in 2024 that would add explicit supply chain contract terms.

This guide is written for the people at a pipeline or LNG operator who carry that work: the CISO, the head of pipeline control or OT engineering, the TSA Cybersecurity Coordinator and compliance lead, procurement and vendor risk, and the field and control room IT team. The first two thirds work with whatever tools you already run. Safeguard enters at "How Safeguard does this". Nothing here is legal or regulatory advice; your TSA-approved plan and your counsel decide what applies to you.

Key takeaways

• The binding text is TSA SD Pipeline-2021-02G. Section III.E requires a patch management strategy for Critical Cyber Systems, a risk methodology for patch criticality, priority for everything on CISA's KEV catalog, and documented additional mitigations where an OT system cannot be patched without severe degradation.
• TSA can ask for your software inventory. Section IV.C.2.a of SD-02G lists a hardware and software asset inventory, including SCADA systems, among the records TSA may inspect.
• Supply chain contract terms are coming, but not final. TSA's November 2024 proposed rule (proposed 49 CFR 1586.215 for pipelines) would require vendors to notify you of incidents and confirmed vulnerabilities, and would require a cybersecurity evaluation of vendors. As of 25 October 2026 no final rule has appeared in the Federal Register.
• Recent public incidents touched both sides. 2024 company filings describe business application outages; federal advisories describe state actors in energy IT networks and attacks on exposed PLCs.
• The vendor is half your supply chain. CISA's January 2025 Secure by Demand guide for OT buyers tells owners to ask manufacturers for an SBOM, CSAF advisories, verifiable updates and published end of life dates.
• Safeguard capabilities in this post, all GA: SBOM generation and analysis (GA), SCA and vulnerability management with EPSS and KEV (GA), reachability analysis (GA), TPRM with SBOM requests and vendor monitoring (GA), CSAF and VEX upload (GA), policies and gates with Block, Warn and Notify plus exceptions (GA), the compliance and GRC suite with TSA SD, IEC 62443 and NIST SP 800-82 framework pages (GA), the CLI and local runner (GA), air-gapped and on-prem deployment (GA), Zero AI mode (GA) and autonomous remediation, which ships switched off (GA).

What software an oil and gas pipeline company runs

A pipeline company's software splits into four groups, and each reaches you through a different supply chain.

Pipeline control and SCADA. The control room runs a SCADA host, operator HMIs, a historian and the front end that polls remote terminal units (RTUs) at compressor, pump, meter and valve sites. It is bought from industrial vendors, runs for a decade or longer, and arrives as an installer or appliance whose open source contents you rarely see.

Field devices and their engineering software. PLCs, RTUs, flow computers, gas chromatographs and safety instrumented systems carry vendor firmware and engineering tools. Updates usually need an outage window, a site visit or both.

Pipeline operations applications. Leak detection, gas control and nominations, measurement and custody transfer, integrity management, GIS and the interfaces that move historian data to the business side. Many are glued together with in-house code that pulls open source packages from npm, PyPI, Maven or NuGet.

Enterprise and partner IT. ERP, billing, scheduling and shipper portals, the electronic bulletin boards that interstate gas pipelines run for shippers, field mobility apps, and the managed service providers and integrators who touch all of it. The 2024 company filings below describe incidents on this side.

The TSA directives deliberately cover both sides. SD-02G defines a Critical Cyber System as any information or operational technology system or data that, if compromised or exploited, could result in operational disruption, and it says that includes business services. So a billing system that would stop product moving if it went down can be in scope alongside the SCADA host.

Where the software supply chain risk sits

The regulations and frameworks that apply

The rules below are the ones a US pipeline or LNG operator meets most often. Dates were checked on the primary source on 25 October 2026.

TSA Security Directive Pipeline-2021-02G: mitigation actions, contingency planning and testing

TSA reissues the SD-02 series each year. The current version, SD Pipeline-2021-02G, is dated 1 May 2026, is effective 3 May 2026 through 2 May 2027, and cancels and supersedes SD-02F. TSA's transmittal memo says there are no substantive revisions in this renewal; the changes are limited to dates, the series letter and formatting. It applies to owner/operators of TSA-designated hazardous liquid and natural gas pipelines and liquefied natural gas facilities, and TSA notifies any newly designated operators of their deadlines.

The directive requires three plans. A TSA-approved Cybersecurity Implementation Plan describes how you meet the outcomes in Sections III.A to III.E. A Cybersecurity Incident Response Plan (III.F) covers containment and segregation. A Cybersecurity Assessment Plan (III.G) is submitted annually for approval, with an annual report of results.

The outcomes that touch software supply chain work most directly:

• III.A, identify Critical Cyber Systems. You cannot inventory software for systems you have not named.
• III.D, continuous monitoring and detection, which is easier when you know what authorized code looks like.
• III.E, patch management. The strategy must ensure all critical security patches and updates on Critical Cyber Systems are current. It must include a risk methodology for categorizing patches with an implementation timeline (III.E.2.a) and must prioritize all patches and updates on CISA's Known Exploited Vulnerabilities catalog (III.E.2.b). Where you cannot patch a specific OT system without severe degradation of business critical functions, the strategy must describe additional mitigations and a timeline (III.E.3).
• III.G, assessment. At least one third of the measures in your implementation plan must be assessed each year and all of them over any three year period, and the plan must include a cybersecurity architecture design review at least once every two years.
• IV.C, documentation. TSA may inspect or copy records needed to establish compliance, starting with a hardware and software asset inventory that includes SCADA systems, and firewall rules.

The directive's Authorized Representative includes agents, contractors and subcontractors acting for you (not managed security service providers), so integrators carrying out your plan are part of the compliance story.

TSA Security Directive Pipeline-2021-01G: coordinator, reporting and vulnerability assessment

SD Pipeline-2021-01G is effective 16 January 2026 through 15 January 2027. It requires a primary and at least one alternate Cybersecurity Coordinator, available to TSA and CISA around the clock, and it requires reporting of cybersecurity incidents to CISA as soon as practicable and no later than 72 hours after the operator identifies an incident. The 01G memo notes one substantive change: a non-US citizen serving as primary or alternate coordinator must hold NEXUS, Global Entry or a comparable vetted status. The 01 series also requires a cybersecurity vulnerability assessment using TSA's form.

The 72 hour clock is the practical point: when a vendor reports a compromised component, the coordinator needs to know within hours which systems run it.

TSA's proposed rule: Enhancing Surface Cyber Risk Management

TSA published a notice of proposed rulemaking on 7 November 2024 (89 FR 88488, docket TSA-2022-0001). It would move the directive requirements into regulation for pipelines, freight rail, passenger rail and bus operators that meet risk criteria, and it adds requirements that the directives never had. One is supply chain risk management. For pipelines the proposed section is 49 CFR 1586.215, and it would require your Cybersecurity Operational Implementation Plan to include policies that:

1. Require procurement documents and contracts, including service level agreements, executed or updated after the rule takes effect, to oblige vendors and service providers to notify you of cybersecurity incidents affecting them and of confirmed security vulnerabilities in what they supply, within a timeframe sufficient for you to act.
2. Incorporate an evaluation, by you or a qualified third party, of the cybersecurity measures of vendors whose goods or services connect to, are installed on or are used by your Critical Cyber Systems.
3. Prefer the more secure offering when two are of roughly similar cost and function.
4. Consider mitigation immediately when a vendor notifies you of an incident or vulnerability, and revise the plan where needed.

TSA drew these from CISA's Cybersecurity Performance Goals (citing CPGs 1.G, 1.H and 1.I of the original goals) and the NIST CSF supply chain category, and asked whether software for Critical Cyber Systems should also meet CISA's Secure by Design and Secure by Default principles.

Status: the Federal Register shows the proposed rule and an entry in the 14 August 2026 Unified Agenda, but no final rule as of 25 October 2026. Treat 1586.215 as a strong signal of what contracts should say, not as a current obligation. CISA has since published version 2.0 of the cross-sector goals, so check the current numbering if you map to them.

API Standard 1164, third edition

The American Petroleum Institute published the third edition of API Std 1164, Pipeline Control Systems Cybersecurity, on 18 August 2021. API says it provides requirements and guidance for managing cyber risk in industrial automation and control environments, that it is based on the NIST Cybersecurity Framework and NERC CIP standards, and that the third edition expanded its scope from SCADA alone to all control system cybersecurity. The standard is sold through the API webstore, so we have not quoted its clauses here. If your implementation plan references 1164, map your supply chain controls to its sections from your licensed copy.

IEC 62443 and the ISA versions

The ISA/IEC 62443 series is the international standard family for industrial automation and control system security. For supply chain work, two parts matter most. ANSI/ISA-62443-4-1-2018 sets secure product development lifecycle requirements for the vendors who build your control system products. ISA-62443-3-3-2013 sets system security requirements and security levels, including requirements for component inventory and software integrity. In practice, 4-1 is what you ask a vendor about, and 3-3 is what you design your system against.

NIST SP 800-82 Rev. 3, and the Rev. 4 draft

NIST SP 800-82 Rev. 3, Guide to Operational Technology Security, was published in September 2023. On 21 September 2026 NIST posted the initial public draft of Rev. 4, with comments due 30 November 2026, so Rev. 3 is still the final version. It is guidance rather than a mandate, and a sensible reference for OT patching and inventory practice.

Other federal rules to check

Operators with marine terminals or Outer Continental Shelf facilities also meet the Coast Guard's final rule, Cybersecurity in the Marine Transportation System, published 17 January 2025 and effective 16 July 2025, which requires a Cybersecurity Plan and a Cybersecurity Officer. The CIRCIA incident reporting rule was proposed on 4 April 2024; CISA announced town halls in May 2026 and no final rule has been published as of 25 October 2026.

CISA guidance for OT buyers and SBOMs

Two CISA documents shape what you can ask a vendor for:

• Secure by Demand: Priority Considerations for OT Owners and Operators when Selecting Digital Products (13 January 2025), written with NSA, FBI, EPA and international partners. It lists twelve elements. Its vulnerability management element tells buyers to seek manufacturers who include a software bill of materials with product delivery, and its questions ask whether advisories will be retrievable in the Common Security Advisory Framework (CSAF) format. Its upgrade and patch tooling element asks whether you can verify an update is authentic and whether the manufacturer publishes end of life dates.
• 2026 Minimum Elements for a Software Bill of Materials (29 July 2026), from CISA, NSA, FBI and international partners. It replaces the 2021 NTIA minimum elements, which you should now cite only as history.

Real public incidents from the last three years

These are drawn from regulator advisories and company filings. We describe only what the sources say and draw no conclusions about what any company should have done.

Without speculating about any victim, two points follow from the sources. The company filings describe outages of business applications, the IT side that SD-02G pulls into scope when it could disrupt operations. And the XZ Utils case shows that an open source component deep inside a Linux image can become the problem, while Linux sits under many HMIs, historians and gateways.

For context, the TSA directive series began in 2021 after the Colonial Pipeline ransomware attack. Our earlier post on the Colonial Pipeline attack covers that history.

The personas who own the problem

Software supply chain security in a pipeline company does not belong to one person. Each of the roles below needs something different, and each has a date that forces the work.

The CISO

Needs: a defensible answer to "are we exposed?" within hours of a vendor advisory or KEV addition, and one view of IT and OT software risk for the board. When: the annual SD-02 renewal each May, the annual Cybersecurity Assessment Plan submission, board reporting, and any incident where the 72 hour CISA clock starts. What good looks like: Critical Cyber Systems with inventories attached, a measured time from KEV listing to decision, and few accepted risks, each with an owner and expiry.

Head of pipeline control or OT engineering

Needs: patch decisions that respect outage windows, vendor qualification and safety, and an auditable way to say "this RTU waits for the next turnaround, and here is what we do meanwhile". When: planned maintenance windows, vendor release cycles, and III.E.3 mitigation reviews. What good looks like: every OT system tagged with vendor, version, support end date and patch path, and every unpatched item linked to a written mitigation.

TSA Cybersecurity Coordinator and compliance lead

Needs: evidence by section number. The software inventory TSA can ask for under IV.C.2.a, the patch methodology and KEV prioritization under III.E.2, and assessment results for the annual report under III.G. When: TSA inspections, amendment requests to the implementation plan, the annual assessment plan and report, and the directive's expiry and renewal. What good looks like: evidence kept current by the systems that produce it.

Procurement and vendor risk

Needs: contract language that gets SBOMs, advisories and incident notice from vendors, and a way to track who delivered. When: every new purchase order and every contract renewal. If TSA finalizes 1586.215 as proposed, contracts executed or updated after the effective date would need the notice clauses. What good looks like: a vendor list tiered by criticality, a standard SBOM and advisory clause, and a record of each vendor's response.

Control room, field and OT IT

Needs: clear instructions on what to update, where and when, and tools that work on segmented or disconnected networks. When: daily operations, maintenance windows and incident response. What good looks like: scans inside the OT zone with no inbound connections, and results that reach the people who decide.

In-house developers and integrators

Needs: to know which open source packages their interface code and operations apps pull in, and to fix them before release. When: every pull request and release. What good looks like: dependency checks in the build, and fix pull requests reviewed like any other change.

Step by step: a 30, 60 and 90 day plan

This plan works with spreadsheets and open source tools as well as with a platform. Adjust the scope to the systems named in your implementation plan.

Days 1 to 30: know what you run

1. Pull the Critical Cyber System list from your implementation plan. That is your scope.
2. Build a software inventory per system. Record vendor, product, version, operating system, support end date, network zone and owner, including business services that could disrupt operations.
3. Generate SBOMs for what you build. For in-house code, operations apps and containers, generate CycloneDX or SPDX SBOMs and store them with the release they describe.
4. Ask vendors for what you cannot generate. Send each SCADA, historian, HMI and field device vendor a written request for an SBOM in a machine-readable format, their advisory feed (CSAF if available), their coordinated vulnerability disclosure contact and product end of life dates. The questions in CISA's Secure by Demand OT guide make a good checklist.
5. Match the inventory against the KEV catalog. Even before SBOMs arrive, match product and version against KEV and vendor advisories, as SD-02G III.E.2.b requires.

Template: the software inventory row.

Days 31 to 60: decide and document

1. Write the patch risk methodology down, as SD-02G III.E.2.a asks. A simple version uses three inputs: KEV status, reachability from outside the zone, and whether the vulnerable component runs in your configuration.
2. Set decision clocks in your own numbers, for example a fixed number of days for KEV items on Critical Cyber Systems and the maintenance cycle for the rest.
3. Write the III.E.3 mitigation record for OT systems you cannot patch. For each, state why patching would severely degrade business critical functions, the additional mitigations (segmentation, access restriction, monitoring) and the date you will revisit.
4. Gate your own builds. Add a dependency check to the build pipeline for in-house code, so new KEV or critical findings stop a release or raise a warning before deployment.
5. Add supply chain clauses to new contracts and renewals. Use the four elements of proposed 1586.215 as a model: incident notice, vulnerability notice, a security evaluation of the vendor, and a duty to support mitigation.
6. Rehearse the 72 hour path. Run a tabletop where a vendor discloses a compromised component in your SCADA platform. Time how long it takes to say which systems and sites run it.

Decision table for OT patching.

Days 61 to 90: monitor and prove it

1. Monitor the inventory. Match new CVEs and KEV additions against stored SBOMs automatically.
2. Track vendor responses: who sent an SBOM, who refused, whose SBOM is stale.
3. Feed the assessment plan. SD-02G III.G requires assessing at least a third of your plan's measures each year; patching and inventory are good candidates.
4. Report to leadership: systems with a current inventory, time from KEV listing to decision, open mitigations by age, vendor SBOM coverage.
5. Plan the next quarter for systems with no SBOM and no advisory feed: escalate, isolate further or replace.

How do you get an SBOM from a SCADA or field device vendor?

Ask in writing, ask for a format, and ask when you are buying or renewing. Name the product and version, ask for SPDX or CycloneDX in machine-readable form, ask how the SBOM will be updated with releases, and ask for the advisory channel and CSAF availability; CISA's OT buying guide backs each question. If a vendor cannot produce a firmware SBOM, ask for a component list and a commitment to notify you of vulnerabilities in it, the shape of proposed 1586.215(a)(2).

Expect partial answers at first; record each response and treat gaps as vendor risk items with review dates.

What should a pipeline operator put in vendor contracts now?

Use the four elements of proposed 49 CFR 1586.215 as the outline, then add what CISA's OT buying guide recommends: an SBOM with each release, CSAF advisories where possible, a way to verify updates, published end of life dates and a disclosure contact. Have counsel draft the wording; regulators describe outcomes, not clauses.

How do API 1164, IEC 62443 and the TSA directives fit together?

Think of them as three layers. The TSA directives are binding for designated operators and set outcomes and submissions. API 1164 is the industry program standard many operators use to structure their plan. IEC 62443 supplies system requirements and, through 4-1, the vendor lifecycle you can require. One control, such as a current software inventory for Critical Cyber Systems, can serve all three if you map it once.

How Safeguard does this

The steps below use only what Safeguard's offering documentation and docs.safeguard.sh describe. Every capability named here is generally available (GA). Commands are shown as the docs show them; we did not run them for this post.

1. Switch on the pipeline frameworks in the compliance suite

The compliance and GRC suite (GA) includes framework pages for the TSA Pipeline Security Directives, IEC 62443 and NIST SP 800-82, each tagged to the energy sector. The docs say each is on in your workspace unless you switch it off in Compliance › Manage.

For TSA SD, the docs list scan requirements checked on every product scan, including against its SBOM: TSA-SD02-INV (critical cyber system identification through an enumerated software inventory), TSA-SD02-IDENT (components carry standard identifiers such as PURL or CPE), TSA-SD02-PATCH (near complete version records to support patching), TSA-SD02-VERS (no vague versions such as "latest" or ranges), TSA-SD02-DETECT (baseline integrity hashes) and TSA-SD01-COORD (a recorded, reachable responsible contact). The Controls tab adds catalog controls such as TSA-PM-01 Patch and Update Management, and the docs list policy templates written for TSA SD, including Implementation Plan, Incident Response Plan and Vulnerability Assessment Plan templates. Treat these as Safeguard's mapping for organizing evidence, not TSA's text.

2. Inventory the software you build

SBOM generation and analysis (GA) and SCA with deep transitive dependency scanning (GA) cover the in-house half of the supply chain. From the CLI (GA), the docs show safeguard scan building an SBOM for exactly one target and matching it against vulnerability databases:

# A local directory (your own or proprietary code)
safeguard scan --dir .
# A container image
safeguard scan --image myregistry.azurecr.io/myapp:v1 \
 --registry-username "$REGISTRY_USER" \
 --registry-password "$REGISTRY_PASSWORD"
# An SBOM you already have (SPDX or CycloneDX, detected automatically)
safeguard scan --sbom sbom.json

Results are written as JSON under ./output by default, and the docs note that safeguard scan does not fail on findings; gating is done by policies. To check vendor SBOMs before you rely on them, safeguard validate sbom.json checks CycloneDX, SPDX and VEX (CSAF and OpenVEX) documents against their specifications.

3. Collect vendor SBOMs through TPRM

TPRM, the Third-Party Risk Manager (GA), is where control system and software vendors live. The vendor management docs show adding a vendor with its products, contacts and a risk tier of Critical, High, Medium or Low, with bulk import from a CSV template. To request an SBOM, the docs describe these steps:

1. Navigate to the vendor.
2. Click Request SBOM.
3. Select the product or products.
4. Choose a request template (the standard template covers SPDX or CycloneDX format and required fields).
5. Customize the message if needed.
6. Set a deadline and click Send.

Bulk requests cover many vendors at once. Requests move through Sent, Viewed, In Progress, Submitted, Validated and Rejected, with automated reminders and an escalation after the deadline. When an SBOM arrives, the docs say Safeguard validates format and completeness, runs a vulnerability scan and notifies the requester. Procurement gets a record of which vendors delivered.

4. Bring in vendor advisories as CSAF or VEX

CSAF and VEX upload (GA) appears on the Integrations page as Upload CSAF/VEX. Loading a vendor's CSAF advisory or VEX statement next to the SBOM records the vendor's position beside the raw match, the machine-readable flow CISA's OT buying guide asks vendors to support.

5. Monitor vendors and KEV continuously

TPRM monitoring (GA) watches vendor SBOMs for new vulnerabilities, severity changes, exploit availability updates and CISA KEV additions. The docs list alert types including Critical Vuln and Exploited (a CVE added to CISA KEV), re-scan schedules from daily for critical vendors to quarterly, and re-assessment triggers that include new disclosures, major version updates, contract renewals and security incidents. Vulnerability management (GA) enriches findings with EPSS and KEV, and reachability analysis (GA) helps rank which vulnerable code paths your own applications actually call, which supports the risk methodology SD-02G III.E.2.a asks for.

6. Turn the patch methodology into policies and gates

Policies, gates and guardrails (GA) put the methodology into practice. The docs describe policies under Settings › Policies with conditions such as severity, CVSS, EPSS, license and component age. Each policy's action decides what a failure does to the gate: Block fails the gate, Warn passes it with a warning naming the policy, and Notify passes it and sends a notification. Plain English policy creation (GA) is also available.

For in-house code, the docs show a CI step that fails the job when a gate fails, with policy outcomes on for your workspace:

safeguard ci scan --wait --fail-on-gate <gate>

For an OT item you cannot patch, the exception workflow fits III.E.3: the docs describe an exception with the finding, a business justification and an expiration date, approved by an approver with an audit trail. The justification holds your mitigations; the expiry is your revisit date.

7. Run it where the OT network allows

Pipeline networks are segmented, and some zones have no internet path. Three options help:

• Local runner (GA). The runner is part of the CLI. The docs say it polls the platform over outbound HTTPS that it opens, nothing connects to it, it runs scan jobs locally and uploads only the resulting SBOM and findings, never source code. For networks that forbid held connections, safeguard runner start accepts --poll-wait 0 to poll at a fixed interval.
• Air-gapped deployment (GA). The docs describe running the full web app, including TPRM, inside your perimeter, with vulnerability feed deltas (including NVD, GitHub Advisory, OSV, CISA KEV and EPSS) delivered in signed snapshot bundles. Delivery options include a one-way diode, manual media and a scheduled DMZ sync, with a cadence from hourly to quarterly, and the docs state that no component inside the perimeter calls outbound.
• Zero AI mode (GA). The platform can run with no LLM in the loop, and bring your own model or on-prem models are available where AI is allowed.

8. Fix what you own, with a person in charge

Autonomous remediation (GA) opens fix pull requests for vulnerable dependencies in code you build. It ships switched off, with every category set to Manual. For OT vendor software, the fix still comes from the vendor; Safeguard tells you which systems are affected and keeps the record.

9. Answer the "who is your vendor?" question about Safeguard

Your own vendor evaluation will ask about Safeguard. Use the precise wording: Safeguard's platform is designed for FedRAMP High, and its SOC 2 Type II audit is in progress.

What Safeguard does not do

• It does not talk to TSA or CISA for you. Submitting the implementation plan, the assessment plan and report, and incident reports under SD-01G remains the coordinator's job.
• It does not see inside firmware a vendor will not disclose. The flows above work on source directories, container images, repositories and SBOM files. For PLC, RTU and flow computer firmware you depend on the vendor's SBOM and advisories.
• It does not segment networks, harden controllers or monitor OT traffic. Those SD-02G outcomes (III.B, III.C and III.D) need your network design, access controls and OT monitoring tools.
• It does not decide when to take an outage. It can show that a KEV item affects a compressor station HMI; the operations and safety teams decide when and how to patch.
• It does not make a vendor send an SBOM. TPRM tracks requests and reminders; contract terms and purchasing decisions get the document.
• It does not interpret the regulations for you. The TSA SD framework mapping is Safeguard's organization of evidence, not TSA's text, and this post is not legal advice.

Common mistakes

• Starting with the whole estate. Scope to Critical Cyber Systems named in the implementation plan first.
• Leaving business services out. SD-02G's definition includes business services whose compromise could disrupt operations.
• Treating an SBOM request as a one-time event. An SBOM is only current for the release it describes. Ask for updates with every release.
• Accepting PDFs as SBOMs. You cannot match a scanned PDF against KEV. Ask for SPDX or CycloneDX.
• Mitigations without dates. Every III.E.3 record needs a revisit date.
• Ignoring in-house glue code. Interface scripts and operations apps often carry the least tracked open source.
• Citing old documents. Use SD-02G and SD-01G, CISA's 2026 SBOM Minimum Elements, and NIST SP 800-82 Rev. 3, and watch the Rev. 4 draft.
• Waiting for the final TSA rule to fix contracts. Renewals happen now; add notice clauses at the next one.

FAQ

What does TSA Security Directive Pipeline-2021-02G require for patching?

A patch management strategy for Critical Cyber Systems that keeps critical security patches current, a risk methodology with implementation timelines, priority for all patches on CISA's KEV catalog, and, where an OT system cannot be patched without severe degradation of business critical functions, a description and timeline of additional mitigations (Section III.E).

When does SD Pipeline-2021-02G expire?

It is effective 3 May 2026 through 2 May 2027. TSA has reissued the series each year since 2021, so expect a renewal or a replacement around May 2027.

How fast must a pipeline operator report a cyber incident to CISA?

Under SD Pipeline-2021-01G, as soon as practicable and no later than 72 hours after the operator identifies a cybersecurity incident. Check the directive for what counts as a reportable incident.

Does the TSA directive require an SBOM?

Not by that name. SD-02G requires identifying Critical Cyber Systems and lets TSA inspect a hardware and software asset inventory. An SBOM is the most practical way to keep the software part of that inventory accurate, and CISA's OT buying guide recommends asking vendors for one.

Is the TSA cyber risk management rule final?

No. TSA proposed it on 7 November 2024. As of 25 October 2026 the Federal Register shows no final rule. The proposed pipeline section on supply chain risk management is 49 CFR 1586.215.

Which IEC 62443 part covers vendors?

ISA/IEC 62443-4-1 sets secure product development lifecycle requirements for product suppliers. Asking a control system vendor how they meet 4-1 is a reasonable part of a vendor evaluation.

How do I secure SCADA software that the vendor will not let me patch?

Document it under SD-02G III.E.3: why patching would severely degrade operations, the additional mitigations such as segmentation and access restrictions, and a timeline. Escalate with the vendor and plan replacement if the product is past end of life.

Can software supply chain scanning run on an isolated OT network?

It can if the tool supports it. Options include a scanner that only makes outbound connections from a jump host, or a fully air-gapped deployment that receives vulnerability data on signed media or through a one-way transfer.

The open source dependencies inside your in-house pipeline applications and container images are the part of this supply chain you can fix yourself, without waiting on a control system vendor's release. The section below explains how Safeguard handles that half, from upgrade pull requests to cases where upstream has no fix yet.

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 sets up the local runner on your own machine, approves it with its device code, and then scans from the terminal. On a pipeline network, this is the pattern for a jump host in an OT DMZ: the runner opens only outbound connections and uploads the SBOM and findings, so the scan happens where the code lives.

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

The second demo is a real Safeguard CLI session. You install the CLI, run safeguard to open the interactive terminal and ask it to fix the lodash CVE in a repository. It reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies to an in-house measurement or integration app whose dependencies are behind.

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

The third demo is a real Android session: you send work to a computer running the CLI and approve the command on the phone with Allow once, Allow for turn or Deny. For an on-call engineer away from the control center, it shows how a change can wait for a person's approval rather than run unattended.

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

Related reading

• Energy sector software security and NERC CIP
• Manufacturing OT software supply chain
• IEC 62443-2-2 (2025): security protection schemes for IACS
• Air-gapped vulnerability management
• Third-party risk management for software vendors
• The Colonial Pipeline ransomware attack (2021)

Quick check

To try these flows on your own code and vendor SBOMs, download Safeguard at safeguard.sh/download and read the docs at docs.safeguard.sh/docs.

Sources

• TSA: Security Directives and Emergency Amendments
• TSA Security Directive Pipeline-2021-02G and transmittal memo (PDF)
• TSA Security Directive Pipeline-2021-02F and memo (PDF, history)
• TSA Security Directive Pipeline-2021-01G and transmittal memo (PDF)
• Federal Register: Enhancing Surface Cyber Risk Management, proposed rule, 7 Nov 2024
• Federal Register: Unified Agenda, 14 Aug 2026
• Federal Register: Cybersecurity in the Marine Transportation System, final rule
• Federal Register: CIRCIA town hall meetings, 26 May 2026
• Federal Register: CIRCIA reporting requirements, proposed rule, 4 Apr 2024
• API: Standard 1164, 3rd Edition
• API news: Third edition of API Standard 1164
• ISA: ISA/IEC 62443 series of standards
• NIST SP 800-82 Rev. 3, Guide to Operational Technology Security
• CISA: Secure by Demand, Priority Considerations for OT Owners and Operators
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• CISA: Cross-Sector Cybersecurity Performance Goals
• CISA: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• CISA advisory AA24-038A: PRC state-sponsored actors (Volt Typhoon)
• CISA advisory AA23-335A: IRGC-affiliated actors exploit PLCs
• CISA alert: Reported supply chain compromise affecting XZ Utils, CVE-2024-3094
• Halliburton Form 8-K, August 2024
• Halliburton Form 8-K, Item 1.05, September 2024
• ENGlobal Form 8-K, November 2024
• ENGlobal Form 8-K/A
• Safeguard docs: TSA Pipeline Security Directives framework
• Safeguard docs: IEC 62443 framework
• Safeguard docs: NIST SP 800-82 framework
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: TPRM Vendor Management
• Safeguard docs: TPRM Monitoring
• Safeguard docs: Policies and Gates
• Safeguard docs: Generate SBOM
• Safeguard docs: CLI usage
• Safeguard docs: Local Runner
• Safeguard docs: Air-Gapped Deployment

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