DoD Cannot Patch Its Own Systems Fast Enough Because of Certification Requirements

When a critical vulnerability is discovered in software used by the Department of Defense, the patch cannot simply be applied. Every software change to a DoD system must go through the Security Technical Implementation Guide (STIG) process, which requires testing the patch against the system's security baseline, verifying it does not break functionality, and obtaining authorization from the system's Authorizing Official. For weapons systems, this includes additional operational testing. The result is that patches that take commercial organizations days to deploy take DoD weeks or months. This matters because adversaries are weaponizing vulnerabilities within hours of public disclosure. The Cybersecurity and Infrastructure Security Agency (CISA) tracks Known Exploited Vulnerabilities (KEV) and issues binding operational directives requiring federal agencies to patch within specific timeframes -- typically 14 days for critical vulnerabilities. DoD systems routinely miss these deadlines. When a Chinese or Russian hacking group begins exploiting a vulnerability on Day 1, and DoD cannot patch until Day 45, there is a 44-day window during which military systems are knowingly vulnerable. The downstream effect is that DoD network defenders must resort to compensating controls -- firewall rules, network segmentation, monitoring -- to protect unpatched systems. These workarounds consume defensive resources, add complexity that creates its own vulnerabilities, and degrade system performance. Operators on the ground experience this as systems that are slow, unreliable, and locked down to the point of being difficult to use for their intended purpose. The problem is especially acute for weapons systems with embedded software. Patching the fire control computer on an F-35 requires regression testing the entire weapons system to ensure the patch does not affect targeting, navigation, or flight safety. This testing can take months and costs millions of dollars, creating a perverse incentive to defer patches indefinitely. The structural cause is that the DoD's Risk Management Framework (RMF) treats every software change as a potential security event requiring re-evaluation. This made sense when software updates were infrequent and manual, but it is incompatible with the modern reality of continuous vulnerability disclosure and rapid adversary exploitation. The process conflates change management (ensuring patches don't break things) with security authorization (ensuring the system meets security requirements), making both slower.