Defer the scanner findings Lockdown already stops

Overview: Under Lockdown, some critical scanner findings can wait for your standard change window. Those are the findings where exploiting the bug only gets an attacker as far as a step Root Lock refuses: running a dropped binary, opening a file the vulnerable program was never granted, or connecting to a destination outside its network allowlist. A finding the attacker can complete inside the program’s existing grants — reading files it already reads, sending to a destination it already reaches — stays this week’s work. You record the deferral as one exception rule in the scanner you already run. That rule changes the scanner’s score, report, and remediation queue until it expires. It does not change the patch date in your policy or contract.

Which findings can wait

A finding can leave the active queue when the attacker’s next step after the exploit is something Lockdown already stops:

• The next step is a program with no allowlist entry. The kernel matches the path, so a copy of an allowed binary at a new path is a new program with no entry.
• The next step is a file the program was not granted.
• The next step is a destination the program was not granted.

The vulnerable code is still on the host, so file these with a compensating-control or accepted-risk reason — the reason column in Record the reason in that scanner — and an expiry. A false-positive reason records that the vulnerability is absent, which is not true here, and the expiry is what brings the finding back for the patch.

In the comment, name the step Lockdown stops: a program with no allowlist entry, a file that program was not granted, or a destination it was not granted. A privilege-escalation finding whose root process already has an allowlist entry is not, by itself, a reason the patch can wait. Where your policy sets the standard change window at 60 or 90 days for work it does not rank critical, set the expiry to that window.

The deferral holds only while the host is in Lockdown. In Setup Mode the kernel logs but stops blocking until you return to Lockdown, so plan maintenance windows on these hosts with the open findings in mind. See Protecting During Maintenance.

Which findings stay on the patch date

Two kinds of finding keep the patch date whatever the exploit’s next step: a known-exploited finding on the CISA Known Exploited Vulnerabilities list, and anything your policy ranks critical.

The rest stay because the attack completes inside what the program is already allowed to do, so there is no refused step for Lockdown to stop:

• In-process bugs, on data the program already reads
• Kernel CVEs whose code is in the kernel you boot
• Injection inside an allowlisted process
• Denial of service
• An already-permitted destination
• The vulnerable app’s own files

An exception for one of these is a rule you file on your own policy’s terms, not on Lockdown’s. Lockdown still refuses the attacker’s next unapproved program, file, or destination on those hosts, so the patch closes the bug and the allowlist bounds what the bug can reach before it lands.

Kernel CVEs for code that is not in the kernel

The false-positive or not-affected reason is for one case: a kernel CVE whose code is absent from the kernel you boot. Record the config gate that leaves it out on the rule. The catalog of gates and the CVEs each one covers is Kernel Security Transparency.

On the 6.18 kernel, the BPF syscall is off, so there is no eBPF program to load. apt and dnf update the OS packages and leave the Root Lock kernel as shipped, so a package update does not change which kernel code is present.

A scanner that flags a kernel CVE from the version string alone follows CVE Hygiene for Scanners.

File the exception

File the rule on the asset group, tag, or range those hosts already belong to, and put the reason, the comment, and the expiry on that rule. If the scanner asks for an approver or a review date, record those on the same rule.

The exception expiry and the remediation SLA are two different dates. The expiry is how long the scanner treats the finding as handled. The SLA is the patch date in your policy or contract, and the exception does not move it. A policy that requires installs within seven days still requires them within seven days — the exception rule is what records that this finding is allowed to wait longer.

Keep evidence for the exception window

Keep a record with the rule that shows Lockdown held for the exception’s dates:

• If those hosts already ship syslog, save a search on identifier heartsuite for those dates. It returns the denials and alerts.
• If a monitor already polls status.json, its history for lockdown and daemon_ok covers the same dates.
• On one host, when the shipper is down, journalctl -t heartsuite --since and --until cover those dates.

See SIEM Integration.

Record the reason in that scanner

Each link goes to the vendor’s own article. Menu labels come from that article and can change between releases. Where an article names a 30-day or 90-day field, that field is the exception expiry, not your remediation SLA.

Wiz and Orca, which How Root Lock Compares names alongside these scanners, publish no public exception article, so they are not in the table.

Image and dependency scanners

An ignore in these tools changes that tool’s report, the same way an exception does in a host scanner.

Backports, tailoring, and intrusion prevention

These cover a backported fix, OpenSCAP tailoring, or intrusion prevention alongside the scanner rule.