One of the most frustrating situations in application security is seeing the same type of vulnerability return after it was already fixed.
A team may resolve an issue, close the finding, and move on. A few months later, the same vulnerability appears in another part of the application or in a different project.
When that keeps happening, the problem is usually bigger than one developer making one mistake. It is often a sign that something in the development or security process needs to change.
Fixing the Finding Is Not the Same as Fixing the Cause
Security teams naturally focus on individual findings because those are what scanners and testing tools report.
A static analysis tool may identify SQL injection. A software composition analysis tool may flag a vulnerable dependency. A penetration test may uncover weak authorization.
The immediate response is usually to fix that specific issue.
That is necessary, but it does not always prevent the same weakness from coming back.
If several teams continue introducing the same vulnerability, the more useful question becomes:
Why does our development process continue allowing this problem to happen?
That question shifts the conversation from remediation to prevention.
Look for Patterns Across Applications
Individual findings can look unrelated when teams review them one ticket at a time.
Patterns become much easier to see when AppSec teams step back and look across applications, repositories and development teams.
For example, if hardcoded credentials repeatedly appear across different projects, the issue may not simply be developer behavior. Teams may not have an easy or clearly documented way to use an approved secrets management solution.
If authorization problems appear repeatedly, developers may not have reusable access-control patterns or clear security requirements.
If vulnerable libraries keep returning, dependency management may not be built consistently into CI/CD pipelines.
Recurring findings often point to gaps in the system around developers, not just mistakes made by individual developers.
Security Requirements Need to Be Clear
Some vulnerabilities happen because security expectations are introduced too late.
A team may receive a security finding after development is complete, even though the requirement could have been discussed when the feature was designed.
Security requirements do not need to be long documents.
For a feature involving sensitive information, teams may simply need to know:
- who should be allowed to access the data,
- how access should be enforced,
- whether the data should be encrypted,
- what activity needs to be logged,
- and what should happen when access fails.
When those expectations are clear before coding begins, developers have a better chance of building the right controls the first time.
Give Developers Reusable Solutions
Telling developers to “write secure code” is not enough.
If an organization repeatedly sees the same weakness, AppSec teams should ask whether developers have a simple, reusable way to solve it.
That might mean creating secure coding examples, approved libraries, reusable authentication components, pipeline templates or common configuration standards.
For example, if teams repeatedly mishandle secrets, providing a standard integration with an enterprise secrets manager can be more effective than repeatedly opening findings about credentials stored in configuration files.
The easier the secure path is to follow, the more likely teams are to use it consistently.
Improve the Feedback Loop
Developers also need to understand why a finding matters.
A scanner report that simply says “high severity” may tell a developer what to fix, but it may not explain what should change in future development.
Good AppSec feedback should help answer three questions:
What went wrong?
Why does it matter?
How can we prevent it next time?
That does not require a long security training session for every finding.
Sometimes a short explanation, a secure example and a link to an internal development standard are enough to turn one remediation task into a learning opportunity.
Measure Recurrence, Not Just Closure
Many vulnerability programs focus heavily on how many findings were opened and how many were closed.
Those numbers are useful, but they do not always show whether security is improving.
A team can close hundreds of findings and still continue introducing the same weaknesses.
AppSec teams should also look at recurrence.
Are the same vulnerability types appearing quarter after quarter?
Are particular controls consistently missing?
Do certain security issues appear across multiple development teams?
Those patterns can help identify where secure coding guidance, architecture standards, reusable controls or pipeline checks need to improve.
The Goal Is to Break the Cycle
Application security should not become a cycle where security finds an issue, developers fix it, and the same issue returns somewhere else.
Individual remediation will always be part of security work, but mature AppSec programs also look for the conditions that allowed the vulnerability to happen in the first place.
Sometimes the answer is better training.
Sometimes it is clearer requirements.
Sometimes it is a reusable security control.
Sometimes it is an automated check in the development pipeline.
And sometimes it is simply making the secure option easier for developers to use.
The most valuable question after fixing a recurring vulnerability is not only, “Did we close the finding?”
It is:
“What should we change so we do not have to fix this again?”
Note: These comments reflect the author’s personal professional views and do not represent the official position of his employer.
Join our LinkedIn group Information Security Community!
