Software supply chain security for logistics and freight: a 90-day plan

Securing the software supply chain at a carrier, broker, 3PL, port or terminal operator means three things: knowing every piece of software that moves your freight (TMS, WMS, EDI and file transfer, telematics, customs tools and the open source inside your own code), holding vendors to written security terms, and answering "are we affected?" in hours when the next file transfer flaw or hosted platform outage lands. In the US, the hard deadlines today come from the Coast Guard's maritime cybersecurity rule, SEC incident disclosure for listed companies and CMMC for defense freight; most other pressure arrives through customer audits, insurers and contracts. A focused 90 day program gets most freight organizations from a spreadsheet of guesses to a working inventory, a vendor tier list and a tested response path.

This guide covers the systems the industry runs, the rules that apply with their current status, the public incidents of the last three years, who owns which part of the problem, and a 30/60/90 day plan that works with whatever tools you have. Safeguard appears only in the section called "How Safeguard does this". Nothing here is legal or regulatory advice; read the primary texts linked in Sources before you rely on a summary.

Key takeaways

• Logistics software risk sits in four places: hosted platforms you rent (TMS, WMS, visibility), integration plumbing (EDI, managed file transfer, carrier and customs APIs), devices in the field (telematics, ELDs, handhelds, terminal OT) and the code your own teams write to connect it all.
• The Coast Guard rule at 33 CFR part 101, subpart F has been effective since 16 July 2025. Its supply chain measures in section 101.650(f) require vendor vulnerability notification "without delay" and monitoring of third party remote connections. Cybersecurity Plans and the first Cybersecurity Assessment are due by 16 July 2027.
• TSA's proposed surface cyber rule (7 November 2024) and the CIRCIA reporting rule (proposed 4 April 2024, still in town hall consultation in May 2026) were not final in the Federal Register when we checked on 25 October 2026.
• Recent freight incidents were mostly not exotic: a hosted supply chain platform went down, a managed file transfer product was mass exploited, and operators took systems offline to contain intrusions, which stopped trucks and orders.
• The plan: inventory and tier in the first 30 days, vendor terms and build controls by day 60, a tested response drill and leadership report by day 90.
• In Safeguard, the matching flow uses TPRM (GA), SBOM generation and analysis (GA), SCA (GA), vulnerability management with EPSS and CISA KEV (GA), reachability analysis (GA), policies and gates (GA), autonomous remediation (GA, ships switched off), the Portal SBOM Repository (GA), the CLI and local runner (GA), and on-prem and air-gapped deployment (GA).

The situation

Freight is a coordination business. One shipment touches a shipper's ERP, a broker's TMS, a carrier's dispatch system, a driver's ELD and mobile app, a warehouse WMS, a terminal operating system, a customs broker's filing software and several EDI or file transfer hops in between. Each is software, most of it is bought rather than built, and almost all of it carries open source components nobody at the freight company chose.

That is why a software problem can stop physical goods. When a hosted platform or file transfer server is compromised, the first move is usually to isolate systems, and isolation in logistics means trucks waiting at a gate and orders not picked.

The trigger for this work is rarely a calm planning cycle. It is usually one of these:

• A facility Cybersecurity Officer has to write the supply chain section of a Coast Guard Cybersecurity Plan and finds nobody has a list of IT and OT vendors with remote access.
• A large shipper's vendor risk team asks for an SBOM for your customer portal or tracking API before renewal.
• A CISA alert names a file transfer product, and the operations director asks whether "we use that" before lunch.
• After a peer's 8-K filing, the audit committee asks how quickly the company would know whether an incident is material.
• A defense logistics contract requires CMMC, and the assessor asks how you manage software on systems that touch contract information.

A bad week looks like this: an advisory lands on a Friday, the integration team believes the affected product was retired two years ago, a partner says it still receives files from that server, and nobody can say which version is running or whom to call at the vendor. Everything below is about making that week shorter.

What software does a logistics or freight company run?

Most freight organizations run some version of the following, hosted by a vendor, installed on site, or built in house.

Two things stand out. A large share of the estate is vendor software you cannot scan from the inside, so the controls are contractual and evidential: the vendor must tell you what is in the product and tell you quickly when something is wrong. And the in house integration layer is often bigger than people think; a mid sized 3PL can have dozens of small services translating between carriers, customers and the TMS, each with its own dependency tree. That part you can inventory and fix yourself.

With dense partner networks, IT and OT side by side at terminals, and thin teams that rely on vendors for almost everything, vendor risk management is the main security control in freight, not a side process.

Which regulations and frameworks apply to logistics software?

No single cybersecurity rule covers logistics. Which ones apply depends on what you operate, whom you work for and whether you are listed. Status below was confirmed on the primary source on 25 October 2026.

US Coast Guard: Cybersecurity in the Marine Transportation System (33 CFR part 101, subpart F)

The Coast Guard published its final rule on 17 January 2025, effective 16 July 2025. It sets minimum cybersecurity requirements for US-flagged vessels, Outer Continental Shelf facilities and facilities subject to the Maritime Transportation Security Act regulations. Owners and operators must develop a Cybersecurity Plan, designate a Cybersecurity Officer (CySO) and put a set of measures in place. For supply chain work, three parts of the current text matter most:

• Section 101.615, Definitions. The rule defines "software" and "supply chain", and defines an "approved list" as an owner or operator's authoritative catalog of products that meet cybersecurity requirements.
• Section 101.650(f), Supply chain. The operator or CySO must document in Section 4 of the Cybersecurity Plan that they (1) consider cybersecurity capability when procuring IT and OT systems or services, (2) have a process through which all IT and OT vendors or service providers notify them of vulnerabilities or reportable cyber incidents "without delay", and (3) monitor and document all third party remote connections to detect cyber incidents.
• Sections 101.650 and 101.655, measures and dates. The measures include vulnerability scans as specified in the Cybersecurity Plan. The current text sets training for all personnel by 12 January 2026, a Cybersecurity Assessment by 16 July 2027 and annually after that (sooner after a change in ownership), and submission of Cybersecurity Plans by 16 July 2027.

This is the most concrete software supply chain requirement in US freight today. Vendors selling to terminal operators should expect the notification clause to appear in their contracts.

TSA: Enhancing Surface Cyber Risk Management (proposed)

On 7 November 2024 TSA proposed cyber risk management requirements for certain pipeline and rail owner/operators, plus incident reporting for certain over-the-road bus operators. Comments closed on 5 February 2025. We found no final rule in the Federal Register as of 25 October 2026. If you run or serve freight rail, track it, and do not describe it to your board as in force.

CIRCIA incident reporting (proposed)

CISA published the CIRCIA proposed rule on 4 April 2024, covering covered cyber incident and ransom payment reporting by covered critical infrastructure entities. On 26 May 2026 CISA published a revised town hall schedule to take more input on "refining the scope and burden" of the proposal. Plan for it, since transportation is a critical infrastructure sector, but check the covered entity criteria in the final text before deciding whether you are in scope.

SEC Form 8-K Item 1.05 and DFARS CMMC

Listed companies disclose material cybersecurity incidents on Form 8-K under Item 1.05. Two logistics and distribution companies did so in the period this guide covers. The practical consequence for supply chain work is speed: the people deciding materiality need facts about which systems and vendors are involved, fast.

DoD's final DFARS rule incorporating the Cybersecurity Maturity Model Certification program took effect on 10 November 2025. Carriers, forwarders and 3PLs with DoD contracts involving federal contract information or controlled unclassified information need the CMMC level their contract specifies. CMMC does not ask for SBOMs, but the patch and support state of software on in scope systems is part of what an assessor examines. Export controlled freight raises different questions; see our guide to ITAR and EAR export control for software.

CTPAT, NIST and CISA guidance

CTPAT is CBP's voluntary trade security program, with Minimum Security Criteria published by type of business. Trade summaries describe a cybersecurity section added in CBP's 2019 revision; read the current criteria for your entity type rather than a summary.

NIST CSF 2.0 (26 February 2024) puts supply chain risk under the Govern function in category GV.SC: know and prioritize suppliers by criticality (GV.SC-04), build security requirements into contracts (GV.SC-05), and understand, assess, respond to and monitor supplier risk over the relationship (GV.SC-07). NIST SP 800-161 Rev. 1 is the detailed supply chain risk guidance behind it, and SP 800-218 (SSDF) describes secure development practice for your integration and portal code.

CISA's 2026 Minimum Elements for a Software Bill of Materials, published 29 July 2026, update and replace the NTIA minimum elements from 2021. Ask vendors for SBOMs against this document.

In Europe, as context, the NIS2 Directive lists transport (air, rail, water and road) among sectors of high criticality in Annex I and includes supply chain security in its risk management measures. For a US freight company that matters mainly through European subsidiaries and customers.

What happened in real logistics incidents in the last three years?

These public incidents from late 2023 to 2025 touched freight, ports or the software logistics depends on. Details come from filings, government sources or established reporting, linked in Sources. We describe what was reported and draw no conclusions about what anyone should have done.

DP World Australia, November 2023

On 10 November 2023 DP World Australia detected unauthorized access and disconnected its systems from the internet, suspending operations at its four Australian container terminals, including Sydney and Melbourne. Operations resumed on 13 November with almost 30,000 containers stranded, according to The Record, and Australia's National Cyber Security Coordinator called it "a nationally significant cyber incident."

Radiant Logistics, March 2024

Radiant Logistics, a US 3PL, filed a Form 8-K under Item 1.05 on 20 March 2024. It said that on or about 14 March its monitoring tools detected the initial stages of an incident related to its Canadian operations. It isolated those operations from the rest of its network, engaged forensics professionals and reported service delays for Canadian customers, while US and other international operations continued.

The xz utils backdoor, March 2024

On 29 March 2024 CISA published an alert about a reported supply chain compromise in xz utils, a compression library present in many Linux distributions (CVE-2024-3094). It was not a logistics incident, but it is the clearest recent example of open source inside the servers and containers freight companies run being compromised upstream. The question it raised for every operator is the one this guide is about: which of our systems contain that version, and how fast can we tell?

Port of Seattle, August 2024

The Port of Seattle, which runs maritime facilities and the airport, was hit by a ransomware attack that began on 24 August 2024. According to The Record, the Port attributed it to the Rhysida group, said some Port data was obtained, and refused to pay. We cover it in more depth in Port of Seattle and the Rhysida ransomware attack.

A hosted supply chain software platform, November 2024

On 21 November 2024 supply chain software vendor Blue Yonder reported a ransomware attack on its managed services hosted environment and said its public cloud services were not affected, according to Tech Monitor. UK grocers said the outage disrupted the flow of goods and that they had moved to backup processes or contingency plans. This is the vendor concentration case: one hosted platform, many downstream operators, and little the customers could do except work around it.

Cleo managed file transfer, December 2024

In December 2024 attackers exploited vulnerabilities in Cleo Harmony, VLTrader and LexiCom, managed file transfer products used for B2B and EDI exchange. CISA added CVE-2024-50623 to its Known Exploited Vulnerabilities catalog on 13 December 2024 and CVE-2024-55956 on 17 December, and the catalog marks both as known to be used in ransomware campaigns. File transfer servers face the internet by design, which is why this product class keeps appearing in KEV.

United Natural Foods, June 2025

United Natural Foods, a large US food distributor, filed an 8-K on 9 June 2025 saying that on 5 June it became aware of unauthorized activity on certain IT systems and took some systems offline, which temporarily affected its ability to fulfill and distribute customer orders. It later filed under Item 1.05. The filing shows how quickly an IT containment decision becomes a fulfillment problem.

What these incidents have in common

Who owns software supply chain risk in a freight company?

In most logistics organizations the problem is split across five or six people, and none owns all of it. That works if each knows what they need and when.

The CISO or head of security

The CISO owns the risk picture and the response, and needs a short list of systems whose failure stops freight, the vendors behind them, and a credible answer to "how long until we know if we are affected?" They need it before the board meeting, before the insurance renewal, and the moment a KEV entry names a product the company uses. At a listed company they also need facts fast enough for an Item 1.05 decision. Templates are in our guide to board level supply chain security reporting.

The VP of engineering or IT, or the TMS and WMS platform owner

This person owns the in house integration layer and the core platform vendors. They need one process instead of four: one inventory of repositories and images, one view of vulnerable dependencies, and fixes that arrive as reviewable pull requests rather than tickets. The pressure peaks at release time and during peak season freezes.

The GRC lead and the facility Cybersecurity Officer

For a port, terminal or vessel operator, the CySO must document supply chain measures in Section 4 of the Cybersecurity Plan. Elsewhere, the GRC lead fields customer questionnaires, CTPAT validations, CMMC assessments and insurer forms. Both need evidence by clause (a tiered vendor list, notification terms, remote connection records, dated SBOMs) on the plan submission date, at the assessment, and when a shipper's audit request arrives.

Procurement and vendor risk

Procurement holds the strongest position at signing and renewal. Section 101.650(f)(1) asks regulated operators to weigh cybersecurity when they buy, and GV.SC-05 asks everyone to write requirements into contracts. Procurement needs standard clauses, a tiering rule so effort goes to critical vendors, and a renewal calendar so terms are added while the vendor still wants the signature.

Operations IT and OT, and integration developers

The people running gate systems, cranes, sortation and robotics know which vendors connect remotely and how. They need a register for those connections, a list of what is installed at each site, and a say in patch timing so a fix does not stop a sorter mid shift. Developers maintaining carrier adapters, EDI maps and the tracking portal need exact commands and a gate that says clearly why a build failed and how to request an exception.

How do you secure logistics software in 90 days?

This plan works with spreadsheets, a ticketing system and whatever scanners you already have. Adjust the dates to your peaks and freezes.

Days 1 to 30: know what you run and who it depends on

1. List the systems that move freight. Start from operations, not IT. Ask each operations lead which systems would stop their work within four hours if they went down.
2. Map each system to its vendor and delivery model: hosted, on premises, device, or in house. Note hosting regions and known subprocessors.
3. Find every file transfer and EDI server. Record product, version, location, internet exposure and the partners using it. Remove the ones nobody uses; the server nobody listed is the one that gets found.
4. Inventory your own code. List repositories and container images behind integration services, portals and APIs, and generate an SPDX or CycloneDX SBOM for each.
5. Tier the vendors. Critical if an outage stops freight within a day or the vendor has a remote connection into OT; High if it handles customer or shipment data; Medium and Low for the rest.
6. Record remote connections: tool, accounts, who approves sessions and where logs go. For Coast Guard regulated facilities this feeds 101.650(f)(3) directly.
7. Check against CISA KEV. Compare vendor products and your SBOMs with the Known Exploited Vulnerabilities catalog. Matches go to the top of the list.

Days 31 to 60: put terms on vendors and controls on builds

1. Send SBOM requests to Critical and High vendors. Name the product and version, cite CISA's 2026 Minimum Elements, accept SPDX or CycloneDX, and ask for a security contact and a notification process. Hosted vendors may decline; record the refusal and ask how they track components, because "asked on this date, refused" is still evidence.
2. Add standard clauses at the next renewal (table below), with renewal dates in a shared calendar.
3. Set build rules for your own code. Decide what fails a build (for example, a KEV listed vulnerability, or a critical one with a fix available) and what only warns. Write an exception process with an owner, a reason and an expiry date.
4. Fix the top of the list. Clear KEV matches and critical fixable findings first, batching upgrades by repository so reviewers see one change per service.
5. Agree patch windows with operations, including who can approve an emergency change during peak season and at sites with OT.

Have counsel draft the actual wording.

Days 61 to 90: rehearse, report and make it routine

1. Run a tabletop on a file transfer flaw (illustrative scenario): a KEV entry names your EDI team's file transfer product on a Friday in peak season. Who finds the servers, who decides to take them offline, how are partners told, and how do orders keep moving?
2. Run a tabletop on a hosted vendor outage: your TMS or WMS provider reports ransomware in its hosted environment. Who calls the vendor, what is the manual fallback, what do customers hear?
3. Time the "are we affected?" answer for a recently published open source vulnerability across repositories, images and vendor products. Write the number down; it is the metric a board understands.
4. Write a one page report: critical systems, vendor tiers, open KEV items, the time from step 3, and the decisions you need.
5. Set the cadence: monthly KEV and SBOM checks, quarterly reviews of Critical vendors, clauses at every renewal, tabletops twice a year.

A worked example (illustrative scenario)

The numbers are invented and round so you can redo them with your own. A 3PL runs 12 critical systems, depends on 40 software vendors and maintains 60 integration repositories. In the first 30 days it tiers 6 vendors Critical, 10 High and 24 Medium or Low, finds 3 file transfer servers (one nobody had listed), and its SBOMs show 15 KEV listed findings across 8 repositories.

By day 60 it has sent SBOM requests to the 16 Critical and High vendors and received 7, added the notification clause to the 4 contracts renewing that quarter, and merged upgrades clearing 12 of the 15 KEV findings; the other 3 have no fixed version and carry dated exceptions. By day 90 the tabletop shows the "are we affected?" answer for in house code takes about an hour, while vendor software still depends on 9 vendors without an SBOM. That gap leads the leadership report. The usual shape is exactly this: you get fast on your own code first, and the vendor gap is as much a procurement problem as a technical one.

For Coast Guard regulated operators, the tiered vendor list, the clause text and the remote connection register from this plan map directly to the three items 101.650(f) asks Section 4 of the Cybersecurity Plan to document.

How Safeguard does this

Everything above works without Safeguard. If you want the inventory, vendor requests, gates and fixes in one place, this is how the matching flow runs in Safeguard, using only what Safeguard's documentation describes. Every capability named here is generally available (GA).

The products involved are TPRM, Safeguard's Third-Party Risk Manager (GA); SBOM generation and analysis (GA) and SCA with deep transitive dependency scanning (GA) for your own code; vulnerability management with EPSS and CISA KEV enrichment (GA); reachability analysis and prioritization (GA); policies, gates and guardrails (GA); license compliance (GA); autonomous remediation with Griffin fix pull requests (GA), which ships switched off with every category set to Manual; and the Portal SBOM Repository (GA).

1. Inventory your own code from the CLI. The Safeguard CLI (GA) builds an SBOM for a target and matches it against vulnerability databases. The docs show these forms; we did not run them for this post:

   # The current directory
   safeguard scan --dir .
   # A container image
   safeguard scan --image nginx:latest
   # A Git repository
   safeguard scan --repo https://github.com/org/repo
   # An SBOM you already have
   safeguard scan --sbom sbom.json
   

   Per the docs, safeguard scan does not fail on findings: it exits 0 when the scan ran, 1 when the command itself failed and 2 when results were written but the vulnerability scan did not run, so a script never mistakes that for a clean pass.

2. Keep repositories on your side if you must. The local runner (GA) runs on your own machine, pulls the repository there, scans it there and pushes only encrypted results.

3. Store SBOMs by product and version. In the Portal SBOM Repository, create a product (name, SKU, description), associate SBOMs with it and track versions with comparison and diff. Import SBOM uploads one you already hold. Tags for environment, team ownership and compliance requirements let you mark which SBOMs support a critical freight system.

4. Add and tier vendors in TPRM. Click Add Vendor, enter company name, primary contact, contact email, website and products used, set the risk tier and save, matching the tiers from your first 30 days.

5. Request SBOMs. From the vendor, click Request SBOM, select the products, choose a template, customize the message if you want, set a deadline and click Send. For many vendors, select them under Vendors and click Bulk Request. The standard template covers SPDX and CycloneDX format requirements, required fields, submission instructions and the deadline; custom templates live under Settings → Request Templates. Requests move through Sent, Viewed, In Progress, Submitted, Validated and Rejected, with reminders 7 days before the deadline and at the deadline and an escalation 7 days after. Vendors can submit by email attachment, secure upload portal, API submission or direct integration.

6. Validate and send back what falls short. On arrival Safeguard checks format, completeness against required fields and compliance, scans for vulnerabilities and notifies the requester. If it falls short, click Request Revision and specify the corrections.

7. Turn on monitoring that matches the KEV habit. Under Settings → Monitoring, enable alerts for Critical Vuln (a new critical CVE), Exploited (a CVE added to CISA KEV), Risk Change (score below a threshold) and SBOM Expiry. Set re-scans of vendor SBOMs daily for critical vendors, or weekly, monthly or quarterly; re-assessment can trigger on new disclosures, major version updates, contract renewals and security incidents. Alerts go to email, Slack, Microsoft Teams, PagerDuty or a custom webhook, so the EDI owner can receive a KEV alert directly.

8. Prioritize what is reachable. Reachability analysis ranks findings by whether your application actually calls the vulnerable code, combined with EPSS and KEV, so the first fixes your integration team merges matter most. Measure the effect on your own repositories rather than relying on a quoted figure.

9. Write build rules as policies and enforce them with gates. Under Settings → Policies, click Create Policy, define conditions with the visual builder or YAML, set severity and actions, then save and enable. Documented conditions include vulnerability severity, CVSS, EPSS, license, component age and maintenance. A failed policy's action decides the gate: Block fails it, Warn passes with a warning naming the policy, Notify passes and sends a notification. Approvals run through exceptions: a developer clicks Request Exception, selects the policy and finding, gives a justification and expiry date, and approvers decide, with an audit trail. The docs show this CI form (not run for this post):

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

10. Fix with pull requests at your pace. Autonomous remediation lets Griffin open tested, policy gated pull requests that move a dependency to a safe version, for one repository or in bulk. It ships switched off with every category on Manual. During a peak season freeze, leave it on Manual and use it to prepare the pull requests you will merge afterwards.

11. Report and, if needed, stay inside the perimeter. The TPRM dashboard shows aggregate risk, vendors needing attention, score changes and upcoming SBOM expirations; scheduled reports run weekly to annually and ad hoc reports export to PDF or Excel. Policy reports show compliance by policy, exception history and violation trends. For terminals that allow no outbound internet, air-gapped deployment (GA) runs the full web app (ESSCM, Portal, TPRM and OSM) inside your perimeter, with signed snapshot bundles verified by a Receiver in the DMZ, and the docs state no component inside the perimeter calls outbound. On-prem and private VPC deployment (GA) and Zero AI mode (GA), which runs the platform with no LLM in the loop, are also available.

What Safeguard does not do

• It does not secure vendors' hosted platforms. It can show what a vendor's SBOM contains and alert you to new vulnerabilities in it, but fixing and restoring a hosted TMS or WMS is the vendor's job, and the manual fallback is yours.
• It does not monitor remote access sessions. The monitoring in 101.650(f)(3) needs your remote access tools, logs and review process.
• It does not write, sign or submit your Cybersecurity Plan. It supplies vendor lists, SBOMs and reports as evidence; the CySO owns the plan and the Coast Guard decides on approval.
• It does not decide materiality or file regulatory reports. SEC disclosure, any future CIRCIA report and any notice to a Captain of the Port are your decisions.
• It does not patch device firmware or OT systems. Telematics devices, ELDs, cranes and sortation controllers are patched through their vendors and your change process.
• It cannot make a vendor send an SBOM. TPRM tracks, reminds and escalates; the pressure comes from your contract and renewal calendar.

Common mistakes

• Starting from the IT asset list instead of operations. It misses the file transfer server a partner still uses and includes systems nobody depends on.
• Treating proposed rules as in force. The TSA surface rule and CIRCIA were still proposed when we checked; someone on the board may read the Federal Register.
• Asking every vendor for everything. Forty identical questionnaires produce forty late answers. Tier first.
• Forgetting the integration code. It is often bigger than people think, and it is the part you can fix fastest.
• Patching into peak season without a window. An upgrade that breaks a carrier adapter in November costs more than the flaw it fixed.
• Letting exceptions live forever. Every exception needs an owner and an expiry date.

FAQ

What is software supply chain security in logistics?

It is knowing what software and open source your freight operations depend on, holding vendors to security terms, controlling what your own teams ship, and responding quickly when a component or vendor is compromised. In logistics it centers on TMS, WMS, EDI and file transfer, telematics and the integration code connecting them.

Does the Coast Guard cybersecurity rule apply to my company?

It applies to owners and operators of US-flagged vessels, Outer Continental Shelf facilities and facilities subject to the Maritime Transportation Security Act regulations (33 CFR 101.605). A trucking company that only visits a terminal is reached indirectly, through the operator's vendor and access requirements. Confirm with counsel.

When are Coast Guard Cybersecurity Plans due?

The current text of 33 CFR 101.655 requires plans to be submitted for approval by 16 July 2027. The first Cybersecurity Assessment is due by the same date, then annually, and sooner after a change in ownership.

Is the TSA cybersecurity rule for rail final?

Not as of 25 October 2026. TSA proposed it on 7 November 2024 and comments closed on 5 February 2025; we found no final rule in the Federal Register.

Do logistics companies have to report cyber incidents under CIRCIA?

Not yet. The rule was proposed on 4 April 2024, and in May 2026 CISA was still holding town halls on its scope and burden. When it is final, check the covered entity criteria.

Should we ask our TMS and WMS vendors for an SBOM?

Yes, at least Critical and High tier vendors, per product and version, against CISA's 2026 Minimum Elements. Hosted vendors may decline; record the answer and ask how they track components and notify customers.

Why are file transfer and EDI servers such a common target?

They face the internet by design, hold partner credentials and business documents, and often run for years untouched. The Cleo exploitation in December 2024, with two vulnerabilities added to CISA KEV within a week, is the recent example most relevant to freight.

What is a good first metric for a freight security program?

The time to answer "are we affected?" for a newly published vulnerability across your repositories, images and vendor products. It is easy to explain, improves visibly as the inventory matures, and measures what matters during an incident.

How does CMMC relate to software supply chain security for carriers?

CMMC, in DoD contracts through the DFARS rule effective 10 November 2025, protects federal contract information and CUI on contractor systems. It does not require SBOMs, but the patch and support state of software on those systems is part of protecting them, so this inventory work supports an assessment.

Most incidents in this guide came down to a vulnerable component and the time it took to replace it. The section below explains how Safeguard closes that time for the open source and images you build and ship, which in freight usually means the integration services, portals and APIs your own teams maintain.

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 is a real Safeguard CLI session: install, open the interactive terminal, ask it to fix a lodash CVE in a repository, and watch it read the finding and advisory, ask before any command that changes something, edit package.json, run the install and tests with approval, and print a summary without pushing anything. The same flow applies to a carrier adapter or tracking portal repository.

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

The second demo sets up the local runner on your own machine, approves it with its device code and scans from the terminal. For a terminal operator or 3PL that will not grant a cloud service access to its repositories, this keeps the code on your side.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which Safeguard tools Claude can use. For a small freight security team, it is a way to ask plain language questions of the data Safeguard holds, within the tools you allow, while you work through the 90 day plan.

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

Related reading: using SBOMs to find affected products fast, the incident response playbook for a compromised dependency, and, for air freight, RTCA DO-326A and aviation supply chain security.

To try the flow yourself, download Safeguard or read the Safeguard docs.

Quick check

Sources

• Federal Register: Cybersecurity in the Marine Transportation System, final rule, 17 January 2025
• eCFR: 33 CFR part 101, subpart F
• Federal Register: Enhancing Surface Cyber Risk Management, proposed rule, 7 November 2024
• Federal Register: CIRCIA Reporting Requirements, proposed rule, 4 April 2024
• Federal Register: CIRCIA town hall meetings, 26 May 2026
• Federal Register: DFARS, Assessing Contractor Implementation of Cybersecurity Requirements
• CBP: CTPAT Minimum Security Criteria
• NIST Cybersecurity Framework 2.0
• NIST SP 800-161 Rev. 1
• NIST SP 800-218, Secure Software Development Framework
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: Reported supply chain compromise affecting XZ Utils
• EUR-Lex: Directive (EU) 2022/2555 (NIS2)
• SEC: Radiant Logistics Form 8-K, 20 March 2024
• SEC: United Natural Foods Form 8-K, 9 June 2025
• SEC: United Natural Foods Form 8-K, Item 1.05
• The Record: Australian ports operator recovering after major cyber incident
• The Record: Port of Seattle refuses Rhysida ransom
• Tech Monitor: Blue Yonder ransomware attack disrupts supply chains across UK and US
• Safeguard docs: Third Party Risk Manager
• Safeguard docs: TPRM Vendor Management
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: TPRM Monitoring
• Safeguard docs: Policies and Gates
• Safeguard docs: CLI usage
• Safeguard docs: Portal SBOM Repository
• Safeguard docs: Air-gapped deployment
• Safeguard docs: Reachability analysis

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