Security posture is a patch path

October is Cybersecurity Awareness Month. The lesson I keep coming back to in regulated systems: you don't have a security posture, you have a patch path.

A CVE lands in a dependency you ship. The real question isn't how severe it is. It's how much of the system you have to re-verify to fix it.

That answer is set by architecture, long before the CVE exists.

• Software item boundaries set your revalidation scope. A library behind a clean interface in one item keeps the change impact in that item. Thread it through a shared core and one patch becomes full regression plus a DHF update.
• The SBOM is impact analysis input, not paperwork. Mapped to software items, it tells you where a component lives and what it touches. FDA requires one in premarket submissions for cyber devices (section 524B).
• The update path is a safety-relevant software item. Signed artifacts, verified on the device, with rollback and defined behavior during the update. If the mechanism can interrupt therapy or brick the unit, it needs its own risk analysis.
• Version skew is a design problem. Patch a cloud service and the fleet runs N and N-1 for weeks. Versioned contracts and tolerant consumers, or you trade one hazard for another.
• Security controls are risk controls. Segmentation, edge token validation and least privilege, traced into the risk management file with verification evidence, not just present in code.
• The pipeline is the evidence. If CI produces verification records and traceability on every change, a patch is routine work. If evidence is assembled by hand, it's a project.

One distinction I hold firmly: security risk and safety risk are separate analyses. Attacker intent can't be given a probability the way a component failure can, so the design assumes breach and bounds what a breach can reach.

The test: if a critical vulnerability is disclosed tomorrow, can you ship a verified fix in days, with the evidence, without touching unrelated items?

If not, that's the design backlog.