Picture the investigation beginning on a Monday morning.
A customer reports activity they do not recognise. Security checks the account and discovers that somebody accessed information through an old administrative function. The application itself was not defeated by a previously unknown attack. Instead, the investigation uncovers a chain of much less dramatic problems.
A security update for one component had been postponed because the release carried regression risk. An old support account still had privileges it no longer needed. A configuration exception introduced months earlier had never been removed, while the logs recorded suspicious access but no alert brought it to anyone's attention.
Individually, each issue had seemed manageable enough to leave for later.
Together, they gave an attacker a path to data.
That is an important way to think about the relationship between application maintenance and data breaches. Maintenance cannot guarantee that a breach will never occur, nor can routine upkeep replace secure architecture or specialist security work. What it can do is continually remove weaknesses that would otherwise accumulate in a live application.
The relevance is becoming harder to dismiss. Verizon's 2026 Data Breach Investigations Report, based on more than 22,000 confirmed breaches, says vulnerability exploitation has become the leading breach vector and again emphasizes fundamentals such as asset visibility, disciplined patch management and practiced response. Verizon: 2026 Data Breach Investigations Report
For Levelworks, this is why Secure App Health cannot be separated from ongoing maintenance. Applications change after launch, but so do vulnerabilities, permissions, dependencies, configurations and attack techniques. Preventing breaches requires keeping those moving parts under control.
When people imagine a data breach, they often picture a highly sophisticated attacker discovering a previously unknown flaw.
That happens, but many security failures involve conditions defenders could already identify: vulnerable software, excessive privileges, weak configuration, compromised credentials or insufficient monitoring.
The OWASP Top 10:2025 illustrates how ordinary these categories are. Its current list includes Broken Access Control, Security Misconfiguration, Software Supply Chain Failures, Authentication Failures and Security Logging & Alerting Failures among the most important web application risks.
Notice what many of those problems have in common.
They can become worse after launch.
An account gains privileges. A dependency falls out of support. A deployment changes configuration. A new endpoint bypasses an old authorization assumption. A useful security alert stops reaching the right team.
Application maintenance is the process that keeps revisiting those conditions rather than assuming that security remains fixed because the original release passed testing.
Patching is one of the most obvious ways maintenance contributes to breach prevention, but the security value is sometimes misunderstood.
The purpose is not simply to keep version numbers current.
A security patch removes or mitigates a weakness that has become known. Once the vulnerability is publicly documented, continuing to operate the affected version can leave a route available to attackers who now have considerably more information about the weakness.
CISA's Known Exploited Vulnerabilities Catalog exists specifically to help organisations prioritise vulnerabilities for which exploitation has already been observed in the wild. CISA recommends using this evidence as an input to vulnerability-management decisions rather than treating every vulnerability as equally urgent.
Good maintenance therefore creates a repeatable path:
Find the relevant vulnerability → establish whether the application is exposed → prioritise the risk → apply the correction → test it → verify production.
Without that path, patches accumulate until one eventually becomes urgent.
That is particularly dangerous in older applications, where a seemingly small security update can require a larger framework or runtime upgrade before it can be applied safely.
[Internal Link: “Why Security Patching Should Be Part of Every App Maintenance Plan”]
Applications increasingly contain large amounts of software that their own developers did not write.
Frameworks, libraries, SDKs, container images and transitive packages all become part of the application's security surface.
A dependency can operate perfectly while becoming a security liability.
OWASP's 2025 category on Software Supply Chain Failures warns about vulnerable, unsupported and outdated software across the application stack. It recommends tracking direct and transitive dependencies, monitoring relevant security information and addressing underlying platforms, frameworks and dependencies in a risk-based, timely manner.
Maintenance helps in two ways.
First, it gives teams visibility into what they actually run.
Second, regular dependency work prevents the application from moving so far behind supported versions that an urgent security fix becomes a major migration.
This distinction matters.
The immediate breach-prevention benefit is fixing known weaknesses.
The longer-term benefit is keeping the application fixable when the next weakness appears.
Maintenance is often associated with adding fixes, but removing things can improve security too.
Applications accumulate:
Every component that remains available represents something that may need to be authenticated, authorised, configured, updated, tested and monitored.
OWASP's guidance on security misconfiguration specifically warns about unnecessary features, services, accounts and privileges remaining enabled. It also notes that secure configuration needs to be repeatable across the application stack rather than performed once and forgotten. OWASP: Security Misconfiguration
An application-maintenance review should therefore occasionally ask:
What is still running that the product no longer needs?
Deleting an unused endpoint can sometimes provide better security than adding another control around it.
Not every breach begins with vulnerable software.
Attackers also use legitimate credentials.
That makes access maintenance important even when authentication itself is working exactly as designed.
Imagine an employee who originally needed customer-export privileges but moved to another team eighteen months ago. Their account remains active, and the old role remains attached.
If that account is later compromised, the attacker inherits privileges the employee no longer has any business need to possess.
The authentication system has not failed.
The access lifecycle has.
OWASP's Broken Access Control guidance describes the consequences of allowing identities to act outside their intended permissions, including unauthorised disclosure, modification or destruction of data.
Maintenance reduces this risk through recurring work such as:
This is especially important as an application grows. Permission models tend to expand much more readily than they contract.
[Internal Link: “How to Maintain Authentication and Access Control in a Growing App”]
An application may launch with secure configuration and still become less secure later.
Cloud permissions change. A diagnostic endpoint is enabled temporarily. A firewall exception is created during troubleshooting. A storage resource receives broader access so an integration can work. Debugging information is exposed to solve a production issue and never disabled.
These changes are often reasonable at the moment they are made.
The risk comes when temporary conditions quietly become permanent.
OWASP's Security Misconfiguration category includes improperly configured permissions, unnecessary features, default accounts, insecure framework settings and weak hardening across the technology stack. It specifically recommends a repeatable hardening process rather than relying on one-time configuration.
This is why configuration belongs inside maintenance.
Useful practices include keeping security-sensitive configuration reviewable, identifying differences between environments, removing temporary exceptions and checking that upgrades have not introduced insecure defaults.
The objective is not to freeze configuration.
It is to make changes visible enough that the application's security posture does not drift accidentally.
Applications contain identities that belong to systems rather than people:
These credentials often survive much longer than anyone originally intended because rotating them carries operational risk.
A key created for an integration three years ago may still work even though nobody is sure which services depend on it.
This creates a security problem because the organisation may struggle to respond if the credential is exposed.
Maintenance should make credential ownership and replacement normal rather than exceptional.
At minimum, teams should know:
A secret that cannot be rotated because nobody knows what will break has effectively become part of the application's maintenance debt.
Access control does not become vulnerable only because permissions are old.
New development can also break previously safe assumptions.
Suppose an application originally allowed each account to contain one organisation. Later, enterprise functionality introduces sub-organisations and delegated administrators.
An authorization check built around:
user belongs to account
may no longer be enough.
The application may now need:
user belongs to account
AND
user has permission for this organisation
AND
user may perform this action on this resource
If maintenance focuses only on keeping servers and dependencies updated, security can still deteriorate through product evolution.
This is why security regression testing matters after changes to roles, APIs, sensitive workflows and data models.
The question is not only:
Does the new feature work?
It is also:
Did this change allow anyone to see or do something they could not access before?
Preventing data breaches requires maintaining security assumptions alongside functionality.
Preventing initial access is only one part of breach prevention.
Sometimes an attacker gets in.
What happens next depends partly on whether the application exposes enough evidence for the activity to be detected.
OWASP's Logging Cheat Sheet recommends application-level security logging because application events often provide context that infrastructure logging alone cannot. It highlights the value of consistent security-event logging for analysis and incident investigation.
For an application, useful events might include:
Maintenance matters because logging ages too.
A new sensitive workflow may not be covered by old security events. An alert may still exist but point to a team channel nobody uses. A new API may bypass the logging used by the original web application.
Maintaining security visibility means periodically asking whether important activity would still be noticed.
Security monitoring cannot guarantee that an attacker never obtains access.
It can affect how long suspicious activity continues before somebody responds.
Consider two versions of the same compromised account.
In the first, it starts requesting thousands of customer records, but the behaviour generates no meaningful security signal.
In the second, abnormal export volume, unusual privilege use or suspicious resource access is visible quickly enough for responders to disable the account and investigate.
The original compromise is the same.
The eventual consequences may be very different.
This is why Observable reinforces Secure within Levelworks' App Health framework. Preventive security controls matter, but teams also need sufficient visibility to recognise when those controls have failed or are being tested.
Maintenance keeps that visibility aligned with the application's current behaviour instead of its architecture from two years ago.
Suppose a security review discovers that one API endpoint trusts an object ID supplied by the user without confirming ownership.
Engineering fixes the endpoint.
Three months later, another team creates a different endpoint with the same weakness.
The first vulnerability was patched.
The breach condition was not really removed because the underlying engineering pattern remains.
NIST's Secure Software Development Framework explicitly includes addressing the root causes of vulnerabilities so similar problems are less likely to recur, rather than limiting remediation to individual findings.
Application maintenance provides the opportunity to turn a security finding into a durable improvement.
That could mean:
The strongest maintenance work does not simply close tickets.
It makes the next version of the same vulnerability harder to create.
Security work often fails in the space between knowing about a problem and actually fixing it.
A vulnerability scanner raises a finding.
Nobody knows which team owns the affected service.
Engineering identifies a patch, but the application has poor regression coverage.
The update is postponed until the next release window.
That window slips.
Three months later, the vulnerability is still in production.
OWASP explicitly warns that slow risk-based updates can leave organisations exposed unnecessarily for days or months when patching is constrained by rigid maintenance processes.
A mature maintenance capability shortens this path because ownership, testing and deployment already exist.
The real security advantage is not that maintenance teams somehow predict every vulnerability.
It is that when a relevant weakness becomes known, the organisation can act while the information is still useful.
Security maintenance creates its own risk when performed carelessly.
A rushed patch can introduce a regression. A dependency update can break authentication. A new security configuration may accidentally block legitimate customers.
That is not an argument for postponing security work.
It is an argument for maintaining the application well enough that security changes can be introduced safely.
A useful lifecycle looks like:
Maintenance step
Breach-prevention purpose
Inventory
Know what needs protecting and updating
Detect
Identify vulnerabilities, suspicious behaviour and drift
Prioritise
Focus effort on meaningful exposure
Remediate
Remove or reduce the weakness
Test
Confirm the security change did not break essential behaviour
Deploy
Move the correction safely into production
Verify
Confirm the expected fix is actually operating
Learn
Prevent the same weakness from returning
This is where Tested and Seamlessly Updatable contribute indirectly to breach prevention.
The easier it is to change an application safely, the easier it is to remove security exposure before an attacker takes advantage of it.
Data exposure is partly determined by what the application retains and where copies accumulate.
Over time, systems can collect:
Not every application-maintenance team owns data-retention policy, and retention decisions may be shaped by legal and business requirements.
Still, maintenance should identify when application changes create unnecessary copies or new storage locations.
The security principle is straightforward:
Data the application genuinely no longer needs cannot be exposed through that application once it has been appropriately removed.
This should be handled carefully rather than becoming an excuse for uncontrolled deletion, but reviewing data flows as systems evolve can reduce the eventual impact of compromise.
The relationship between maintenance activity and breach risk becomes clearer when viewed together:
Maintenance activity
Security exposure it reduces
Security patching
Exploitation of known vulnerabilities
Dependency maintenance
Vulnerable or unsupported third-party code
Access reviews
Dormant and excessive privileges
Configuration reviews
Accidental exposure and insecure defaults
Credential maintenance
Long-lived or poorly controlled secrets
Authorization regression testing
Data access introduced by product changes
Security logging
Undetected suspicious application activity
Removal of obsolete functionality
Forgotten attack surface
Root-cause remediation
Recurrence of known vulnerability patterns
Safe deployment capability
Delay in getting security fixes into production
No row guarantees that a breach will not happen.
Together, they steadily reduce the number of easy opportunities available.
[Internal Link: “Application Security Maintenance: What Needs to Happen After Launch?”]
This distinction matters.
A properly maintained application can still be attacked through:
Maintenance is not a guarantee.
Its role is to prevent avoidable security deterioration.
There is an important difference between suffering a breach because an attacker exploited a genuinely novel weakness and suffering one through a vulnerability that had been known for months, an account that should have been removed, or a configuration exception nobody remembered existed.
Maintenance cannot eliminate adversaries.
It can eliminate many of the conditions that make their work easier.
A launch security review can tell you that an application is reasonably secure at one point in time.
It cannot preserve that condition.
Every subsequent dependency update, employee change, feature release, configuration adjustment, API integration and vulnerability disclosure has the potential to change the application's security posture.
That is why breach prevention is connected so closely to maintenance.
At Levelworks, Secure App Health is not treated as a certificate an application earns once. It is a condition that has to survive change, which in turn depends on the application remaining Current & Updated, Observable, Tested and sufficiently Seamlessly Updatable to correct weaknesses when they appear.
The value of application maintenance is rarely one dramatic security action.
It is the cumulative effect of closing old accounts, correcting vulnerable software, removing forgotten functionality, narrowing privileges, checking configuration, improving detection and making the next security fix easier to deploy than the last.
A breach often needs only one usable path.
Good maintenance keeps removing them.
