HomeSecurity & Governance › Vulnerability & patch governance

Vulnerability & patch governance

Purpose: A defensible process from "CVE published" to "fixed in prod", covering AEM, dependencies and the stack beneath.

Who this page is for

AudienceWhy it matters to you
Tech leads / platform engineersProcess owners
All engineersDependency hygiene

The surfaces you are patching

SurfaceIntakeFix path
AEM productAdobe security bulletins (subscribe, don't discover via news)SP/hotfix via patching process
Java dependencies (yours)SCA scanning in CI (OWASP dependency-check or equivalent)Version bump PRs, prioritised by exploitability in YOUR usage
Frontend dependenciesnpm audit / SCA on ui.frontendSame
JVM / OS / web server / CDN configPlatform vulnerability managementPlatform patch cadence
Your own codeSecurity checklist per PR + periodic pentestNormal or hotfix path

Triage that scales

Severity score is the start, not the answer. Triage each finding against reality: Is the vulnerable path reachable in our deployment? (dispatcher-blocked console CVE ≠ internet-reachable RCE) — which is one more reason the dispatcher probe suite stays green.

ClassClock
Critical + reachable + exploited-in-wildEmergency: hours–days (compressed path)
Critical/high, not directly reachableNext patch window, mitigations meanwhile (WAF rule, filter)
Medium/lowScheduled with releases; batch dependency bumps monthly

Record the triage decision (even "accepted risk, because…") — undocumented risk acceptance is just risk.

Keeping the backlog honest

Quick navigation