What evidence actually closes a Linux POA&M item?

A Plan of Action and Milestones, or POA&M, is supposed to turn a known weakness into a tracked remediation plan. That sounds tidy until the weakness is a Linux vulnerability and the evidence is scattered across scanner output, package manager state, reboot notes, and whatever someone copied from a terminal during the maintenance window.

The uncomfortable part is usually not the plan.

It is the closeout.

Someone has to decide whether the item is actually remediated. Not “worked on.” Not “patched somewhere.” Not “the dashboard looks better.” Remediated enough that the open item can move out of the plan without making the next review harder.

For Linux vulnerabilities, the cleanest answer is host-level evidence that connects the original finding to the action taken and the state of the system after remediation.

At minimum, the evidence should answer:

What was vulnerable?
What fixed package or configuration state was required?
What is installed now?
What is running now?
Is a service restart or reboot still required?
When was this checked?
What result should the reviewer accept: fixed, still open, or needs review?

That is the evidence shape. The exact artifact can be a report, an assessor package, a control evidence record, a scanner attachment, or an internal remediation note. The important thing is that it is specific enough to stand on its own after the patch window is over.

A POA&M is not just a vulnerability list

NIST SP 800-171A describes assessment work in terms of evidence, assessment methods, assessment objects, and determinations. The assessment methods are familiar: examine, interview, and test. That matters because a POA&M closeout is not only a statement that someone intended to fix something. It needs enough evidence to support a determination that the weakness was addressed.

For NIST SP 800-171 Revision 3, requirement 03.12.02 covers plans of action and milestones. The assessment objective includes developing a POA&M to document planned remediation actions for weaknesses or deficiencies noted during security assessments and to reduce or eliminate known system vulnerabilities. It also includes updating the POA&M based on assessment, audit, review, and continuous monitoring findings.

Translated into Linux vulnerability work, the POA&M item should not remain at:

Patch affected Linux hosts.

That is a task label. It is not closeout evidence.

A better closeout record says:

CVE/advisory affected openssl-libs on host group web-rhel9.
Vendor-fixed EVR was identified for Rocky Linux 9.
Affected hosts were checked after remediation.
Fixed package is installed.
No stale vulnerable libssl mapping was detected for the exposed nginx service.
Result: remediated based on package and runtime evidence.

That is much easier to review because the reader does not have to reverse-engineer the story.

CMMC raises the stakes, but does not change the basic evidence problem

For defense contractors, CMMC adds a harder edge because POA&M use is constrained. As of September 3, 2026, Department of War (DoW) CMMC materials describe limited POA&M use, and 32 CFR § 170.21 defines POA&M requirements for Conditional CMMC Status. The rule treats Level 1 differently from Level 2 and Level 3, and it requires POA&M closeout assessment within a defined time window for conditional status.

That is the compliance context.

This article is not legal advice, CMMC consulting, or a claim that any one Linux report is enough to close a CMMC requirement. Contract language, assessment scope, system boundary, controlled unclassified information (CUI) handling, and assessor expectations all matter.

The practical point is narrower:

If a POA&M item depends on Linux vulnerability remediation,
the closeout package should show more than "package update ran."

It should show the host state that supports the remediation claim.

Start with the original weakness

The easiest evidence mistake is starting at the patch output.

Patch output is useful, but it is not the root of the item. The root is the weakness that caused the POA&M entry in the first place.

For a Linux vulnerability, capture the original condition in plain terms:

finding_id: internal scanner finding, advisory, or assessment identifier
cve_or_advisory: CVE-20XX-NNNN / RHSA / vendor advisory
system_boundary: production RHEL-family web tier
affected_host: host label or redacted host identifier
affected_package: openssl-libs
installed_evr_before: 1:3.0.7-18.el9
required_fixed_evr: 1:3.0.7-27.el9
reason_opened: installed package below vendor-fixed EVR

Do not throw away the starting point. Without it, the reviewer has to guess what the remediation was supposed to prove.

This is especially important on RHEL-family systems because upstream-looking versions can be misleading. Enterprise Linux vendors often backport security fixes into a stable package stream. A package can look old compared with upstream while still containing the vendor’s fix, or it can look “updated” while still sitting below the vendor-fixed epoch-version-release (EVR).

I wrote through that scanner/vendor mismatch in Vendor says it is fixed. Your scanner says it is vulnerable. Now what?.

Show the package-state answer

The first closeout question is usually:

Is the fixed package installed?

For RPM-based systems, the evidence should preserve the full package identity:

rpm -q --qf '%{NAME} %{EPOCH}:%{VERSION}-%{RELEASE}.%{ARCH}\n' openssl-libs

Example shape:

openssl-libs 1:3.0.7-27.el9.x86_64

By itself, that output does not prove the POA&M item can close. It proves package state. That is necessary evidence, not the whole evidence bundle.

The reviewer also needs to know what the package state means:

installed_evr: 1:3.0.7-27.el9
vendor_fixed_evr: 1:3.0.7-27.el9
package_result: fixed package installed
source: vendor security metadata / advisory data used by the organization
checked_at_utc: 2026-09-03T14:08:21Z

That last part matters. A terminal screenshot that says openssl-libs-3.0.7 leaves too much interpretation on the table.

Show the runtime-state answer

Linux remediation often fails in the gap between package state and runtime state.

A package update changes files on disk. It does not automatically restart every long-running process that loaded an old shared library before the update. A kernel update installs a kernel package, but the host does not run that kernel until it reboots into it.

So the closeout evidence should answer:

Is the fixed code actually live, or is follow-up still required?

For kernel findings, the runtime check is straightforward:

uname -r
rpm -q --last kernel-core 2>/dev/null | head -1

If the fixed kernel package is installed but uname -r still reports the older kernel, the POA&M item should not be closed as fully remediated. The better status is:

result: reboot required
reason: fixed kernel package installed, but host is still running previous kernel
next_action: reboot host and verify running kernel afterward

For shared libraries, the evidence is usually process-specific. A long-running service can keep an old object mapped after the package update:

sudo grep -H "deleted" /proc/*/maps 2>/dev/null | head

Or, when you know the service:

pidof nginx
sudo grep -H "libssl" /proc/1187/maps

Those commands are inspection aids, not universal proof. Permissions, containers, service managers, language runtimes, and dynamic loading can complicate the picture. Still, the closeout record should make the runtime conclusion explicit:

runtime_result: no stale libssl mapping detected for nginx after restart

or:

runtime_result: nginx still maps deleted libssl object
next_action: restart nginx and recheck

That is the part many evidence bundles miss.

Show exposure when it changes priority

Not every package finding carries the same operational urgency.

If the affected package is tied to a service listening on the network, that should be visible in the evidence:

sudo ss -ltnup

Example shape:

tcp LISTEN 0 4096 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=1187,fd=6))

That does not prove internet reachability by itself. A host-local socket can still be blocked by host firewall rules, security groups, Kubernetes NetworkPolicies, network ACLs, load balancers, or upstream controls.

But it does tell the reviewer something important:

The vulnerable component was associated with a live service path.

If exposure is unknown, say unknown. If it is internally reachable only, say that. If it is internet-facing based on separate network-path evidence, include that evidence.

This is where POA&M closeout evidence gets more useful than a raw scanner export. It helps separate:

package fixed, no live service context found

from:

package fixed, exposed service restarted, stale runtime mapping cleared

Those are different levels of confidence.

Use action labels a reviewer can follow

The evidence should not make the reviewer infer the final status from a pile of facts.

Use explicit outcome labels:

Evidence state	POA&M-friendly status
Package remains below vendor-fixed EVR	Still open: package update required
Fixed package installed, but old library still mapped	Still open: service restart required
Fixed kernel installed, but old kernel running	Still open: reboot required
Fixed package installed, no stale runtime evidence detected	Candidate for closure
Scanner still flags, but vendor-fixed EVR is installed	Needs review: reconcile scanner logic
Exposure or runtime evidence missing	Needs review: evidence incomplete

“Candidate for closure” is intentionally careful language. A host-level report can support closure, but the organization still has to decide whether the evidence is sufficient for the POA&M item, system boundary, assessment scope, and internal process.

That distinction keeps the artifact useful without overclaiming.

A closeout evidence shape

A practical Linux vulnerability closeout record might look like this:

POA&M item:
  weakness: Linux vulnerability finding for CVE-20XX-NNNN
  system boundary: RHEL-family production web tier
  affected host: host_0381853b728c

Package evidence:
  distro: Rocky Linux 9
  package: openssl-libs
  installed EVR: 1:3.0.7-27.el9
  vendor-fixed EVR: 1:3.0.7-27.el9
  result: fixed package installed

Runtime evidence:
  service: nginx
  process: nginx pid 1187
  library check: no stale vulnerable libssl mapping detected after restart
  kernel: running kernel matches expected fixed kernel state

Exposure evidence:
  service: 443/tcp listening on host
  reachability: externally reachable based on approved exposure source

Closeout result:
  status: candidate for closure
  checked_at_utc: 2026-09-03T14:08:21Z
  evidence_collector: named tool, script, or process
  reviewer_note: package and runtime evidence support remediation for this host

For an item that is not ready, the record should be just as clear:

Closeout result:
  status: still open
  reason: fixed package installed, but nginx still maps old deleted libssl object
  required_action: restart nginx and recheck runtime mappings

That second version is not a failure. It is useful evidence. It stops the organization from closing the item too early and tells the operations team exactly what remains.

What not to rely on by itself

I would be careful with any closeout package that depends only on one of these:

• a package update transcript
• a screenshot showing the scanner is green
• a statement that “the server was patched”
• a reboot note with no running-kernel verification
• a package version without distro/vendor-fixed EVR context
• a list of CVEs with no affected package or host state
• a compliance score with no rule-level or host-level evidence

None of those artifacts are useless. They are just incomplete by themselves.

A package transcript shows that work happened. A scanner screenshot shows scanner state. A reboot note shows an operational event. A compliance score shows a rollup. The POA&M closeout question is sharper:

Does the evidence show the weakness was corrected or reduced enough to close this item?

For Linux vulnerabilities, that usually means connecting package evidence, runtime evidence, and the remaining action.

The practical end state

The best POA&M evidence is not the biggest attachment.

It is the clearest one.

For each Linux vulnerability item, the reviewer should be able to read the artifact and understand:

This was the vulnerable condition.
This was the required fixed state.
This is the host state after remediation.
This is whether old code is still running.
This is whether restart or reboot work remains.
This is why the item can close, stay open, or move to review.

That level of clarity helps the Linux team too. It reduces back-and-forth, avoids repeat patching when the real action is a restart, and gives compliance or security reviewers something more durable than a screenshot.

If you want to see the artifact shape, the sample Patch Truth report shows how oxharden presents package state, runtime state, and next action for a Linux host. For the broader defense-contractor context, the CMMC and defense contractors page explains how host evidence fits into audit prep without pretending one report replaces the assessment.

References

• NIST SP 800-171 Revision 3
• NIST SP 800-171A Revision 3
• Department of War CMMC overview
• 32 CFR § 170.21, Plan of Action and Milestones requirements