Known vulnerabilities, left unpatched.
NIS 2's Art. 21(2)(g) lists basic cyber-hygiene practices among the required measures, and one of the most basic is keeping software up to date against known vulnerabilities. When a fix exists for a published advisory and you do not take it, you are running a known hole on purpose. That decision is usually made in a manifest or a base image, in code.
The shapes the same control failure takes.
Cyber hygiene erodes when a change leaves a known, fixable vulnerability in place. The recurring shapes:
A dependency is held back from its fix
A library with a published advisory is pinned to the affected version rather than updated to the patched one, to avoid retesting.
A base image is frozen and unmaintained
A base image is pinned to an old tag that no longer receives security updates, so its known vulnerabilities accumulate.
An automated update mechanism is disabled
Dependency or image update automation is turned off or its pull requests routinely closed, so fixes stop landing.
A security patch is reverted
An update that closed a vulnerability is rolled back because it caused friction, reopening the hole.
End-of-life software is kept in place
A runtime or library past end of life, which no longer gets fixes at all, is retained instead of migrated.
A dependency pinned back to a version with a known advisory.
A library has a published security advisory with a fixed version available. Taking the fix would mean retesting an integration, so a change pins it back to the affected version. The app keeps working, on a version with a known, unpatched vulnerability.
"dependencies": {- "image-parser": "1.4.2"+ "image-parser": "1.3.0" }Pinning image-parser back to 1.3.0 keeps a version with a known, published advisory when a fixed release (1.4.2) is available. Art. 21(2)(g) (basic cyber-hygiene practices) includes keeping software patched against known vulnerabilities. Take the patched version and retest, rather than holding the affected one.
Cyber hygiene is checked against what you are still running.
An inspection under NIS 2 looks for evidence of basic hygiene: that known vulnerabilities are tracked and patched in a reasonable time, and that software is kept supported. A change that pinned a dependency back to a vulnerable version, froze an unmaintained base image, or disabled update automation is the concrete lapse behind that, and it is visible in the diff to the manifest, lockfile, or image.
A review, not a vulnerability scanner.
heygrc flags changes that touch a NIS 2 hygiene measure and cites the point so the fix happens in the pull request. It does not run your vulnerability scanning or your patch pipeline. It catches the moment a change leaves a known, fixable vulnerability in place, at the diff. heygrc is in early access.