A patched package is the updated software artefact stored on disk or in a repository, while a patched running process is the already loaded instance in memory after the fix has been applied. The difference matters because the package can be updated without the process changing until it is restarted, reloaded, or hot-patched.
What changes between the package and the running process?
The package is the versioned artefact you store, distribute, and verify on disk or in a repository. The running process is the instance already loaded into memory, with its own runtime state, open handles, and current code image. A patch can exist in the package before the process actually picks it up, so release status and runtime exposure are not always the same thing.
Why patching the file does not always patch the live system
Updating a package usually changes what will be installed or launched next, but it does not automatically alter what is already executing. Many services, agents, and daemons keep the old code path until they restart, reload modules, or receive a hot patch. That gap is operationally important because scanners may show the artefact as fixed while the host is still executing vulnerable code.
Some environments also mix multiple copies of the same package, cached libraries, or container layers, which can make the on-disk version look current while an old process image remains active. For software delivery and supply chain review, the relevant question is not just whether the package has been updated, but whether the live workload has actually reattached to the patched code path. Public guidance on open source package integrity from OpenSSF is useful here because artefact trust and runtime exposure are related but distinct checks.
How to confirm the fix is actually running
First confirm the package version, then confirm the process image and runtime state. On a host, that may mean checking the installed package, the service binary in use, the process start time, and whether the service has been restarted since the fix. In containerised environments, verify the deployed image digest and the currently running pod or container, not just the rebuilt image in the registry. If the application supports live reload or hot patching, validate that the code path was refreshed rather than assuming it happened.
When the issue is security-relevant, corroborate with vulnerability intelligence rather than version labels alone. NIST National Vulnerability Database helps map a package or component to the relevant CVE record, while the CISA Known Exploited Vulnerabilities Catalog helps you prioritise components that are known to be actively exploited.
Risk and Threat Considerations
The main risk is false confidence: teams believe exposure is closed because the package changed, while the vulnerable process continues to run. Attackers exploit that gap by targeting long-lived services, especially where restarts are delayed, processes are pinned, or the fix requires a service bounce that operations has not yet approved.
Failure mechanism: The vulnerable code remains resident in memory until the process restarts, so the patch exists on disk but not in the execution path that matters to the attacker.
Impact: Systems can remain exploitable after “patching,” which extends the window for intrusion, persistence, and post-compromise activity even when reporting shows the software as updated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V13 — Configuration | Patching changes deployed configuration and runtime integrity. |
| Recommendation — Verify that deployed code and runtime instances match the approved patched state. | ||
| NIST SP 800-53 Rev 5 | CM-6 — Configuration Settings | Patch status must be reflected in the active system configuration, not just the stored package. |
| Recommendation — Enforce approved configuration changes and validate that running services adopt them. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The question is about closing exposure after remediation, which depends on confirming the live state. |
| Recommendation — Track remediation through to the running process, not only the package update. | ||
| NIST CSF 2.0 | PR.IP-12 — Vulnerability Management | Distinguishes remediation from verified exposure reduction in the live environment. |
| Recommendation — Confirm vulnerability remediation in the active environment before marking it complete. | ||
Practitioner Guidance
What to verify: Treat “package updated” and “process protected” as separate checks. Confirm the running instance, the service restart or reload event, and the timestamp of the live binary or module load before closing the item.
Decision rule: If the fix only exists in the package store or image registry, keep the finding open until the affected process has been restarted, reloaded, or otherwise confirmed to be executing patched code.
Practitioner takeaway: Remediation is complete only when the patched artefact has become the patched execution state; otherwise, the exposure still exists in memory.
Related resources from NHI Mgmt Group
- How should security teams respond when a Node package uses autostart persistence and process masquerading on Windows endpoints?
- What breaks when health checks only confirm that a process is running?
- What is the difference between shifting security checks left in GitHub Actions and running them later in the release process?
- What happens when a Node.js package establishes a background process that exposes command execution over HTTP?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org