docs: require air-gapped deployment and add switch hardening guidance

README.md

@@ -59,18 +59,29 @@ dvledtx reads a video source file (e.g., MP4), decodes it using FFmpeg, and tran
 
 ### Deployment Security Model
 
-dvledtx is intended for deployment on a physically secured, network-isolated media segment: the
-TX host, a dedicated L2 switch and the receivers all sit inside a locked cabinet, with all NICs
-on the TX host used for transmission onto that switch.
-
-The transport (SMPTE ST 2110-20) and its PTP timing provide no authentication, encryption or
-integrity protection — security is delegated to MTL/ST 2110 and to physical and Layer 2
-isolation. Integrators must therefore verify the deployment assumptions before relying on this
-model.
+dvledtx follows a layered security model. The application validates and bounds every input it
+owns — configuration parsing, log file destinations, decoder behaviour and resource limits — and
+is covered by static analysis, fuzzing and dependency CVE tracking in CI. Transport-level
+security is a separate layer: SMPTE ST 2110-20 and the PTP timing it depends on do not define
+authentication, encryption or integrity protection, which is a property of the standards common
+to all ST 2110 equipment. The deployment architecture supplies that layer.
+
+> **We recommend that all hosts in a dvledtx deployment are air-gapped.** The TX host, a
+> dedicated L2 switch and the receivers sit inside a locked cabinet with no network path to any
+> other network and no in-band administrative access — no SSH, no management NIC, no remote
+> console, BMC disabled — with administration by physical KVM inside the cabinet. Because
+> "isolated" and "restricted" are used loosely, note that a VLAN on a shared switch, a firewall
+> or a jump host does not meet this definition.
+
+We also recommend hardening the dedicated switch, since its configuration carries the boundary:
+disable and blackhole every unused port, enable port security (802.1X or sticky MAC) with a
+shutdown violation action, disable dynamic trunking, and enable IGMP snooping, storm control,
+BPDU guard and DHCP snooping. The full list is in the assumptions document.
 
 See **[Deployment Assumptions and Security Model](docs/assumptions.md)** for the trust boundary,
-the required deployment assumptions, the security properties the toolkit does not provide, and
-the residual risk and mitigations.
+the deployment assumptions, switch hardening recommendations, controlled ingress of
+configuration and video content, the controls the toolkit implements, the residual risk, and a
+commissioning validation checklist.
 
 ## Notices
 

Security.md

@@ -3,19 +3,26 @@ Intel is committed to rapidly addressing security vulnerabilities affecting our
 
 ## Security Model
 
-dvledtx is designed for deployment on a physically secured, network-isolated media segment. The
-transport (SMPTE ST 2110-20) and its PTP timing provide no authentication, encryption or
-integrity protection; security is delegated to MTL/ST 2110 and to the physical and Layer 2
-isolation of that segment.
+dvledtx follows a layered security model. The application validates and bounds the inputs it
+owns — configuration parsing, log file destinations, decoder behaviour and resource limits — and
+is covered by static analysis, fuzzing and dependency CVE tracking. Transport-level security is
+a separate layer: SMPTE ST 2110-20 and its PTP timing do not define authentication, encryption
+or integrity protection, which is a characteristic of the standards rather than of this
+implementation, so the deployment architecture supplies that layer.
+
+For that reason we recommend deploying on an **air-gapped** media segment: no network path to
+any other network, and no in-band administrative access to the TX host (no SSH, no management
+NIC, no remote console, BMC disabled). A VLAN on a shared switch, a firewall or a jump host does
+not meet this definition.
 
 **In scope:** the dvledtx transmitter application, its JSON configuration parsing, and its use
 of FFmpeg and the Media Transport Library.
 
 **Out of scope:** the receivers (customer-designed, typically FPGA-based, and not delivered with
 this toolkit), the LED panels, and the physical and network controls of the installation site.
 
-The trust boundary, the deployment assumptions this model depends on, and the residual risk if
-those assumptions are broken are documented in
+The trust boundary, the deployment assumptions, the switch hardening recommendations, the
+controls the toolkit implements, and the residual risk are documented in
 [Deployment Assumptions and Security Model](docs/assumptions.md).
 
 ## Reporting a Vulnerability