Chemicals and Mining Supply Chain Security: Rules, Incidents, 90-Day Plan

Chemical companies and mining operators secure their software supply chain by knowing which open source and commercial components run in the control rooms, historians, fleet systems and business applications at each site, fixing flaws in those components on a schedule that respects turnarounds and shift changes, and asking every supplier for the same records. In the United States the rulebook is thinner than most people assume: the Chemical Facility Anti-Terrorism Standards (CFATS) program lost its statutory authority on 28 July 2023 and CISA says it cannot enforce it, mining safety regulation under MSHA does not set a cybersecurity standard, and the hard requirements today come from the Coast Guard for waterfront facilities, SEC disclosure rules for listed companies, and customer and insurer contracts. A 90-day plan built around a site by site inventory, a fix process tied to change management, and supplier evidence gets most operators to records they can show a board, an insurer or an inspector.

Everything up to "How Safeguard does this" works with whatever tools you already have. Nothing here is legal or regulatory advice; your counsel, your permits and your contracts decide what applies to you.

Key takeaways

• CFATS is lapsed, not repealed. The CFATS statutory authority (6 CFR Part 27) expired on 28 July 2023. CISA's archived program page says it cannot enforce compliance, and it points facilities to its voluntary ChemLock program.
• Waterfront chemical facilities have a live cyber rule: the Coast Guard's Marine Transportation System cybersecurity rule for facilities regulated under the Maritime Transportation Security Act.
• Mining safety law is about people and machines, not code. MSHA's recent rules, such as the written safety program for surface mobile equipment (effective 19 January 2024), are safety rules. We found no MSHA cybersecurity standard, so the software duty in a mine comes from corporate risk, disclosure and customer contracts.
• NIST SP 800-82 Rev. 3 (September 2023) is the shared reference for operational technology security in both sectors, with ISA/IEC 62443 as the industrial standard most suppliers already speak. NIST has published an initial public draft of Revision 4, with comments due 30 November 2026.
• Incident reporting is still coming. CIRCIA's proposed rule closed for comment on 3 July 2024 and CISA says it continues to work on the final rule. Listed companies already face the SEC's four business day disclosure clock after a materiality determination.
• The incidents that matter are mostly IT and vendor software. In January 2024 an attacker installed a webshell on the remote access appliance in front of CISA's own chemical security portal, and in 2024 mining companies disclosed data theft and an IT outage that delayed smelting at a US metallurgical complex.
• Safeguard capabilities covered here, all GA: SBOM generation and analysis, SCA with deep transitive dependency scanning, vulnerability management with EPSS and KEV, reachability analysis, policies and gates (Block, Warn and Notify, with approval handled through exceptions), autonomous remediation (ships switched off, every category set to Manual), license compliance, CSAF and VEX upload, the compliance and GRC suite, TPRM with SBOM requests, the Safeguard CLI and local runner, the mobile app, Zero AI mode, bring your own model, and on-prem and air-gapped deployment.

The situation

The trigger in these two sectors is rarely a regulator letter about software. It is usually one of four things.

A customer or insurer sends a questionnaire. Specialty chemical buyers ask how suppliers manage vulnerabilities, and cyber insurers ask a mining group how long it takes to know whether a new flaw affects its remote operations center.

A vendor advisory lands for something on the plant floor. A historian, a fleet management server or a remote access gateway turns out to carry an old version of a common library, and the site team has to work out which of 40 sites run it.

The board asks after a peer's incident. A competitor in the same commodity discloses an outage, and the audit committee wants to know whether the same thing could happen here and how fast the company would know.

A project changes the attack surface. Autonomous haulage, a cloud historian or remote operations bring new software, suppliers and network paths into places that used to be isolated.

A bad week looks like this. A critical flaw lands in a library under the plant historian and the laboratory system. Nobody can say which sites run which version, the control systems engineer cannot patch until the next turnaround, and the CISO owes the audit committee an answer by Friday. Every one of those is a software supply chain question you can answer from records built in 90 days.

What software chemical plants and mines run

The first job is a map of software types, because the owner, the patch path and the supplier evidence differ for each.

Chemical plants and terminals

• Distributed control systems (DCS) and programmable logic controllers (PLCs) run the process. Controller firmware comes from the vendor; the engineering workstations run Windows or Linux with vendor tools and libraries.
• Safety instrumented systems (SIS) take the process to a safe state on demand. Changes are rare and go through strict change control.
• Human machine interfaces (HMI) and SCADA servers show operators the process. Many now use web technologies, which brings browser engines, JavaScript frameworks and web servers onto the operator console.
• Process historians and data platforms bridge OT and IT and often include open source databases, message brokers and Python or Java services.
• MES, batch management and laboratory information management systems (LIMS), the last often vendor hosted.
• Tank farm, terminal and loading automation manages storage and the movement of product by road, rail and ship.
• Environmental monitoring and emissions reporting, including continuous emissions monitoring systems that feed regulatory reports.
• Remote access and integration layers: VPN gateways, jump hosts, OPC UA servers, MQTT brokers and vendor support tunnels.
• Business systems: ERP, supply chain planning, product stewardship and safety data sheet tools, plus the in-house applications and data pipelines your own developers write.

Mines and processing plants

• Fleet management and dispatch systems that assign trucks and report production.
• Autonomous haulage and drilling, with onboard computers and off-board supervisory control.
• Collision avoidance and proximity detection systems on mobile equipment.
• Processing plant control: crushers, mills, flotation, leaching and smelting run on DCS and PLC platforms much like a chemical plant.
• Ventilation on demand, dewatering and power distribution in underground mines.
• Geotechnical and tailings monitoring: slope radar, piezometers, survey prisms and the software that turns readings into alarms.
• Mine planning, geology and survey software with plugins and Python scripting.
• Remote operations centers linked to sites by private LTE, fibre or satellite.
• Edge computing: rugged servers, container platforms and gateways at sites with limited bandwidth and no on-site IT staff.
• Business systems: ERP, maintenance management, assay and laboratory systems, and the analytics your data team builds.

Where open source shows up

Across both sectors, open source is not mainly in the controller. It is in the layers around it: the Linux and Windows hosts, the web based HMIs, the historians and brokers, the edge gateways, the container images on site servers, the Python and Java services that move data, and the in-house applications your developers build. That is the part of the stack a software supply chain program can inventory and fix with ordinary tools. Controller firmware and certified safety logic stay with the vendor and your own change control.

The regulations and frameworks that apply

This section covers the United States first, then international context. Statuses were checked on the primary pages on 25 October 2026.

CFATS: lapsed since 28 July 2023

CFATS was the Department of Homeland Security program for high-risk chemical facilities, codified at 6 CFR Part 27 and run by CISA. Facilities that held chemicals of interest above set thresholds reported them through the Chemical Security Assessment Tool (CSAT), and those designated high-risk wrote Site Security Plans against risk-based performance standards, one of which covered cyber.

CISA's CFATS page is now marked as archived content. Its announcement says that as of 28 July 2023 Congress allowed the statutory authority to expire, so CISA "cannot enforce compliance with the CFATS regulations at this time." CISA says it cannot require facilities to report chemicals of interest, submit information in CSAT, host inspections or implement their Site Security Plans or Alternative Security Programs. It encourages facilities to keep their security measures in place, points them to ChemLock, and says it will follow up with facilities if CFATS is reauthorized. The page states that roughly 3,200 facilities had previously been designated high-risk.

What this means in practice: the Site Security Plan you wrote under CFATS is no longer enforceable, but it is still the best description most facilities have of their critical cyber assets. Keep it current. Insurers, customers and any future reauthorization will start from it.

ChemLock: the voluntary program

ChemLock is CISA's voluntary chemical security program. CISA describes it as completely voluntary and no-cost, with on-site assessments and assistance, training, exercises and publications for any facility that holds dangerous chemicals. It is not a compliance regime, but it is the current federal channel for chemical security help and a reasonable place to benchmark a security plan.

The Coast Guard rule for waterfront facilities

Chemical plants with docks, marine terminals and bulk liquid storage on navigable waters are usually regulated under the Maritime Transportation Security Act (MTSA) at 33 CFR Part 105. The Coast Guard published a final rule on cybersecurity in the Marine Transportation System in the Federal Register on 17 January 2025, effective 16 July 2025. It adds minimum cybersecurity requirements for U.S. flagged vessels, Outer Continental Shelf facilities and MTSA regulated facilities, including a Cybersecurity Plan and a designated Cybersecurity Officer, among other measures. The Coast Guard also sought comment on delaying implementation periods for U.S. flagged vessels. If you operate a regulated terminal, read the rule text for your own dates.

SEC cybersecurity disclosure

For listed chemical and mining companies, the SEC's cybersecurity disclosure rules adopted on 26 July 2023 require a Form 8-K under Item 1.05, generally within four business days after the company determines a cybersecurity incident is material, and annual disclosure in Form 10-K under Regulation S-K Item 106 of how the company assesses, identifies and manages material cybersecurity risks, with board oversight and management's role. This is often the strictest live clock a mining or chemicals group faces, and it applies to incidents in vendor software as much as in your own.

CIRCIA: incident reporting for critical infrastructure, still in rulemaking

The Cyber Incident Reporting for Critical Infrastructure Act of 2022 will require covered entities to report substantial cyber incidents to CISA and ransom payments. CISA published the proposed rule at 89 FR 23644, with comments open from 4 April 2024 to 3 July 2024. CISA's CIRCIA page says funding lapses affected its rulemaking and that it continues to work on the final rule. Reporting is not required until the final rule takes effect. The Chemical Sector is one of the 16 critical infrastructure sectors, so plan as if the rule will apply.

NIST SP 800-82 Rev. 3

NIST's Guide to Operational Technology Security, SP 800-82 Rev. 3, was published in September 2023 and superseded Rev. 2. It covers OT architectures, risk management and the application of the SP 800-53 control overlay to OT. On 21 September 2026 NIST added a planning note pointing to the initial public draft of Revision 4, with public comments due by 30 November 2026, so expect the reference to change. For a software supply chain program it is the document that explains why patching in OT needs testing, staging and vendor coordination, and why compensating controls are legitimate when a patch must wait.

ISA/IEC 62443

The ISA/IEC 62443 series is the industrial automation and control systems security standard most automation suppliers build to. Two parts matter here. 62443-4-1 sets secure product development lifecycle requirements for suppliers, including how they manage third-party components and security updates. 62443-2-4 sets security program requirements for IACS service providers, such as integrators and maintenance contractors. Asking suppliers which parts they conform to, and for the evidence, is the most direct supply chain question you can ask in this sector.

MSHA: safety rules, no cybersecurity standard

MSHA's rules, in Title 30 of the Code of Federal Regulations, are about people and machines. The most relevant recent one is the final rule on safety programs for surface mobile equipment, published on 20 December 2023 and effective 19 January 2024. It requires mine operators to develop, implement and update a written safety program for surface mobile equipment (excluding belt conveyors) at surface mines and surface areas of underground mines, developed with input from miners and their representatives, setting out the actions the operator will take to identify hazards and risks. It does not regulate software. Our reading, not MSHA's: if your written program relies on collision warning, proximity detection or other onboard technology to control those hazards, the software in that technology is part of what keeps the program working, so you need to know what it is and how it is updated.

We found no MSHA rule that sets cybersecurity requirements for mines. The software duty in mining comes from corporate risk management, SEC disclosure, customer contracts, insurers and frameworks like NIST SP 800-82 and ISA/IEC 62443.

International context

If you operate or sell in the European Union, check whether the NIS2 Directive (EU) 2022/2555, as transposed into each member state's law, brings your entities into scope; it carries risk management and supply chain security duties. Mining groups with Australian, Canadian, Chilean or South African operations should check each country's critical infrastructure law for their commodity and site.

How the pieces fit

Real public incidents from the last three years

These incidents come from official notices or the company's own announcements. We draw no conclusions beyond what the sources say.

The chemical security portal itself (January 2024)

CISA's CSAT notification says its Chemical Security Assessment Tool was the target of an intrusion by a malicious actor from 23 to 26 January 2024. On 26 January CISA identified potentially malicious activity on the remote access appliance in front of CSAT and found that the actor had installed an advanced webshell on it and accessed it several times over two days. CISA says it found no access beyond that appliance and no evidence of data exfiltration, but that the intrusion may have allowed unauthorized access to Top-Screen surveys, Security Vulnerability Assessments, Site Security Plans, Personnel Surety Program submissions and CSAT user accounts. CISA took the system offline, notified CFATS participants under federal reporting rules, held stakeholder webinars on 24 June and 9 July 2024, and pointed organisations using that appliance family to its joint advisory on threat actors exploiting multiple vulnerabilities in it. It encouraged account holders who reused their CSAT password elsewhere to change it.

Two points sit in the notice itself. The activity was on a commercial remote access appliance, which is vendor software. And the data potentially exposed was the facilities' own security plans, held by a third party.

Mining data theft and disclosure (2024)

Northern Minerals, an Australian rare earths company, told the Australian Securities Exchange on 4 June 2024 that it had been the subject of a cyber security breach it became aware of in late March 2024, and that its consultant had advised that some exfiltrated data had been released on the dark web. The company said the data included corporate, operational and financial information, some details of current and former personnel and some shareholder information, and that the breach had not had a material impact on its operations or broader systems.

Sibanye-Stillwater, a multinational mining and metals processing group listed in Johannesburg and New York, announced on 11 July 2024 that a cyber attack was affecting its IT systems globally, that it had isolated IT systems in line with its incident response plan, and that there had been limited disruption to operations. Its update on 25 July 2024 said the Columbus metallurgical complex at its US PGM operations had short-term operational delays because IT outages affected the smelting of underground concentrate and the recycling of spent autocatalysts, that some operations used backup manual processes, and that publication of its first half results would be delayed. That is the clearest public example in these sectors of an IT incident reaching processing operations.

A backdoor in a widely used open source library (March 2024)

On 29 March 2024 CISA reported a supply chain compromise of XZ Utils, a data compression library shipped in many Linux distributions, tracked as CVE-2024-3094. Malicious code had been inserted into versions 5.6.0 and 5.6.1. CISA advised downgrading to an uncompromised version. It matters here because Linux runs the historians, edge gateways and container hosts in both sectors, and the first question on that Friday was the same everywhere: which of our systems carry those versions?

None of these began in a controller. They began in remote access, IT systems and shared libraries, the layers a software supply chain program covers first.

The personas who own the problem

Software supply chain risk in a chemical plant or a mine has more owners than in most industries, because safety, operations and IT all touch the same systems.

Who leads

In most groups the CISO owns the program and the answer to the board, while the OT lead and the site IT lead own the fixes. Process safety owns the gate on any change inside the safety envelope, and that role should not need to become a security expert to do it. Procurement carries the heaviest load in these sectors, because most of the software is bought: it needs one standard request and one place to track replies.

Step by step: a 30/60/90-day plan

This plan works with or without Safeguard. Adjust the order to your sites; a single plant and a multi-country mining group will move at different speeds.

Days 1 to 30: scope and inventory

1. Pick the pilot sites. Choose one chemical plant or terminal and one mine or processing plant if you have both, or two sites of different age. Name a site owner for each.
2. List the software types per site, using the lists above. For each system, record the owner, the supplier, the hosting (on site, vendor hosted, cloud), and whether it sits in the OT network, the business network or a DMZ.
3. Split by fix path. Put each system into one of three groups: software you build (in-house apps, data pipelines, edge containers), software you host but buy (historians, MES, fleet servers), and software the vendor controls end to end (controller firmware, SIS logic, hosted LIMS). The first two groups are where your own inventory work pays off fastest.
4. Generate SBOMs for what you build and host. Use any tool that writes SPDX or CycloneDX for source repositories and container images. For bought software you host, scan the installed images or file systems where your license and vendor terms allow.
5. Ask key suppliers for SBOMs and update commitments. Start with the remote access, historian, fleet management and LIMS suppliers. Use the template below.
6. Find your old CFATS Site Security Plan, if you had one, and your Coast Guard facility security plan if you run a terminal. Note which systems they named as critical cyber assets and check that each is on your inventory.
7. Agree a severity model with OT and safety. Use CVSS for severity, CISA's Known Exploited Vulnerabilities catalog for active exploitation and EPSS for likelihood, then adjust for whether the component is reachable and which network zone it sits in.

Days 31 to 60: fix, gate and ask suppliers

1. Fix what you build first. In-house apps and edge containers can usually be upgraded in a normal release. Open the upgrade, run your tests, ship it.
2. Add a gate to your pipelines. Fail or warn on new critical vulnerabilities that are known exploited, and on licenses your legal team has ruled out. Start in warn mode for a few weeks, then block on the narrow set everyone agreed.
3. Tie hosted software updates to management of change. For historians, MES and fleet servers, add the vulnerability record to the change request so the process safety reviewer sees why the change is needed and what it touches.
4. Write compensating controls for what must wait. Where a patch waits for a turnaround or a vendor release, record the control (network isolation, disabled service, restricted accounts) with an owner and an expiry date.
5. Chase supplier replies. Track who sent an SBOM, in what format, how complete it is, and what they committed to on updates. Escalate silence through procurement.
6. Rehearse one advisory. Pick a recent high profile vulnerability and time how long it takes to answer "do we run it, where, and is it reachable" across both pilot sites.

Days 61 to 90: prove it and keep it running

1. Map evidence to your frameworks. Map the inventory, scan history, policies and exceptions to the framework your company uses (NIST CSF, NIST SP 800-82 or ISA/IEC 62443), and for terminals to the Coast Guard plan elements.
2. Write the board summary. One page: coverage by site, open critical findings by fix path, supplier response rate, exceptions past due, and the rehearsal time.
3. Extend to more sites on a schedule tied to turnarounds and fleet updates.
4. Set a monthly review with OT, safety, IT and procurement in the room.

Template: evidence checklist for an auditor, insurer or customer sample

Template: supplier SBOM request (plain text you can adapt)

Please provide a software bill of materials in SPDX or CycloneDX format for each software product and version you supply to our sites, including third-party and open source components. Please tell us how you notify customers of vulnerabilities in those components, your target time to release updates for critical vulnerabilities, whether you publish VEX statements, and which parts of ISA/IEC 62443 your development process conforms to. Please send an updated SBOM with each release. If a product is end of support, please say so and give the date.

Decision table: what to do with a finding

Illustrative scenario: one advisory, two sites, 48 hours

This is an illustrative scenario with invented round numbers. A critical flaw is published in a widely used logging library on a Tuesday. The CISO asks for an answer by Thursday. The chemical plant's inventory shows the library in two in-house data services and inside the historian's web interface. The mine's inventory shows it in the fleet management server image and in nothing the mine builds. The engineering lead upgrades the two data services by Wednesday afternoon, because the library is a direct dependency and the tests pass. The historian vendor confirms an update within ten days; the plant IT lead blocks the historian's web interface from the business network in the meantime and records the exception with a two week expiry. The fleet vendor says the vulnerable function is not used and sends a VEX statement; the mine records it and asks for the update at the next release. On Thursday the CISO has one page: four affected systems, two fixed, one isolated with an expiry, one vendor statement on file.

How Safeguard does this

Safeguard is a software supply chain security platform. The steps below follow the plan above and use only flows described in Safeguard's offering documentation and docs.safeguard.sh. Every capability named here is generally available (GA).

1. Choose where Safeguard runs. Plants and mines often keep OT data inside the perimeter. Safeguard offers on-prem and fully air-gapped deployment (GA). The air-gapped deployment docs describe signed snapshot bundles carrying vulnerability feed updates (including CISA KEV and EPSS) into a control plane inside your perimeter, where no component calls outbound. If you want no AI in the loop, Zero AI mode (GA) runs the platform deterministically; bring your own model (GA) is the other option.

2. Scan on your own machines with the local runner. The Safeguard CLI and local runner (GA) scan source code, container images and existing SBOMs on systems you control, which suits a site server with limited bandwidth. The docs show:

   # 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)
   safeguard scan --sbom sbom.json
   

   These snippets are copied from the docs and were not run for this post.

3. Build the inventory. SBOM generation and analysis (GA) produces SPDX and CycloneDX. SCA with deep transitive dependency scanning (GA) covers application dependencies and container layers. The platform shows which projects contain a given component and version, which is the lookup the 48 hour rehearsal tests.

4. Validate what suppliers send. The CLI docs show a validator for SBOM and VEX documents:

   safeguard validate sbom.json --strict -o report.json
   

5. Prioritize. Vulnerability management (GA) enriches findings with EPSS and CISA KEV. Reachability analysis (GA) ranks findings by whether your code calls the vulnerable path, which is the split the OT lead needs before a turnaround.

6. Gate new risk in CI. Policies and gates (GA) evaluate SBOMs and findings. Each policy's action is Block (the gate fails), Warn (the gate passes with a warning naming the policy) or Notify (the gate passes and a notification is sent). Exceptions are requested with a business justification and an expiration date, then submitted for approval, which is the exception register from the plan. In CI, the docs show safeguard ci scan with --wait, and a --fail-on-gate flag that fails the job when the named policy gate is not Passed or Warning; the docs also show --fail-on critical for a severity threshold.

   License compliance (GA) applies license policy to the same components.

7. Open fix pull requests under your control. Autonomous remediation (GA) has Griffin open tested, policy gated pull requests that move a dependency to a fixed version. It ships switched off, with every category set to Manual. For anything that touches a system in the safety envelope, leave it on Manual and route the change through management of change.

8. Request SBOMs from suppliers. TPRM (GA) lets you send single or bulk SBOM requests from a vendor record, with format requirements, a deadline and reminders. Received SBOMs get format validation, a completeness check and an automatic vulnerability scan.

9. Record vendor statements. CSAF and VEX upload (GA) records exploitability statements, such as the fleet vendor's VEX in the scenario.

10. Map evidence. The compliance and GRC suite (GA) maps scan results and uploaded evidence to frameworks such as NIST CSF 2.0, so the GRC lead can sample from one place.

11. Approve from the road. The Safeguard mobile app (GA) can send work to a computer running the CLI and lets you approve each command from your phone, which helps a site lead who is underground or on a haul road when a fix needs a yes.

Requirement, what Safeguard does, what you still own

What Safeguard does not do

• It does not analyse firmware binaries. Controller firmware, SIS logic, protection relays and onboard machine firmware are outside what Safeguard scans. Ask the vendor for an SBOM and update commitments, and track them in TPRM.
• It does not replace management of change or a hazard review. Safeguard can supply the vulnerability record; the decision to change a system in the safety envelope stays with your process safety and operations people.
• It does not monitor OT networks. Passive network monitoring, asset discovery on control networks and intrusion detection for industrial protocols need other tools.
• It does not patch vendor appliances or hosted software. When the flaw is inside a vendor's appliance, a hosted LIMS or an operating system you do not build, the fix comes from that vendor.
• It does not make your filing decisions. It holds evidence; whether an incident is material under SEC rules, or reportable to the Coast Guard, is a decision for your counsel and leadership.
• It does not certify you. Mapping evidence to a framework is not an audit or a certification of your site or your products.

Common mistakes

• Treating CFATS as still enforceable, or as gone for good. It is lapsed. Keep the Site Security Plan current and watch for reauthorization.
• Starting with the controllers. The controller is the hardest place to see and fix. Start with what you build and host, where most open source lives.
• One list for all sites. A list without a site, an owner and a fix path cannot be acted on by a site lead.
• Patching outside management of change. A rushed update to a historian that feeds a safety alarm is a process safety event waiting to happen.
• Exceptions without expiry. Compensating controls become permanent unless someone has to renew them.
• Asking vendors for "an SBOM" with no format, no deadline and no follow up. Use the template and track replies.
• Forgetting the remote access layer. The portal incident above began at a remote access appliance. Inventory those gateways like any other system.

FAQ

Is CFATS still in effect?

No. CISA's archived CFATS page says that as of 28 July 2023 Congress allowed the statutory authority to expire and CISA cannot enforce compliance at this time. CISA encourages facilities to keep their security measures and offers the voluntary ChemLock program. If Congress reauthorizes CFATS, CISA says it will follow up with facilities.

What replaced CFATS for chemical facility cybersecurity?

Nothing replaced it directly. ChemLock is voluntary. Waterfront facilities regulated under MTSA have the Coast Guard's cybersecurity rule. Listed companies have SEC disclosure duties. Everyone else relies on frameworks such as NIST SP 800-82 and ISA/IEC 62443, insurer requirements and customer contracts.

Does MSHA regulate cybersecurity at mines?

We found no MSHA cybersecurity standard. MSHA's rules cover health and safety, including the written safety program for surface mobile equipment that took effect on 19 January 2024. If your program relies on onboard technology such as proximity detection or collision warning, the software in that technology belongs in your inventory even though no cyber rule names it.

Do chemical companies need an SBOM?

No general federal rule requires one. Federal customers and large commercial buyers increasingly ask suppliers for SBOMs, and asking your own automation vendors for SBOMs is the quickest way to answer "do we run this component" after an advisory.

What is the Coast Guard's cybersecurity rule for terminals?

It is a final rule published on 17 January 2025 and effective 16 July 2025 that adds minimum cybersecurity requirements for MTSA regulated facilities, Outer Continental Shelf facilities and U.S. flagged vessels, including a Cybersecurity Plan and a designated Cybersecurity Officer. Check the rule text for the dates that apply to your facility.

Will CIRCIA apply to chemical companies?

CIRCIA covers critical infrastructure entities that meet the final rule's definitions, and the Chemical Sector is one of the 16 sectors. The final rule has not been issued; CISA says it continues to work on it. Reporting is not required until the final rule takes effect.

How do we patch OT systems that cannot go down?

NIST SP 800-82 Rev. 3 describes testing patches before deployment, coordinating with vendors and using compensating controls when a patch must wait. Record each wait as an exception with a control and an expiry, and tie the eventual update to management of change and the next turnaround.

Does the SEC cyber disclosure rule apply to mining and chemical companies?

It applies to public companies that report under the Securities Exchange Act of 1934, whatever their industry. A material incident generally needs a Form 8-K under Item 1.05 within four business days of the materiality determination, and the annual report describes cybersecurity risk management and governance. An incident that starts in a supplier's software can still be yours to disclose.

Related reading

• CFATS cybersecurity requirements for chemical facilities explained
• Chemical plant software: supply chain risk as a process
• Mining OT security: autonomous equipment and remote site response
• Why software supply chain risk becomes a safety risk in mining
• MSHA's proximity detection rule explained
• Software supply chain security for critical energy infrastructure

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

Most of the open source exposure in a plant or a mine sits in the software you build and host, and that is where you can close the gap between a published fix and a running fix. The section below explains how, and where the fix still has to come from a vendor.

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. On a site server at a plant or a mine, that is how you would scan in-house services and container images without sending source off site.

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

The second demo is a real CLI session. You ask the assistant 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 data service at a chemical plant.

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 a site lead who is rarely at a desk, that is how a fix can wait for a human yes without waiting for a person to drive back to the office.

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

Quick check

Sources

• CISA: Chemical Facility Anti-Terrorism Standards (CFATS), archived program page
• CISA: ChemLock
• CISA: Chemical Sector
• CISA: CSAT notification
• CISA: Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA)
• CISA: Reported supply chain compromise affecting XZ Utils (CVE-2024-3094)
• NIST SP 800-82 Rev. 3: Guide to Operational Technology (OT) Security
• Federal Register: Cybersecurity in the Marine Transportation System (U.S. Coast Guard final rule, 17 January 2025)
• Federal Register: Safety Program for Surface Mobile Equipment (MSHA final rule, 20 December 2023)
• Mine Safety and Health Administration
• SEC press release 2023-139: SEC adopts rules on cybersecurity disclosure
• Federal Register: Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure (SEC final rule)
• ISA: ISA/IEC 62443 series of standards
• European Commission: NIS2 Directive
• Northern Minerals: ASX announcement, cyber security breach (4 June 2024, PDF)
• Sibanye-Stillwater: SENS announcement, cyber security attack (11 July 2024)
• Sibanye-Stillwater: SENS update on the cyber security attack (25 July 2024)
• Safeguard docs: CLI usage
• Safeguard docs: CI/CD integration
• Safeguard docs: Policies and gates
• Safeguard docs: TPRM SBOM requests
• Safeguard docs: Air-gapped deployment
• Safeguard docs: Local runner
• Safeguard docs: CSAF and VEX upload
• Safeguard docs: Auto-fix
• Safeguard docs: Reachability analysis

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