How a Submarine Is Built and Maintained: Hulls, Sonar, Software, Docks

A submarine is built by welding high strength steel into thick cylindrical hull sections, filling those sections with pipework, machinery and electronics while they are still open modules on land, joining the modules into one pressure hull, and then testing the boat alongside and at sea for months before it enters service. It is kept in service by a cycle of short maintenance periods alongside and long docking periods out of the water, and the number of dry docks, floating docks and shiplifts a navy can use limits how many boats it can have ready at any time.

As with the satellite and spacecraft builds we covered earlier, inside that steel shell sits a dense software estate: sonar processing, combat management, navigation, ship control and platform monitoring, much of it now running on commercial processors and operating systems that are refreshed on a planned cycle. That is why this post ends with the software supply chain rules defence suppliers have to meet. Everything here comes from public, unclassified sources: shipbuilders, navies, the US Congressional Research Service, the UK Ministry of Defence, NIST and the US Department of Defense. Nothing here describes the vulnerabilities or tactics of any navy's systems.

Key takeaways

• Docks are the bottleneck this month. On 28 September 2026 the UK confirmed three new floating docks for HM Naval Base Clyde (Programme Euston), competed among UK yards. A 19 October Navy Lookout article argues for a common AUKUS design.
• Dock capacity sets availability. The Congressional Research Service reports that the number of US attack submarines in depot maintenance or waiting for it rose from 11 boats (about 21 percent of the force) in FY2012 to 16 boats (about 33 percent) as of FY2023, against a Navy goal of 20 percent.
• A pressure hull is a welded steel cylinder held round by internal frames, made from qualified high yield steel with every weld inspected.
• Modern boats are built in modules, increasingly by suppliers away from the final assembly yard.
• The combat system runs on commercial hardware, refreshed on a schedule, which brings commercial operating systems and libraries, with their own vulnerability and obsolescence cycles, inside a closed platform.
• Suppliers carry formal cyber duties. In the US, DFARS 252.204-7012 requires NIST SP 800-171 protection for covered defense information and incident reports within 72 hours, and the CMMC program rule (32 CFR Part 170) verifies it. In the UK, Def Stan 05-138 Issue 4 sets requirements by Cyber Risk Profile, Level 0 to Level 3.
• A delivered system is not static. Its inventory and SBOM must be kept current through every refresh, not filed once at acceptance.

Why are floating submarine docks in the news?

On 28 September 2026 the UK government announced that the Royal Navy's submarine service at HM Naval Base Clyde will receive three new floating docks, known as Programme Euston, through a UK only competition. The announcement says the docks will provide maintenance for the current and future fleet of nuclear submarines, "allowing essential inspections, upgrades and repairs to be carried out."

On 19 October 2026 Navy Lookout, an independent Royal Navy news site, published a guest article by Rear Admiral Peter Briggs, Royal Australian Navy (retired), arguing that the UK, US and Australia should build nuclear capable floating docks to a common design. His case, in summary:

• Faslane relies on a single shiplift that he describes as about 30 years old. Because nuclear safety rules forbid moving a reactor that has gone critical ashore over land, a breakdown at the shiplift stops out of water maintenance for the base.
• Devonport's graving docks are designed for multi year deep maintenance, so sending Clyde boats south for short repairs ties up those slots and keeps crews away from home.
• In the US, he cites a GAO report published in August 2026 finding that maintenance delays cost attack submarines around 15,000 operational days between 2016 and 2025. (We could not open the GAO report itself, because gao.gov refuses scripted requests, so treat that figure as Navy Lookout's summary until you check it.)
• Australia needs a nuclear certified dock at Henderson in Western Australia before Virginia class boats transfer, the first of which he says is due in 2032. A design contract for a joint Australian and US floating dock design for Henderson was awarded in July 2026, with a functional design due by mid 2027.
• The 188 metre floating dock Atlas, built for General Dynamics Electric Boat, arrived at Groton, Connecticut, in January 2026 to launch Columbia class submarines rather than to maintain boats, and a new US Navy Auxiliary Floating Dry Dock Medium (AFDM 15) launched in July 2026 is designed for surface ships up to 18,300 tonnes and is not nuclear certified.

He also estimates that the bare steel hull of a nuclear capable floating dock is only about 20 to 30 percent of its cost, with nuclear systems, power, cooling and controls around 40 to 50 percent. In other words, a modern dock is mostly a utility plant full of control systems, not just a steel box.

The UK Defence Nuclear Enterprise 2026 annual update to Parliament, published 15 September 2026, gives the wider context. It describes HM Naval Base Clyde (Faslane and Coulport) as home to the UK Submarine Service, a supply chain of over 6,000 UK based businesses, a programme called Project Royal Oak putting £26bn into naval bases over the next decade, and £7.1bn over ten years into HMNB Devonport.

Why does dock capacity limit how many submarines are available?

A submarine is always either available, in maintenance or waiting for maintenance. Hull, propeller, shaft seal, sea valve and sonar dome work needs the boat out of the water. If no dock is free when a period comes due, the boat waits alongside, often with operating restrictions, or the work is deferred and the next period grows.

The CRS report on the Virginia class program (RL32418, updated 26 January 2026) puts numbers on the US version of this problem. It reports that the number of attack submarines in depot maintenance or idle while waiting for it rose from 11 boats, about 21 percent of the force, in FY2012 to 16 boats, about 33 percent, as of FY2023. It notes that the Navy adopted 20 percent as its goal, and quotes Navy testimony that late depot periods at public and private yards "have consumed all the dry docks," leaving few options for emergent dockings.

A 2025 press account reprinted in the same report notes that the four remaining US public shipyards have more than half their equipment past its expected service life, according to GAO.

Nuclear propulsion adds a constraint that diesel boats do not have. Navy Lookout's article explains that regulators in the UK and Australia do not allow a hull with a reactor that has gone critical to be lifted ashore on a shiplift and moved by rail. Such boats need a floating dock or a graving dock, and both need nuclear certification, shore power, cooling and effluent systems that take years to design and approve.

How is a submarine built, from steel plate to sea trials?

The table below follows a typical modern build, using what US and UK public sources say about Virginia, Columbia, Astute and Dreadnought class construction. Durations are indicative ranges from public reporting, not schedules for any particular boat.

Two public figures show the overall scale. The CRS Virginia report says that since 2022 the actual US production rate has been about 1.1 to 1.2 boats per year against a procurement rate of two per year, creating a backlog of boats bought but not yet built. The UK DNE update says new infrastructure at Barrow-in-Furness and Raynesway is intended to let the enterprise produce a submarine every 18 months in the future, and records that steel was cut for the fourth and final Dreadnought class boat in September 2025.

Who builds a submarine?

Only two US shipyards can build nuclear powered ships: General Dynamics Electric Boat (Groton, Connecticut and Quonset Point, Rhode Island) and Huntington Ingalls Industries Newport News Shipbuilding in Virginia. CRS notes that these are also the only two capable of final assembly of submarines. Behind them sits a large supplier base. CRS reports suppliers in all 50 states, and that about 70 percent of the critical suppliers for submarine construction are sole source.

When CRS quotes the Navy's own description of what that supplier base must produce more of, the list is telling: steel and specialty metals, high tech castings and forgings, electrical components, combat systems, propulsion plant components, valves, pumps, pipes, fittings and fans, and "software and information systems." Software is named as a supply chain input alongside steel.

In the UK, the DNE update says reactors for all UK submarine classes are manufactured by Rolls-Royce Submarines at Raynesway near Derby, boats are built at Barrow-in-Furness, deep maintenance is carried out at Devonport, and operations run from the Clyde.

How is a pressure hull built?

The pressure hull is the part of the submarine that keeps the sea out at depth. Everything else, including the outer casing, fin (sail), much of the ballast tank structure and the sonar domes, may be free flooding or lightly built. The pressure hull is not.

The shape: cylinders, cones and domes

A cylinder resists external pressure well for the material it uses, and a sphere does even better. Real pressure hulls are long cylinders, sometimes with conical transitions where the diameter changes, closed at each end by domed or dished bulkheads. The hull is subdivided by internal watertight bulkheads, and pierced by as few openings as possible: hatches, torpedo tubes, shaft and sea valve penetrations, and cable glands. Every penetration is a design and inspection problem, which is part of the reason modern masts no longer pass through the hull (see below).

Under external pressure a thin cylinder is more likely to fail by buckling than by the steel yielding, so the shell is stiffened with internal ring frames welded to it at regular intervals. The frames keep the cylinder round. A hull that is out of round loses buckling strength, so builders measure circularity as the cylinders are fabricated and again after welding.

The steel

Military submarine hulls use quenched and tempered high yield steels. In the US and allied navies these have long been the HY series, HY-80 and HY-100, where the number is the minimum yield strength in thousands of pounds per square inch. A public 1988 report from Australia's Defence Science and Technology Organisation, Properties of HY-100 Steel for Naval Construction (MRL-R-1149), shows what qualifying such a steel involves. The plate was made to US military specification MIL-S-16216J, water quenched and tempered, and tested for chemistry, tensile strength (HY-100 is the 690 MPa yield grade), Charpy impact toughness at minus 40 degrees Celsius and explosion bulge crack starter tests, to meet the US Naval Sea Systems Command's first article qualification. The steelmaking itself controls oxygen, nitrogen and hydrogen to low levels to avoid flaws and keep toughness high. That work supported the Australian Submarine Corporation's build of a Swedish designed submarine for the Royal Australian Navy.

The higher the yield strength, the thinner and lighter the hull can be for a given depth, but the more demanding the steel is to weld. Weld procedures and welders are qualified separately from the plate, and procedures control heat input and use low hydrogen consumables to avoid cracking.

The plate itself arrives with mill certificates that trace each heat of steel to its chemistry and mechanical tests. That traceability is the hardware equivalent of a software bill of materials: if a heat of steel or a batch of welding wire is later found defective, the yard needs to know exactly which hull sections it went into.

Welding and inspection

Hull sections are joined with full penetration welds. Welders and procedures are qualified in advance, and every structural weld in the pressure hull is inspected. Typical non destructive methods are visual inspection, magnetic particle testing for surface cracks, and radiography or ultrasonic testing for internal flaws. Records of who welded what, with which procedure and consumables, and how it was inspected, are kept for the life of the boat.

Finished hulls are proven by test. Builders run tightness tests on compartments and hull openings, and the boat makes a series of progressively deeper dives during sea trials before it is accepted.

Modular construction

Older submarines were built largely as a hull on a slipway that workers then filled from the inside through hatches. Modern practice is modular: the hull is built as a number of large cylindrical sections, and each is outfitted with decks, tanks, pipework, cabling, machinery and equipment racks while it is still open at the ends and easy to reach. Fully outfitted modules are then moved together and joined.

CRS quotes the US program executive officer for attack submarines describing how companies across the US now build structural pieces of submarines, "including some large modules," that used to be built at Electric Boat and Newport News, and then ship them to the shipyard for assembly. Modularity is also how the Virginia Payload Module was added: CRS reports that Virginia boats with the VPM are 84 feet longer, 461 feet in total, with a submerged displacement of about 10,200 tons.

The same idea shows up in the strategic submarine programmes. CRS reports that the US and UK designed a Common Missile Compartment for the Columbia and Dreadnought classes, with a modular design that accommodates a different number of launch tubes in each class.

Modular build moves risk around. A module built hundreds of miles away carries its own wiring, equipment and, increasingly, embedded controllers and software, and each is a supplier deliverable that has to be recorded and tracked into the finished boat.

What goes inside a submarine?

At concept level, a submarine is a pressure hull wrapped around five groups of systems.

Propulsion and power

Nuclear powered submarines use a pressurised water reactor to raise steam for turbines, which drive the propeller either through gearing or through electric motors. CRS reports that the Columbia class will use an electric drive system, an X stern control arrangement and a reactor designed to last the entire 42 year service life, so the boat never needs a mid life refuelling. That matters for maintenance planning: CRS notes that the Ohio class it replaces was certified for 42 years made up of two periods of roughly 19 years of operation separated by a midlife refuelling overhaul of about four years.

Conventionally powered submarines run diesel generators to charge large battery banks and run on battery power when submerged. Some designs add an air independent propulsion system so they can stay dived longer without raising a snorkel, and newer designs use lithium ion batteries instead of lead acid cells. Each of these choices brings its own monitoring electronics and battery management firmware.

Sonar

Sonar is the main sensor. A modern boat typically carries a large bow array, flank arrays along the sides of the hull, and one or more towed arrays streamed behind the boat on a long cable. Arrays are made of many hydrophones. The same Navy fact file notes that from Virginia Block III the traditional air backed sonar sphere was replaced with a water backed Large Aperture Bow array, part of a redesign of about 20 percent of the ship to cut acquisition cost. The value is in the processing: beamforming, filtering and classification turn thousands of channels of raw acoustic data into tracks and contacts an operator can use. That processing is software.

Masts and periscopes

Traditional periscopes are optical tubes that pass through the pressure hull into the control room. The US Navy's attack submarine fact file says that in the Virginia class "traditional periscopes have been supplanted by two photonics masts" carrying visible and infrared digital cameras on telescoping arms, and that removing the barrel periscopes let the control room move down a deck and away from the hull's curvature. Removing a large hull penetration is a structural win, but it turns a mechanical optic into a networked digital system with its own processors and software.

Combat system

The combat system brings together sonar, other sensors, navigation, fire control and weapons handling into a common picture for the command team. It is a distributed computing system of consoles, servers, network switches and storage, connected to the boat's own navigation and ship control systems.

Platform systems

Ship control, ballast, hydraulics, atmosphere control and electrical distribution each have their own controllers and software, often built from the same industrial control components used ashore.

How do sonar and combat system software programmes run on commercial hardware?

Until the 1990s, navy combat systems ran on purpose built military computers that stayed in service for decades. Commercial processors overtook them in performance, and military unique computers became expensive to sustain. The US Navy's answer for submarine sonar was Acoustic Rapid COTS Insertion (A-RCI), designated AN/BQQ-10. A 1998 Federation of American Scientists summary describes it as a four phase programme, starting in November 1997 with towed array processing, to move existing submarine sonar systems onto a commercial off the shelf, open system architecture and give the force a common sonar system. It notes that "COTS/OSA technologies and systems will enable rapid periodic updates to both software and hardware," with laboratory and at sea testing before upgrades are distributed.

The US Navy's current fact file makes the same point for the whole Virginia class: through "modular construction, open architecture, and commercial off-the-shelf components," the class is designed to stay current for its entire life through rapid introduction of new systems and payloads. In practice change arrives in two streams: periodic hardware refreshes, often called technology insertions, so the fleet does not sit on obsolete processors, and software builds that deliver new capability onto compatible hardware. Programme specific cycle lengths are not something we could confirm from public primary sources, so we do not quote them.

Why commercial hardware creates a patching and supply chain problem

The commercial approach solved the obsolescence and performance problem, but it imported the commercial software supply chain into a platform that does not behave like an office network.

• Commercial components have commercial vulnerability cycles. Operating systems, network stacks, libraries, middleware and firmware inside commercial servers receive security advisories on the vendor's schedule, not the navy's.
• The platform cannot patch on demand. Mission software is tested and certified against a specific hardware and software baseline, and a boat at sea or deep in a maintenance period cannot simply pull updates. Changes are bundled into the next certified build or the next technology insertion, which can be months or years away.
• Configuration is spread across organisations. Integrator, shipyard, sub tier suppliers, support contractor and navy all touch the baseline; without a shared inventory nobody holds the full list.
• Not everything is on the boat. Trainers, simulators, test benches and maintenance laptops run the same software on more connected networks.
• Obsolescence and vulnerability management collide. A component can be both end of life and vulnerable, and the replacement may only arrive at the next insertion.

None of this describes a weakness in any particular system; it is the general consequence of building long lived platforms from short lived commercial parts. The policy level answer is the one other regulated industries use: know exactly what software and firmware is in each delivered baseline, record it in a machine readable SBOM, map vulnerability information onto that baseline as it changes, and plan remediation into the next build or insertion with documented risk acceptance in between.

How is a submarine maintained?

Maintenance is organised in levels. Terms vary between navies, but the shape is similar.

The DNE 2026 update gives a current UK example: HMS Astute is preparing for its Mid Life Re-Validation Period at Devonport after a 15 year first commission. It also describes a Submarine Maintenance Period for HMS Anson at HMAS Stirling near Perth in March 2026, in which 17 Australian businesses supported the work and 34 components were made locally.

Floating dock, graving dock or shiplift?

There are three ways to get a submarine out of the water.

Whichever option is chosen, a modern dock is full of pumps, valves, cranes, power and cooling systems with control software, and will itself be maintained and upgraded for decades.

What public audits have said about maintenance delays

CRS summarises the US situation in two figures already cited: boats idle or in depot maintenance rose to about a third of the attack submarine force by FY2023, against a goal of 20 percent. It quotes the June 2025 GAO annual assessment of major weapons programs as finding that the Virginia class construction rate fell to 1.15 boats per year in 2024, short of the Navy's goal of 1.5, and that workforce, material and supplier delays were among the drivers. For the Columbia class, CRS reports GAO's finding that the second boat was about 12 percent behind schedule after more than a year of formal construction, and that it can take years for new suppliers to complete qualification.

GAO's November 2018 report on attack submarine maintenance (GAO-19-229, read through an archived copy because gao.gov blocks scripted requests) found that between fiscal years 2008 and 2018 attack submarines incurred 10,363 days of idle time and maintenance delays from getting into and out of shipyards, and estimated the Navy spent more than $1.5 billion (fiscal 2018 dollars) supporting boats that provided no operational capability while they waited. Its example was USS Boise, which could no longer conduct normal operations from June 2016 and sat idle pierside waiting for a shipyard. We could not open the August 2026 GAO report Navy Lookout cites, so its 15,000 day figure is quoted only as Navy Lookout's summary.

What do defence suppliers have to meet for software and cyber?

Whatever a company supplies, from a valve controller to dock control software, it will usually handle sensitive technical data under contracts with cyber clauses. This is a summary for orientation, not legal advice; your contract is what binds you.

United States: DFARS 252.204-7012, NIST SP 800-171 and CMMC

DFARS 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting, is the clause most US defense contracts carry. The current version in the eCFR is dated May 2024. In summary, it requires contractors to provide adequate security on covered contractor information systems, which for systems not operated on behalf of the government means implementing NIST SP 800-171; to report cyber incidents that affect covered defense information to the DoD within 72 hours of discovery; to preserve images of affected systems and relevant monitoring data for at least 90 days; and to flow the clause down to subcontractors whose work involves covered defense information.

NIST SP 800-171 sets the security requirements for protecting controlled unclassified information (CUI) in nonfederal systems. Revision 3 was published in May 2024 and supersedes Revision 2 of January 2021. NIST also publishes SP 800-171A, the assessment procedures, as a companion. Note one nuance: the CMMC program rule was written against Revision 2, so check which revision your contract and your assessment reference.

CMMC verifies that contractors have actually implemented these requirements. The CMMC Program final rule (32 CFR Part 170) was published in the Federal Register on 15 October 2024 and took effect on 16 December 2024. The companion DFARS rule that puts CMMC requirements into contracts (DFARS Case 2019-D041) was published on 10 September 2025 and took effect on 10 November 2025. Under 32 CFR 170.14, CMMC has three levels: Level 1 uses the basic safeguarding requirements of FAR 52.204-21 for federal contract information, with an annual self assessment; Level 2 requirements are identical to NIST SP 800-171 Revision 2; and Level 3 adds selected requirements from NIST SP 800-172. Section 170.3 phases requirements in over four phases. Phase 1 began on the DFARS rule's effective date with Level 1 and Level 2 self assessments as a condition of award, and Phase 2, one calendar year later, adds Level 2 third party (C3PAO) assessments for applicable contracts.

For deeper coverage of CMMC itself, see CMMC 2.0 explained and the CMMC 2.0 software supply chain guide.

United Kingdom: Def Stan 05-138

Def Stan 05-138, Cyber Security for Defence Suppliers, applies to all MOD procurements and to MOD suppliers and their subcontractors with a relationship to an MOD contract. Issue 4 is dated 14 May 2024. Its main change from Issue 3 was to replace the five Cyber Risk Profiles (N/A, Very Low, Low, Moderate and High) with four: Level 0, Level 1, Level 2 and Level 3. A risk assessment under the MOD's Cyber Security Model assigns each contract a profile, and Table 1 of the standard lists which controls apply at each level. Controls in that table include up to date network diagrams and, at the higher levels, automated discovery tools to keep an up to date asset inventory.

How the rules compare

Neither regime is an SBOM mandate by itself, but both expect a supplier to know what is on its systems and manage configuration and vulnerabilities. An SBOM per delivered system is the most practical way to show that for software.

Step by step: a supplier's software assurance routine

This walkthrough is for a company that delivers software, firmware or computer based equipment into a naval programme and builds at least some of that software itself. The commands are read only.

1. Scope the systems that handle controlled information

List every system that stores, processes or transmits CUI (US) or MOD contract information (UK): engineering workstations, build servers, source control, file shares, email, test rigs and laptops. Draw the boundary on a network diagram. Anything inside the boundary is in scope for NIST SP 800-171 or your Def Stan 05-138 profile; anything outside should not hold the data.

cui-boundary.md
- Source control: internal Git server (contains delivered software source)
- Build: two build servers and artifact store
- Engineering: 14 CAD and software workstations
- Test: hardware in the loop rig (bench copy of delivered processor)
- Email and file transfer: approved encrypted channel only
- Out of scope: corporate website, marketing laptops

2. Inventory the software and firmware you deliver

For each delivered item, record the hardware model, firmware versions, operating system and version, and every software package and library in the image. On Linux based delivered images or bench copies, read only commands give you a first inventory.

# Operating system and kernel of a bench copy of the delivered image
cat /etc/os-release
uname -r

# Installed packages (Debian or Ubuntu based images)
dpkg-query -W -f='${Package}\t${Version}\n' > packages.tsv

# Installed packages (RPM based images)
rpm -qa --qf '%{NAME}\t%{VERSION}-%{RELEASE}\n' > packages.tsv

# Firmware and hardware identity, read only (needs root)
sudo dmidecode -t bios -t system
lspci -nn

Only run these on equipment you own or are authorised to inspect; on a delivered system, the customer's procedures decide what may be run.

3. Produce an SBOM for each delivered baseline

Generate an SBOM from the source and build of each delivered software item, and keep it versioned with the release. With the Safeguard CLI, you can scan the repository, the container image or an existing SBOM file; results are written as JSON under ./output.

# Scan the repository that builds the delivered software
safeguard scan --dir .

# Scan a container image used in the delivered system or its test rig
safeguard scan --image registry.example.internal/combat-display:4.2.1

# Ingest an SBOM supplied by a sub tier supplier
safeguard scan --sbom supplier-sbom.cdx.json

For commercial components you do not build, such as a vendor operating system image or a processor board's firmware, ask the supplier for an SBOM in CycloneDX or SPDX format. Where none exists, record the component manually so it at least appears in your inventory. CycloneDX has a firmware component type for exactly this.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "metadata": {
    "component": {
      "type": "device",
      "name": "display-processor-unit",
      "version": "hw-rev-C"
    }
  },
  "components": [
    {
      "type": "firmware",
      "name": "board-bios",
      "version": "2.17",
      "supplier": { "name": "Board supplier (as recorded on delivery note)" }
    },
    {
      "type": "operating-system",
      "name": "linux-kernel",
      "version": "6.6.58"
    }
  ]
}

4. Tie each SBOM to a configuration baseline

Tag the release in source control, record the hash of every delivered artefact, and store the SBOM with both. When a delivered system is later updated in a technology insertion or a software build, produce a new SBOM for the new baseline rather than editing the old one.

git tag -s v4.2.1 -m "Delivered baseline 4.2.1"
sha256sum dist/* > dist/SHA256SUMS

5. Map NIST SP 800-171 or Def Stan 05-138 controls to evidence

Keep a simple mapping from each requirement to the system, the control and the evidence. Configuration management, vulnerability management, access control, media protection and incident response requirements are the ones software teams own most directly.

- requirement: "NIST SP 800-171 configuration management (baseline and inventory)"
  system: build servers, delivered images
  control: SBOM generated per release; baselines tagged and hashed
  evidence: output/*.json, SHA256SUMS, git tags
- requirement: "NIST SP 800-171 risk assessment (vulnerability scanning)"
  system: source repositories, delivered image builds
  control: scan on every build; findings triaged weekly
  evidence: CI logs, triage records
- requirement: "Def Stan 05-138 automated asset inventory"
  system: engineering and build network
  control: automated discovery tool plus SBOMs for delivered software
  evidence: inventory export, SBOM archive

6. Keep watching after acceptance

Re-match each delivered baseline's SBOM against vulnerability databases on a schedule, record which findings affect which delivered systems, and agree with your customer how fixes reach the platform: next software build, next technology insertion, or an urgent change, with documented risk acceptance in between.

Where Safeguard fits, honestly

Safeguard does not build submarines, analyse hull structures, inspect firmware or generate hardware bills of materials, and it is not a tool for assessing classified systems. Its fit is narrower and real: the software that defence suppliers build and deliver. It produces SBOMs and scans dependencies for repositories, container images and SBOM files; matches components against vulnerability databases; shows which of your projects contain a given component and version; runs reachability analysis so the code paths your software actually calls rank first; evaluates policies and gates in CI; and can open fix pull requests through autonomous remediation, which ships switched off. For a supplier, that means being able to answer "which of our delivered builds contain this library version?" quickly, and to show configuration and vulnerability management evidence for NIST SP 800-171 or Def Stan 05-138.

Common mistakes

• Treating a delivered system as static after acceptance. The day a system is accepted is the day its SBOM starts to go stale. New advisories arrive for components that have not changed. Keep re-matching.
• No SBOM for commercial processors and operating systems. Teams often list their own application code and forget the commercial OS image, board support package, BIOS or BMC firmware and middleware. Those are usually the largest share of the code on the box.
• Sending controlled data over unmanaged email. Drawings, source code and test data emailed to personal or unapproved accounts sit outside the scoped boundary. Use the approved channel and keep the data inside it.
• Forgetting test, training and simulation software. Simulators, trainers, test benches and maintenance laptops run the same software as the platform and are more connected. Include them in the inventory and the SBOM archive.
• One SBOM per product instead of per baseline. A product that has shipped five baselines needs five SBOMs. Matching vulnerabilities against the latest one tells you nothing about the boats still running older builds.
• Not flowing requirements down. DFARS 7012 and Def Stan 05-138 both reach subcontractors. A sub tier supplier writing code for your module needs the same controls and should hand you an SBOM with its delivery.
• Assuming a closed network means no vulnerability management. Isolation changes how fixes are delivered, not whether they are needed. Removable media, maintenance laptops and shore test rigs all connect to it.
• Mixing up NIST SP 800-171 revisions. NIST's current revision is 3; CMMC Level 2 references revision 2.

FAQ

How long does it take to build a submarine?

Several years from first steel to delivery, plus design and long lead ordering before that. CRS reports a recent US output of about 1.1 to 1.2 Virginia class boats a year across two yards.

What steel are submarine pressure hulls made of?

Quenched and tempered high yield steels such as HY-80 and HY-100, where the number is the minimum yield strength in thousands of pounds per square inch.

Why do submarines need dry docks?

Work on the hull, propulsor, shaft seals, sea valves, sonar domes and external fittings needs the boat out of the water. Without a dock, those items are deferred, which can limit how the boat may operate and makes the next maintenance period longer.

What is the difference between a floating dock and a dry dock?

A graving dock is dug into the shore and pumped dry behind a gate. A floating dock is a pontoon that sinks to let a boat in, then rises to lift it clear.

What is Programme Euston?

It is the UK programme to provide three new floating docks for the submarine service at HM Naval Base Clyde. On 28 September 2026 the government confirmed they would be procured through a UK only competition.

What software runs on a submarine?

Sonar processing, combat management, navigation, ship control, platform management and communications software, much of it on commercial processors and operating systems in modern boats. Trainers and shore test rigs run copies of the same software.

What is ARCI?

Acoustic Rapid COTS Insertion is the US Navy approach that moved submarine sonar processing onto commercial off the shelf computers with an open architecture, refreshing hardware through periodic technology insertions and software through separate processing builds.

Do submarine suppliers need CMMC?

US defense contractors and subcontractors that handle federal contract information or CUI will see CMMC requirements in contracts as they are phased in after the DFARS rule took effect on 10 November 2025. The level depends on the information involved and is set in the solicitation.

Do defence suppliers have to provide an SBOM?

Neither DFARS 7012 nor Def Stan 05-138 is, by itself, an SBOM mandate, but individual contracts increasingly ask for one, and an SBOM per delivered baseline is the most practical evidence that you know what software you shipped.

Docks, combat systems and shore test rigs are all built from open source and commercial software that will need fixes long after delivery, and a maintenance period is when those fixes finally reach the boat. The steps below are about the open source dependencies and images suppliers build and ship; they do not reach into firmware or commercial products a supplier does not build.

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 it, run safeguard to open the interactive terminal, and ask it to fix the lodash CVE in a repository. It reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. A supplier would follow the same flow in the repository behind a display application or a test tool, then roll the fix into the next delivered build.

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

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, then scans from the terminal. It suits engineering teams that keep source and build servers inside a scoped boundary and want scanning to run on hardware they control.

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 lets you choose which tools Claude can use. Once connected, a programme engineer can ask which projects still carry an old version of a library that also ships in a delivered baseline, without exporting data by hand.

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

To try it on your own code, download Safeguard and follow the CLI documentation.

Quick check

Sources

• UK government: Healey pledges "new age of industrialisation" as Government backs British shipbuilding (28 September 2026)
• Navy Lookout: The case for AUKUS nations building floating submarine dry docks together (19 October 2026)
• UK Ministry of Defence: Defence Nuclear Enterprise 2026 Annual Update to Parliament (15 September 2026)
• Congressional Research Service: Navy Virginia-Class Submarine Program and AUKUS Submarine (Pillar 1) Project, RL32418 (updated 26 January 2026)
• Congressional Research Service: Navy Columbia (SSBN-826) Class Ballistic Missile Submarine Program, R41129 (updated 4 December 2025)
• eCFR: DFARS 252.204-7012 Safeguarding Covered Defense Information and Cyber Incident Reporting
• NIST: SP 800-171 Rev. 3, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
• Federal Register: Cybersecurity Maturity Model Certification (CMMC) Program final rule (15 October 2024)
• Federal Register: DFARS Case 2019-D041, Assessing Contractor Implementation of Cybersecurity Requirements (10 September 2025)
• UK MOD: Cyber security for defence suppliers (Def Stan 05-138, Issue 4)
• eCFR: 32 CFR 170.14, CMMC Model
• eCFR: 32 CFR 170.3, Applicability and implementation phases
• US Navy fact file: Attack Submarines (SSN), archived copy
• GAO-19-229: Navy Readiness, actions needed to address costly maintenance delays facing the attack submarine fleet (19 November 2018), archived copy
• Australian DSTO Materials Research Laboratory: Properties of HY-100 Steel for Naval Construction, MRL-R-1149 (November 1988), archived DTIC copy
• Federation of American Scientists: BQQ-10 A-RCI Acoustic Rapid COTS Insertion (1998), archived copy
• CycloneDX 1.6 JSON schema (component types)
• UK MOD: Defence Standard 05-138 Issue 4 (PDF)

Last reviewed: 25 October 2026.