A security review completed the day before launch can tell you something useful: under the conditions tested, on that version of the application, the team found a certain set of weaknesses and verified a certain set of controls.
It cannot tell you that the application will still be secure six months later.
By then, dependencies may have new vulnerabilities. An API integration may have changed, employees may have accumulated privileges they no longer need, certificates may be approaching expiry, new features may have altered authorization paths, and a configuration change made directly in production may have weakened a control that passed testing at launch.
Nothing about that requires the original security review to have been poor.
Production simply keeps moving.
Application security maintenance is the ongoing work required to keep security controls effective after launch as the application, its dependencies, its users and the threat environment change.
That makes security maintenance different from a one-time penetration test or pre-launch checklist. Those activities can provide important evidence at a moment in time. Security maintenance is what happens between those moments.
For Levelworks, this is primarily part of the Secure dimension of App Health, but keeping an application secure also depends heavily on whether it remains Current & Updated, Observable, Tested and Seamlessly Updatable.
Launch changes the security problem.
Before production, the team controls most of the environment. After launch, real users, real data, real integrations and real operational processes begin interacting with the software.
At the same time, external conditions continue evolving.
New vulnerabilities are disclosed in libraries the application already uses. Attack techniques change. Cloud services and APIs introduce new capabilities or retire old ones. Engineers modify infrastructure, add integrations and release product features that did not exist during the original assessment.
NIST's Secure Software Development Framework treats security as something that must continue across the software lifecycle, including responding to vulnerabilities discovered after release and addressing root causes so similar weaknesses are less likely to recur.
That is the mindset required after launch.
Security is no longer a gate the application passed.
It becomes an operating condition that has to be maintained.
Security maintenance becomes much harder when nobody has an accurate view of the software running in production.
A production application may depend on:
Those components continue changing even if your own application code does not.
OWASP's Top 10:2025 category on Software Supply Chain Failures identifies unsupported, outdated and vulnerable components as important risk conditions. OWASP recommends continuously tracking component versions, including transitive dependencies, and monitoring relevant vulnerability sources rather than relying on occasional manual reviews.
The maintenance requirement is therefore straightforward: know what you run, which versions are deployed and whether those versions remain supported.
That does not mean upgrading every dependency the moment a new release appears. It means being able to answer quickly when a security advisory arrives:
Do we use the affected component?
Which production systems use it?
Which version are we running?
Is the vulnerable functionality exposed?
If answering those questions takes several days of repository archaeology, vulnerability response is already slower than it needs to be.
[Internal Link: “How Outdated Dependencies Create Security Risks in Your App”]
New vulnerability information arrives continuously.
Your application may not change at all while its known security exposure changes overnight because a vulnerability is disclosed in software it already uses.
Security maintenance therefore needs an intake process for new vulnerability information.
That can include:
The difficult part is not finding vulnerabilities.
It is deciding what deserves attention first.
A critical severity score should not be interpreted without context. Ask whether the vulnerable component is actually deployed, whether the affected feature is enabled, whether an attacker can reach it and whether exploitation is already occurring in the wild.
CISA maintains its Known Exploited Vulnerabilities Catalog specifically as an input to vulnerability prioritization. The catalog contains vulnerabilities for which there is evidence of active exploitation, and CISA recommends that organisations use it to help prioritize remediation.
That provides a useful principle for security maintenance:
Prioritize actual exposure and credible threat, not vulnerability volume alone.
A team that closes hundreds of low-risk findings while leaving one internet-facing, actively exploited vulnerability unresolved does not have an effective maintenance process.
Once a relevant vulnerability is identified, the application needs a reliable route from finding to remediation.
NIST's Guide to Enterprise Patch Management Planning explicitly describes patch management as preventive maintenance and defines it as identifying, prioritizing, acquiring, installing and verifying patches, updates and upgrades.
The verification step matters.
A security patch should not be considered complete merely because somebody clicked “update.”
Teams need confidence that:
This is where security maintenance intersects with Tested and Seamlessly Updatable App Health.
If routine security updates regularly require risky emergency releases, the problem is larger than patch management. The application's ability to remain secure is being limited by its ability to change safely.
[Internal Link: “Why Security Patching Should Be Part of Every App Maintenance Plan”]
Authorization rarely remains static after launch.
Employees join, move teams and leave. Customers create new administrators. Service accounts accumulate permissions, while temporary production access granted during an incident may remain longer than intended.
The application's access model can therefore drift even when authentication itself continues working perfectly.
Security maintenance should periodically review:
Also review access whenever organisational or architectural changes create a reason to do so.
For example, introducing a new administration function may require more than checking whether login works. The team should verify who can access the function, what actions they can perform and whether those permissions remain appropriately separated.
OWASP's current Application Security Verification Standard provides a structured basis for verifying technical application-security controls across areas including authentication, session management and access control. The standard is useful precisely because security verification needs to consider specific controls rather than treating “authentication works” as sufficient evidence that access is secure.
Not every production security weakness comes from source code.
Security can change because:
OWASP's 2025 Top 10 places Security Misconfiguration among its major web-application risk categories, alongside supply-chain, access-control and authentication failures.
Configuration therefore belongs inside application security maintenance.
Where practical, important configuration should be managed through controlled, reviewable processes rather than undocumented manual changes. Security-sensitive changes should be traceable, and secrets should have appropriate ownership, storage and rotation practices.
For Levelworks, this is one place where Secure and Version Controlled App Health reinforce each other. Security becomes easier to maintain when production state can be understood and changes have a clear history.
An application can have strong preventive controls and still need to detect when those controls are being tested or bypassed.
Relevant events may include:
The exact events depend on the application and its risk profile.
OWASP's Logging Cheat Sheet recommends application-level logging for security events because application logs often contain information that infrastructure logs cannot provide. It also stresses that logged events need to be available for monitoring, alerting and incident investigation.
Logging is not enough by itself.
If meaningful security events are recorded but nobody reviews them and no serious condition generates an alert, detection remains weak.
The maintenance task is therefore to ensure that security telemetry still reflects the application's current architecture and that the people responsible for responding can actually see significant events.
This is where Secure depends on Observable.
More security logging is not automatically safer.
Logs may accidentally contain:
OWASP recommends excluding, masking, sanitizing, hashing or encrypting sensitive information where appropriate and protecting collected logs against unauthorized access, modification and deletion.
Security maintenance should therefore review both sides of logging:
Are we recording enough information to investigate security events?
and
Are we recording anything that should not be there?
Both can change as the application evolves.
A new feature may introduce sensitive fields into a request that an existing debug logger records automatically, for example. Nothing about the logging configuration changed, yet the security implications did.
Periodic security reviews are useful, but a fixed calendar should not be the only trigger.
Certain changes should prompt security reassessment because they materially change the application's attack surface.
Examples include:
The important question is:
What security assumptions changed because of this release?
If an application begins accepting uploaded files, the answer is not simply “run the same security scan we ran last quarter.” The feature introduces different input handling, storage and access-control concerns.
OWASP ASVS is useful here because its requirements can provide a structured basis for verifying relevant technical controls when the application's security profile changes.
A deeper examination of security-audit frequency belongs elsewhere in the series.
[Internal Link: “How Often Should You Perform an Application Security Audit?”]
One of the most sustainable ways to maintain security is to move repeatable checks into the application's normal delivery process.
Depending on the application, that could include:
Automation cannot replace expert security testing.
It does prevent teams from having to rediscover obvious weaknesses manually after every release.
NIST's SSDF recommends integrating secure practices into the existing software-development lifecycle rather than running security as a separate activity at the edge of development. It also emphasizes identifying and addressing vulnerabilities in released software and preventing recurrence where possible.
That distinction matters.
A one-off security test can find a vulnerability.
Security maintenance should also ask:
Can we create a control or regression test that makes this particular weakness harder to reintroduce?
That is how a finding becomes an improvement to the application's ongoing condition.
No realistic security-maintenance program can guarantee that every attack will be prevented.
Teams also need to preserve the ability to investigate and contain security incidents.
That means knowing:
This information should not exist only in one engineer's memory.
Security incidents often create time pressure, and an undocumented response process wastes that time.
The ability to release safely matters here too. Discovering a vulnerability is of limited value if the application cannot accept a security fix without days of uncertainty and manual preparation.
Security maintenance therefore depends on operational readiness as much as security tooling.
Some security controls fail loudly.
Others simply become less effective over time.
Examples include:
These are maintenance problems because the original control may have been correct.
The problem is that nobody verified it remained correct.
A useful security-maintenance practice is therefore to review evidence of operation, not merely evidence that a control was once designed.
If backups are part of the security and recovery model, can they still be restored?
If privileged access is restricted, who currently has it?
If an alert should detect suspicious authentication behaviour, when was its notification path last tested?
Controls need to survive contact with time.
Not every security-maintenance activity should happen at the same frequency.
A practical model looks more like this:
Security maintenance activity
Typical trigger
Vulnerability and dependency monitoring
Continuous or automated
Critical vulnerability triage
As advisories arrive
Security patching
Risk-based, according to exposure and urgency
Security-event monitoring
Continuous
Access and privileged-account review
Regularly and after personnel/role changes
Secret/certificate review
According to lifecycle and before expiry
Security regression checks
Every relevant release
Broader security verification
Periodically and after significant architectural/product changes
Incident-response readiness review
Periodically and after incidents
Compliance-control review
When requirements, data use or relevant systems change
The exact schedule depends on application criticality, exposure and regulatory obligations.
The more important principle is that security maintenance needs both recurring work and event-driven work.
A quarterly calendar should never become an excuse to ignore a critical vulnerability discovered the week after the last review.
Useful warning signs include:
Individually, some of these may be manageable.
Together, they indicate that security is being treated as a series of isolated projects rather than as an operating responsibility.
Application security maintenance is not about performing the same security test over and over.
It is about keeping the security posture aligned with a moving system.
The application changes. Dependencies change. People and permissions change. Vulnerabilities become known. Integrations evolve, configurations drift and controls that once worked can quietly stop providing the protection you expect.
Maintaining security therefore means continuously knowing what you run, paying attention to new vulnerability information, prioritizing genuine exposure, applying and verifying necessary changes, reviewing access, protecting configuration and secrets, monitoring meaningful security events and reassessing controls when the application itself changes.
For Levelworks, that is what a healthy Secure application looks like after launch.
Not software that passed security testing once.
Software whose security can continue to be understood, updated and verified as the product evolves
