Software supply chain security for maritime and ports: a 90-day plan

Software supply chain security for a port, terminal or US-flagged vessel operator means three things: knowing every piece of software that moves cargo and ships (the terminal operating system, the port community system, gate and crane automation, bridge and engine control, and the open source inside your own integrations), holding every IT and OT vendor to a written duty to tell you about vulnerabilities, and patching or compensating for known exploited vulnerabilities in critical systems without delay. In the US those duties are now regulation: the Coast Guard's cybersecurity rule in 33 CFR part 101, subpart F, writes them into the requirements for US-flagged vessels and regulated facilities, with Cybersecurity Plans due by 16 July 2027. A focused 90 day program gets most maritime operators from a spreadsheet of guesses to an approved software list, a vendor notification process and a response path they have rehearsed.

Below: the systems, the rules and their status, recent incidents, the owners, and a 30/60/90 day plan for any toolset. Safeguard appears only in "How Safeguard does this". This is not legal or regulatory advice; read the primary texts in Sources.

Key takeaways

• The Coast Guard rule (33 CFR 101 subpart F, effective 16 July 2025) requires an approved software list, an inventory, vendor notification terms and patching or compensating controls for known exploited vulnerabilities (KEVs) in critical systems "without delay".
• Plans and the first Cybersecurity Assessment are due by 16 July 2027; training deadlines began 12 January 2026.
• Foreign-flagged vessels are outside subpart F and follow IMO guidance (MSC.428(98), MSC-FAL.1/Circ.3/Rev.4) and class rules.
• Since February 2024, actual or threatened cyber incidents involving a vessel, harbor, port or waterfront facility must be reported immediately to the FBI, CISA and the Captain of the Port under 33 CFR 6.16-1.
• Recent port incidents and upstream software events all became inventory questions within hours.
• Ownership is split across the CISO, the Cybersecurity Officer (CySO), IT, GRC, procurement and OT; the plan gives each a job.
• Safeguard capabilities used here are all GA: SBOM generation and analysis, SCA, vulnerability management with EPSS and KEV, reachability analysis, policies and gates, license compliance, TPRM, the Portal SBOM Repository, autonomous remediation (ships off, every category on Manual), the CLI and local runner, and on-prem and air-gapped deployment.

The situation

The trigger is usually one of four events. The Coast Guard will review your Cybersecurity Plan before July 2027, and it must describe controls that exist. A customer or insurer questionnaire asks for your vendor list and patch speed. A vendor advisory lands for a product your gate or file transfer server depends on. Or another port is in the news and the board asks: could that happen here, and how fast would we know?

The person asked is rarely one person. At a terminal, the Facility Security Officer often works with, or doubles as, the new Cybersecurity Officer, while the head of IT owns the terminal operating system. At a US-flagged fleet operator, the Company Security Officer, the marine superintendent and shore side IT each hold pieces.

A bad week looks like this. A remote access product is added to CISA's KEV catalog on a Tuesday. Nobody can say that afternoon which terminals run it or whether the crane contractor reaches the OT network through it. The vendor's notice arrives four days later to a mailbox nobody watches, while your draft Plan promises KEVs are handled "without delay".

The rest of this guide is about making that week boring.

What software does a port, terminal or shipping company run?

Maritime software falls into five groups. Each has a different owner, a different update path and a different vendor relationship, which is exactly why a single inventory is hard and why it pays off.

Terminal and port operations

The terminal operating system (TOS) plans berths, yard positions, vessel stowage and equipment moves. Around it sit berth planning tools, yard and equipment control systems for ship to shore cranes, gantry cranes and straddle carriers, gate automation with optical character recognition cameras and truck appointment systems, reefer monitoring, and the dashboards terminal managers watch. Much of it comes from specialist vendors, is customized per terminal and is updated by the vendor's engineers on site or remotely. Crane controllers, drives and human machine interfaces run software you did not write, often with remote diagnostics over a link the maker maintains.

Port community and trade systems

A port community system (PCS) connects shipping lines, agents, forwarders, customs brokers, hauliers, terminals and the port authority so information is entered once and shared. It exchanges messages for bay plans, container movements and customs status and links to national single window systems. These platforms face the internet by design and hold credentials for many outside parties. Managed file transfer and EDI servers usually sit alongside them.

Shipboard OT and navigation

On board, the bridge runs electronic chart display and information systems (ECDIS), radar, the automatic identification system, the voyage data recorder and often an integrated bridge or navigation system. Below deck there are engine and propulsion control, power management, ballast water management, cargo loading and stability computers, and alarm and monitoring systems. Their software arrives through shipyards and makers and is updated by service engineers, subscriptions or remote sessions, rarely by your own staff.

Connectivity and shore side fleet systems

Ships carry satellite and cellular links, separate operations and crew networks, and remote support tools that let makers reach equipment at sea. On shore sit fleet management, planned maintenance, voyage performance, crewing and safety management systems, mostly hosted by vendors.

Your own code

Most operators now write integration software: adapters between the TOS and the port community system, APIs for trucking appointment apps, customer tracking portals, data pipelines for emissions and performance reporting, and scripts that move EDI between partners. This code pulls in open source packages and container base images, and it is the one part of the supply chain you can fix yourself the same day.

Which regulations and frameworks apply to maritime software?

Which rules apply depends on your flag, the facilities you operate and whether you build new ships. Status below was checked 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 proposed the rule on 22 February 2024, published the final rule on 17 January 2025 (90 FR 6298), and it took effect on 16 July 2025. Section 101.605 applies it to owners and operators of US-flagged vessels, facilities and OCS facilities that must have a security plan under 33 CFR parts 104, 105 and 106, and states that it does not apply to foreign-flagged vessels subject to part 104.

The owner or operator must maintain an approved Cybersecurity Plan and designate in writing a Cybersecurity Officer reachable by the Coast Guard around the clock (section 101.620). The measures in section 101.650 each name the Plan section that documents them. These matter most for supply chain work.

Device security, 101.650(b), Plan Section 6. Develop and maintain a list of approved hardware, firmware and software that may be installed on IT or OT systems; anything installed must be on that list. Keep an accurate inventory of network connected systems with critical ones designated, plus a network map and OT configuration records. Section 101.615 defines the "approved list" as an owner or operator's authoritative catalog for products that meet cybersecurity requirements.

Risk management, 101.650(e), Plan Sections 11 and 12. Complete a Cybersecurity Assessment no later than 16 July 2027 and annually after that, and sooner after a change in ownership. It analyzes all networks for vulnerabilities to critical systems and must document and ensure patching, or documented compensating controls, for all KEVs in critical IT or OT systems without delay. A penetration test accompanies each Plan renewal. Routine maintenance repeats the KEV duty, needs a method to receive publicly submitted vulnerabilities, keeps OT off the public internet unless operation requires it, and runs vulnerability scans as the Plan specifies.

Supply chain, 101.650(f), Plan Section 4. Three measures:

1. Consider cybersecurity capability as a criterion for evaluation when procuring IT and OT systems or services.
2. Establish a process through which all IT and OT vendors or service providers notify the owner, operator or CySO of any cybersecurity vulnerabilities or reportable cyber incidents, without delay.
3. Monitor and document all third party remote connections to detect cyber incidents.

Resilience and segmentation, 101.650(g) and (h). Report reportable cyber incidents to the National Response Center without delay, for entities that have not reported to the Coast Guard under, or are not subject to, 33 CFR 6.16-1. Exercise a Cyber Incident Response Plan, test backups, segment IT from OT and log every crossing.

The CySO's own duties in section 101.635 repeat the KEV point as a personal responsibility: ensure identification and mitigation of all KEVs in critical IT or OT systems, without delay.

Dates in the current text. Training was due by 12 January 2026 and annually after (101.650(d)(4)). The first Assessment is due by 16 July 2027 (101.650(e)(1)), and section 101.655 requires all Plans to be submitted by the same date. Section 101.660 makes the Plan and penetration test results available to the Coast Guard on request.

Read together, these clauses describe a software supply chain program: the approved list is a controlled software catalog, the inventory is a component register, "KEVs without delay" is a service level you must define and meet, and vendor notification is a contract clause plus an intake workflow.

Incident reporting: Executive Order 14116 and 33 CFR 6.16-1

On 21 February 2024 the President signed Executive Order 14116, amending the regulations on safeguarding vessels, harbors, ports and waterfront facilities, and it was published on 26 February 2024. The resulting text of 33 CFR 6.16-1 says evidence of sabotage, subversive activity, or an actual or threatened cyber incident involving or endangering any vessel, harbor, port or waterfront facility, including data, networks, programs and systems on it, "shall be reported immediately" to the FBI, CISA (for any cyber incident) and the Captain of the Port. Note how broad that is: it covers threatened incidents and it is not limited to US-flagged vessels. Your Cyber Incident Response Plan needs to name who makes those calls.

Cranes: MARSEC Directives 105-4 and 105-5

The Coast Guard announced Maritime Security (MARSEC) Directive 105-4 on 23 February 2024 (89 FR 13726), setting cyber risk management actions for owners or operators of ship to shore cranes manufactured by People's Republic of China companies, and MARSEC Directive 105-5 on 19 November 2024 (89 FR 91413), adding requirements to those in 105-4. Both are security sensitive and not public; affected operators obtain them from their Captain of the Port or District Commander. The point for this guide: a regulator treated the origin of a class of port equipment as a supply chain risk, so crane software belongs in your inventory.

IMO guidance for ships in international trade

The International Maritime Organization's position is guidance applied through existing safety management. The Maritime Safety Committee adopted Resolution MSC.428(98), Maritime Cyber Risk Management in Safety Management Systems, at its 98th session in June 2017. It encourages administrations to ensure cyber risks are appropriately addressed in safety management systems under the ISM Code no later than the first annual verification of the company's Document of Compliance after 1 January 2021. The IMO's current guidelines are MSC-FAL.1/Circ.3/Rev.4, Guidelines on Maritime Cyber Risk Management, which give high level recommendations and functional elements that can be built into existing risk management. The IMO page also points readers to industry guidance on board ships, IACS Recommendation 166, and the IAPH cybersecurity guidelines for ports and port facilities.

Classification society requirements for new ships

The International Association of Classification Societies (IACS) published UR E26, Cyber Resilience of Ships, and UR E27, Cyber Resilience of On-Board Systems and Equipment. According to IACS's press release, revised versions superseded the originals and apply to new ships contracted for construction on and after 1 July 2024, with applicability split into mandatory and non-mandatory compliance by vessel type and size. If you order new ships, ask the shipyard and makers what they deliver under these requirements about onboard systems; it is a natural starting point for your approved list.

NIST and CISA guidance that fills in the "how"

NIST's Cybersecurity Framework 2.0 has a supply chain category under Govern: GV.SC-04 (suppliers known and prioritized by criticality), GV.SC-05 (requirements built into contracts), GV.SC-07 (supplier risk monitored over the relationship) and GV.SC-08 (suppliers included in incident response). NIST SP 800-161 Rev. 1 is the detailed supply chain risk guide. CISA's KEV catalog is the practical reference for the rule's KEV language, and CISA's 2026 Minimum Elements for a Software Bill of Materials (29 July 2026) replaced the 2021 NTIA elements.

What happened in real maritime and port incidents in the last three years?

These public events from late 2023 to 2025 touched ports or the software the maritime sector depends on. Details come from 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

DP World Australia detected unauthorized access in November 2023, disconnected its systems from the internet and suspended operations at container terminals in several cities, including Sydney and Melbourne. The Record reported almost 30,000 containers stranded that weekend, citing local media, and quoted Australia's National Cyber Security Coordinator calling it "a nationally significant cyber incident."

The xz utils backdoor, March 2024

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

Port of Seattle, August 2024

The Port of Seattle, which runs maritime facilities and Seattle Tacoma International Airport, was hit by a ransomware attack that began on 24 August 2024. According to TechCrunch and The Record, the Port attributed it to the Rhysida group, said some Port data was obtained, refused to pay, and brought most affected systems back within a week while restoring others, such as its external website and internal portals, took longer. We cover it in more depth in Port of Seattle and the Rhysida ransomware attack.

Cleo managed file transfer, December 2024

On 13 December 2024 CISA added CVE-2024-50623, an unrestricted file upload vulnerability in multiple Cleo products, to the KEV catalog. Managed file transfer servers like these move EDI and documents between partners, the same class of internet facing server many port and terminal environments run.

What these events have in common

Each started outside the software the affected organization wrote, and each forced an inventory question within hours: do we run it, which version, where, and who supports it. You cannot act "without delay" on something you cannot find.

Who owns software supply chain risk at a port or fleet operator?

The CISO or head of security

The CISO needs a short trend the board and insurer can read: median age of open KEVs in critical systems, share of critical vendors with notification terms, share of remote connections logged. Triggers are the quarterly board pack, insurance renewal and the next port incident.

The Cybersecurity Officer, with the Facility or Company Security Officer

The CySO is the person the rule names, responsible for the approved list, KEV mitigation, vendor notification and remote connection monitoring being true on the day of inspection. The deadline is the Assessment and Plan by 16 July 2027, then every year.

The terminal or fleet IT owner and the VP of engineering

They own the TOS integrations, portals and pipelines and the release calendar. They need to know which components are inside and which matter, and to fix them without stopping the quay.

GRC and compliance

GRC needs evidence by clause in one place: the approved list and its review history, the inventory, dated KEV tickets, vendor terms, remote connection logs and training records, ready for the Assessment and for customer and insurer questionnaires.

Procurement and vendor risk

Sections 101.650(f)(1) and (f)(2) land on procurement: cybersecurity capability as a buying criterion and a notification process with every IT and OT vendor. They own the clause and the renewal calendar, which is the main pressure you have on a vendor.

OT, marine engineering and the marine superintendent

They control what makers install on cranes and ships and how makers connect, at dry docks, service visits and new builds. The approved list has to be practical for them: a version a maker installs during a port call must already be on it.

Integration developers

Developers need a short rule and an exact fix on their pull request: this component is blocked, here is the safe version, here is how to request an exception.

How do you secure maritime software in 90 days?

This plan works with spreadsheets, a ticketing system and whatever scanners you already have.

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

1. Name owners. Confirm the CySO and a deputy, and agree an owner for each system group in the table above. Section 1 of the Plan needs this structure.
2. Build the inventory of network connected systems. Start from network scans and vendor contracts, then walk the terminal and a vessel. The CySO marks which are critical (a compromise could lead to a transportation security incident).
3. Start the approved list from what is installed. Use the template below.
4. Subscribe owners to the CISA KEV catalog and decide what "without delay" means in your Plan, as a measurable target in days.
5. Produce SBOMs for the software you build (integrations, portals, pipelines) and ask your critical vendors for SBOMs of what they ship you, referencing CISA's 2026 Minimum Elements.
6. List every third party remote connection: who uses it, to which systems, how sessions are approved and where logs go.

Approved list template (one row per product and version):

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

1. Tier vendors by the criticality of the systems they touch. Critical vendors sit in critical systems or hold remote access.
2. Add notification terms to contracts. Use the checklist below at every renewal and purchase.
3. Make cybersecurity capability a purchase criterion. Add a short set of questions to every IT and OT purchase: SBOM availability, vulnerability disclosure policy, notification commitment, remote access method, support lifetime.
4. Put build rules on your own code. In CI, stop components with KEV listed or critical vulnerabilities from shipping unless someone approves a time limited exception.
5. Work the backlog in critical systems first. Where a patch cannot be applied during operations or at sea, document the compensating control and its expiry, as 101.650(e)(3)(i) allows.
6. Segment and log. Confirm IT and OT are segmented and every crossing is logged and monitored, per 101.650(h).

Vendor notification checklist for contracts:

• What the vendor must notify: vulnerabilities in products supplied and reportable cyber incidents affecting the service, matching 101.650(f)(2).
• How fast: "without delay", with a stated outer limit you can live with.
• To whom: a named role mailbox and a phone line monitored around the clock, not one person.
• What the notice contains: affected products and versions, exploitation status, available fix or mitigation, and a next update time.
• SBOM delivery: format, per release, and when it is updated.
• Remote access: approved method only, sessions logged, accounts named.
• Cooperation: participation in your incident response and exercises, matching CSF GV.SC-08.
• End of relationship: credential removal and data return when the contract ends.

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

1. Run a tabletop on a vendor advisory. Start from a KEV in a product on your approved list and time how long it takes to name affected terminals and vessels, apply a fix or compensating control, and make the 6.16-1 decision.
2. Report three numbers to the CISO and the board: age of open KEVs in critical systems, share of critical vendors with notification terms, share of remote connections with logged sessions.
3. Feed the results into the Cybersecurity Assessment and the draft Plan, Sections 4, 6, 11 and 12 in particular.
4. Set the routine: monthly approved list review, KEV review on every catalog update, tier review at renewal, an annual exercise.

A worked example (illustrative scenario)

A terminal operator with one container terminal and 200 IT and OT systems in its inventory designates 40 as critical. By day 30 it has an approved list for those 40 with versions and vendors, SBOMs for its 6 in house integration services, and SBOM requests out to its 10 critical vendors. By day 60, 7 of the 10 have signed notification terms, CI blocks KEV listed components in the integration services, and 3 open KEVs in critical systems have documented compensating controls because the vendor patch needs a maintenance window. By day 90, a tabletop shows that finding the affected systems takes under an hour instead of two days. These numbers are invented and round; replace them with your own.

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, writing the results as JSON. The docs show these forms (not run 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 policy says so. 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, click Create Product, enter name, SKU and description, and associate SBOMs with it. Version comparison shows added and removed components and new and resolved vulnerabilities. Import SBOM uploads one a vendor or shipyard gave you, and tags mark which SBOMs back a critical system.

4. Add and tier vendors in TPRM. Each vendor record holds products, primary contact, contract status, a risk tier (Critical, High, Medium or Low), SBOM status and last assessment; a CSV bulk import loads an existing spreadsheet. TPRM can suggest tiers from data access level and system criticality, and you can override with a documented justification. Contract management links contract documents, SLA terms, security requirements and SBOM obligations to the vendor, which is where notification clause status can live.

5. Request SBOMs from vendors. 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. Requests move from Sent through Validated or Rejected, with reminders 7 days before 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 the format is valid SPDX or CycloneDX, checks required fields, runs a vulnerability scan and notifies the requester. If an SBOM falls short, click Request Revision and specify the corrections.

7. Turn on monitoring that matches the KEV clause. Under Settings → Monitoring, enable alerts for Critical Vuln (a new critical CVE), Exploited (a CVE added to CISA KEV), Risk Change and SBOM Expiry. Re-scan vendor SBOMs daily for critical vendors, or weekly to quarterly for the rest. Alerts go to email, Slack, Microsoft Teams, PagerDuty or a custom webhook, so the owner named on the approved list hears about a KEV directly.

8. Prioritize what is reachable in your own code. Reachability analysis checks whether your code actually calls the vulnerable function, and combines that with EPSS, KEV and context into one ranked backlog. Measure the effect on your own repositories rather than relying on any quoted figure.

9. Write build rules as policies and enforce them with gates. Under Settings → Policies, click Create Policy, define conditions (severity, CVSS, EPSS, license, component age, maintenance) with the visual builder or YAML, set actions, then save and enable. A failed policy's action decides the gate: Block fails it, Warn passes with a warning naming the policy, and Notify passes and sends a notification. Approval runs through exceptions: a developer clicks Request Exception with a justification and expiration 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 terminal cutover, leave it on Manual and prepare pull requests for the next window.

11. Report, and stay inside the perimeter if you must. The TPRM dashboard shows aggregate risk, vendors needing attention and upcoming SBOM expirations; scheduled reports run weekly to annually, with ad hoc exports to PDF or Excel. Where production allows no outbound internet, air-gapped deployment (GA) runs the full web app inside your perimeter from signed snapshot bundles verified by a Receiver in the DMZ; the docs state no component inside 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 patch ECDIS, engine control, crane PLCs or other maker supplied OT. Those fixes come from the maker through your change process and, at sea, through service engineers or approved remote sessions.
• It does not monitor remote access sessions. The monitoring and documentation in 101.650(f)(3) needs your remote access tools, their logs and your review process.
• It does not discover every network connected device. The device inventory and network map in 101.650(b) come from your network tools and site walks; Safeguard holds the software and SBOM side.
• 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 what is reportable or make reports. Calls to the FBI, CISA and the Captain of the Port under 6.16-1, and reports to the National Response Center, are your decisions and your calls.
• It cannot make a vendor send an SBOM or sign a notification clause. TPRM tracks, reminds and escalates; the pressure comes from your contract and renewal calendar.
• It does not secure a vendor's hosted platform. Restoring a hosted port community system is the vendor's job, and the manual fallback is yours.

Common mistakes

• Treating the approved list as a purchasing list. The rule asks for a list of what may be installed, and requires that what is installed is on it. Build it from what is actually running, then control changes.
• Leaving vendor notification to goodwill. Without a clause and a monitored inbox, notices arrive late and to the wrong person. Put the term in the contract and the address in the Plan.
• Counting KEVs without timing them. "Without delay" is judged by how long a KEV stays open in a critical system. Track open dates, not just totals.
• Forgetting the ship. Bridge, engine and cargo systems have versions too, and makers update them during port calls.
• Assuming foreign flag means no obligations. Subpart F does not apply to foreign-flagged vessels, but 6.16-1 reporting is written for any vessel, harbor, port or waterfront facility.
• Writing compensating controls with no end date. Give each one an owner and a review date.

FAQ

Does the Coast Guard cybersecurity rule apply to foreign-flagged ships?

No. Section 101.605(b) says subpart F does not apply to foreign-flagged vessels subject to 33 CFR part 104. Those ships follow IMO guidance through their flag state and safety management system audits. The reporting requirement in 33 CFR 6.16-1 is written more broadly and covers actual or threatened cyber incidents involving any vessel, harbor, port or waterfront facility.

When are Coast Guard Cybersecurity Plans due?

Section 101.655 requires all Cybersecurity Plans to be submitted for review and approval no later than 16 July 2027. The first Cybersecurity Assessment is due by the same date and annually after that. Training was due by 12 January 2026 and annually after that.

What does "KEV" mean in the Coast Guard rule?

It refers to known exploited vulnerabilities, the vulnerabilities CISA lists in its Known Exploited Vulnerabilities catalog. The rule requires patching or documented compensating controls for all KEVs in critical IT or OT systems without delay, both in the Cybersecurity Assessment and in routine maintenance.

Do we need SBOMs from our TOS and OT vendors?

The rule does not use the word SBOM, but it requires an approved list, an inventory and vendor notification, and an SBOM is the most direct way to see which components sit inside a vendor product when a KEV lands. Ask for one per release.

What is an approved list under 33 CFR 101.650(b)?

A list of hardware, firmware and software that may be installed on IT or OT systems. The definition in 101.615 calls it an owner or operator's authoritative catalog of products that meet cybersecurity requirements. Anything installed must be on it.

Who must we notify about a cyber incident at a port?

Under 33 CFR 6.16-1, evidence of an actual or threatened cyber incident involving or endangering a vessel, harbor, port or waterfront facility must be reported immediately to the FBI, CISA and the Captain of the Port. Check the current text with counsel before writing your procedure.

How do we handle a KEV we cannot patch during operations or at sea?

The rule allows documented compensating controls. Record the control, the system, who approved it and when it will be reviewed, and patch in the next maintenance window or port call. Keep the record with your Plan evidence.

What is a good first metric for a maritime software security program?

The age of open KEVs in critical IT and OT systems. It maps to the rule's "without delay" language and improves only when inventory, vendor notification and patching all work.

The KEV clause in 33 CFR 101.650(e) is easiest to meet in the code you build yourself, because there you can ship the fix the same day instead of waiting for a vendor visit or a port call. The section below covers the options Safeguard offers for those open source dependencies and images, including what to do when no upstream fix exists 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 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 port community adapter or a customer tracking portal.

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 fleet 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 maritime 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 plan.

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

Related reading: the logistics and freight guide in this series, the manufacturing OT guide, using SBOMs to find affected products fast and the incident response playbook for a compromised dependency.

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

Quick check

Sources

• eCFR: 33 CFR part 101, subpart F, Cybersecurity
• Federal Register: Cybersecurity in the Marine Transportation System, final rule, 17 January 2025
• Federal Register: Cybersecurity in the Marine Transportation System, proposed rule, 22 February 2024
• eCFR: 33 CFR 6.16-1
• Federal Register: Executive Order 14116, 26 February 2024
• Federal Register: MARSEC Directive 105-4, 23 February 2024
• Federal Register: MARSEC Directive 105-5, 19 November 2024
• IMO: Maritime cyber risk
• IACS: UR E26 and E27 press release
• NIST Cybersecurity Framework 2.0
• NIST SP 800-161 Rev. 1
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: Reported supply chain compromise affecting XZ Utils
• CISA: CISA adds one known exploited vulnerability to catalog, 13 December 2024
• The Record: Australian ports operator recovering after major cyber incident
• The Record: Port of Seattle refuses Rhysida ransom
• TechCrunch: Port of Seattle shares ransomware attack details
• 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: Reachability analysis
• Safeguard docs: Air-gapped deployment

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