Your application can be secure on Monday and require a security update on Tuesday without a single line of your own code changing.
A vulnerability may be disclosed in a framework, runtime, operating-system component or third-party library already running in production. The application may continue behaving normally, customers may notice nothing, and every availability dashboard may remain green.
Its security condition has nevertheless changed.
That is why security patching cannot be treated as occasional emergency work outside normal application maintenance. Software continues accumulating new security information after launch, and teams need a repeatable way to identify relevant patches, prioritize them, test them and move them safely into production.
NIST makes this connection explicit in its Guide to Enterprise Patch Management Planning, describing patching as a form of preventive maintenance and defining the process as identifying, prioritizing, acquiring, installing and verifying patches, updates and upgrades.
For Levelworks, that makes patching an important connection between two App Health Aspects: Secure and Current & Updated.
A successful security review tells you something about the application at the time it was assessed.
It cannot guarantee that every component will remain safe indefinitely.
Modern applications depend on large software stacks: frameworks, libraries, runtimes, database engines, container images and operating-system packages. Vulnerabilities continue to be discovered in those components after applications have already adopted them.
The OWASP Top 10:2025 identifies software supply-chain failures as a major application-security risk and specifically calls out vulnerable, unsupported and outdated components. OWASP recommends tracking component versions and monitoring for vulnerabilities affecting both direct and transitive dependencies.
This means security patching is not evidence that development originally failed.
It is a normal consequence of operating software over time.
[Internal Link: “Application Security Maintenance: What Needs to Happen After Launch?”]
Before a vulnerability is publicly known, an organisation may reasonably have no way to patch it.
After the vulnerability and a correction are available, the situation changes.
The team now has a known condition to evaluate.
That does not mean every patch deserves an emergency deployment. Severity scores need context: Is the affected component deployed? Is the vulnerable functionality reachable? Does the application expose it publicly? Are compensating controls present?
Evidence of exploitation matters too.
CISA maintains its Known Exploited Vulnerabilities Catalog as an authoritative list of vulnerabilities known to have been exploited in the wild and recommends using it as an input when prioritizing vulnerability remediation.
The important maintenance principle is therefore not “install every patch immediately.”
It is:
Every relevant security patch needs an explicit decision.
Leaving a vulnerability unresolved because engineering consciously evaluated the exposure and scheduled remediation is different from leaving it unresolved because nobody noticed the update existed.
Teams sometimes postpone security updates because patches themselves can create risk.
That concern is legitimate.
A framework update can affect application behaviour. A library patch may interact with other dependencies, while an operating-system update can expose compatibility assumptions that were previously invisible.
But avoiding routine patching does not remove this risk.
It often concentrates it.
GitHub's Dependabot documentation notes that dependency updates can become difficult when a vulnerable package cannot be upgraded without also changing other packages in the dependency graph. GitHub specifically recommends staying reasonably current because doing so makes it more likely that a future vulnerability can be resolved through a smaller upgrade rather than a much larger dependency change. GitHub: Dependabot Update Errors
This is one reason patches belong inside maintenance planning.
A team that regularly reviews and updates its software can usually deal with smaller changes under controlled conditions.
A team that postpones updates for several years may eventually face a critical vulnerability that requires a framework migration, runtime upgrade and dependency changes at exactly the moment it has the least time to test them.
[Internal Link: “How Outdated Dependencies Create Security Risks in Your App”]
Automated tools are excellent at finding vulnerable dependencies and, in some cases, proposing corrected versions.
GitHub's Dependabot, for example, can generate alerts when vulnerable dependencies are identified and can create pull requests that move affected packages to secure versions.
Automation shortens the path from vulnerability disclosure to engineering awareness.
It should not eliminate validation.
A patching workflow should answer:
The NIST patch-management process explicitly includes verification, which matters because successful installation is not the same as successful remediation.
At Levelworks, this is where Secure depends on Tested and Seamlessly Updatable. If an application cannot accept patches safely, keeping it secure becomes progressively harder.
A useful maintenance plan avoids two extremes.
The first is postponing every update until something forces action.
The second is pushing every security update directly into production without understanding the consequences.
A simple prioritization model can consider:
Factor
Question
Exploit activity
Is there evidence that attackers are actively exploiting it?
Exposure
Can an attacker reach the affected functionality?
Impact
What could successful exploitation allow?
Application criticality
How important is the affected system?
Available mitigation
Can risk be reduced safely before patching?
Patch complexity
How much regression risk does the update introduce?
A remotely exploitable vulnerability affecting an internet-facing authentication component deserves a different response from a vulnerability in an unused library function available only on an isolated internal system.
This is why vulnerability counts alone are weak maintenance metrics.
Ten low-exposure findings may be less urgent than one actively exploited vulnerability affecting a critical production path.
A maintenance plan should make clear who is responsible for moving a security finding from discovery to closure.
A basic workflow might be:
Detect → assess exposure → prioritize → prepare update → test → deploy → verify → document exception if unresolved
The exact people involved will vary, but ownership should not disappear between security and engineering.
If security identifies the problem but nobody owns the application change, the vulnerability remains open.
If engineering applies the update but nobody verifies production, the organisation cannot be certain the exposure has actually been removed.
NIST's Secure Software Development Framework similarly treats responding to vulnerabilities in released software as part of the software lifecycle, including analysing root causes so weaknesses are less likely to recur.
That lifecycle perspective is exactly why patching belongs in maintenance rather than being treated as an exceptional security project.
Sometimes an application cannot be patched immediately.
Perhaps the vendor has not yet released a correction, the patch introduces an unacceptable regression or applying it requires a larger technology upgrade.
That does not make the maintenance process unsuccessful.
Silently forgetting the vulnerability does.
Record:
Otherwise, temporary exceptions have a tendency to become permanent architecture.
Over time, enough deferred updates can leave an application in a state where future security work becomes increasingly difficult.
[Internal Link: “Why Dependency Updates Are Essential to App Maintenance”]
Security patching is easy to treat as reactive work because a vulnerability often triggers it.
The underlying capability is preventive.
A good maintenance plan ensures the organisation knows what software it runs, learns when relevant vulnerabilities appear, distinguishes urgent risk from routine updates and has a tested route for getting necessary corrections safely into production.
That keeps Secure and Current & Updated working together rather than allowing one to deteriorate because the other has been neglected.
The reason security patching belongs in every app maintenance plan is therefore simple:
A released application does not remain secure just because nobody changes it.
The software around it continues changing anyway. Vulnerabilities are discovered, support windows close and attackers gain new information.
Maintenance is how the application keeps up.
