What does a vulnerable dependency mean for a port crane?

A vulnerable dependency inside crane software matters in proportion to what that software can touch. A library in a reporting dashboard is an IT problem. The same library inside a component that talks to a controller is an operational technology problem, where patching has to be weighed against safety and uptime. Start by knowing which of the two you have.

This post does not describe any real incident. It explains how the published standards frame the question, and what a software bill of materials adds.

Why is OT different from the office network?

NIST Special Publication 800-82 Revision 3 is guidance on securing operational technology while addressing its unique performance, reliability and safety requirements. It defines OT broadly: programmable systems and devices that interact with the physical environment or manage devices that do. Industrial control systems, transportation systems and building automation are among its examples.

The practical lesson is in the phrase "performance, reliability and safety." In an office, you patch quickly and reboot overnight. On equipment that moves loads, an update can change behavior, and a reboot may not be possible while operations run. The patch decision belongs to people who understand the machine, not only to the security team.

NIST notes on its publication page that an initial public draft of Revision 4 is open for comment, with comments due by November 30, 2026. Check the current revision before you cite a section number in a policy.

Which standards name the roles?

The ISA/IEC 62443 series covers cybersecurity for industrial automation and control systems. ISA describes it as a holistic approach that bridges operations and IT, and process safety and cybersecurity. Its parts are split by who carries the responsibility.

• Asset owners: Part 2-1 covers security program requirements for IACS asset owners.
• Service providers: Part 2-4 covers security program requirements for IACS service providers.
• Risk assessment: Part 3-2 covers security risk assessment for system design.
• System requirements: Part 3-3 covers system security requirements and security levels.
• Product suppliers: Part 4-1 covers secure product development lifecycle requirements, and Part 4-2 covers technical security requirements for components.
• Patching: Part 2-3 is a technical report on patch management in the IACS environment.

ISA lists transportation among the sectors that use these standards. That does not mean a given crane is certified to anything. It means the vocabulary exists, and a port operator can ask a supplier which parts they build to.

What does a vulnerable dependency add to this picture?

Controller firmware and vendor software are built from components, and many components are open source. A published vulnerability in one of them is only a finding until someone answers three questions.

1. Is the component present in what we run? A software bill of materials from the supplier answers this faster than a phone call.
2. Can the vulnerable code be reached from where it is deployed? A library that parses network input on a segment reachable from the internet is a different case from the same library on an isolated engineering laptop.
3. What is the cost of changing it? That depends on the maintenance window, the vendor's support position and any safety validation the change would trigger.

Reachability analysis is useful here for the first two questions, because it narrows a long list to the findings with a real path. It does not answer the third.

What should an asset owner ask suppliers?

• Do you provide an SBOM for the control and monitoring software, and how often is it updated?
• Which parts of the 62443 series do you build to, and can you show evidence?
• How do you notify us of a vulnerability in a component you ship, and in what time frame?
• Do you support a patch path that we can test in a staging environment before we touch production equipment?
• What is the support period for the version we run?

Write the answers into the contract or the procurement record. A verbal assurance does not survive a change of staff.

What to do

1. List the software that sits in or near crane control and monitoring: vendor applications, remote access tools, historians and gateways.
2. Ask each supplier for an SBOM and record the date you received it.
3. Run the SBOMs against a vulnerability source and sort by what is reachable from your network layout.
4. Separate findings into three lanes: patch in the normal window, patch with a safety review, and compensate with segmentation or monitoring until the vendor ships a fix.
5. Agree with operations who can approve each lane, and rehearse the process once on a non-critical system.
6. Re-check when the supplier ships a new version, and when NIST finalizes its next revision.

Quick check

Sources

• NIST SP 800-82 Rev. 3, Guide to Operational Technology Security
• ISA/IEC 62443 series of standards

Last reviewed: 18 October 2026.