A stopgap with an expiry date, not a second hardening tool
The vulnerability is known, the patch cannot be installed: the vendor has not delivered yet, the system is a plant controller without a maintenance contract, the maintenance window is six weeks away. Instead of waiting, exploitability is removed. The module keeps a recipe catalogue for that, where every recipe consists of steps, a mapping to CVE, KB, package or product, a mandatory side-effect statement and a reference to the vendor. A compensating measure is time-limited, for one system and against one vulnerability, and it disappears again. Mixing that with permanent hardening leaves a fleet of disabled services after two years that nobody remembers.
If there were a mechanism "run this command", a single database row could execute code as SYSTEM across the whole fleet. So there is no script and no free-text field that reaches the device. What the agent does not know, it does not execute, even when signed.
The cockpit compares open vulnerabilities with the catalogue by CVE identifier, KB number and package identifier. Only the product name is a text search, and a hit on it therefore carries the confidence "assumption".
Before a host firewall rule the agent resolves the path to the platform, proxy, name resolution and DHCP and refuses any rule that would hit them. After setting it, it checks whether the platform still answers and withdraws the rule immediately if not. The mechanism is built and stays locked until design review and pentest.
The gap is closed before the patch arrives, and the measure disappears again once it does: traceable, time-limited, with no script on the device.
Schedule a no-obligation demo – we will show you the module with your own use cases.
