Security audits for software mean spotting security vulnerabilities continuously as part of development instead of reacting only after an incident. The key is not a one-off cleanup but continuous code security analysis with a positive trend: preventing new problems, reducing existing ones step by step and building the tools directly into code review.
Key Takeaways
- Ad hoc attention to security doesn’t work: teams that only tackle the topic after an incident lose interest just as quickly as it arrived.
- Instead of big cleanups, follow the campsite rule: whenever you touch a file or method anyway, fix two or three security findings in it along the way.
- The pull request is the best place for security checks, because every change passes through it anyway and a human reviewer sees the tool results right away.
- A seven-figure number of findings is no reason to panic: a team that sets a baseline and keeps improving the trend achieves more than one that cleans up once and then stops.
- Security can’t be assessed at code level alone, because role concepts, IT infrastructure and organizational rules always have to be considered too.
Why Security Problems Stay Unresolved for So Long
Almost everyone agrees that security matters, yet most systems carry unresolved security problems. That contradiction is the heart of the issue, and it is why code security analysis so often stalls. Nobody needs much convincing that security is relevant. What regularly fails is the step from awareness to action.
One reason is how hard the topic is to get a grip on. When a major hack makes the news, everyone is alarmed and attention is high. Then comes the sober question: does this even affect us? With the Log4Shell vulnerability, that was still fairly easy to check. Many other problems are more complex and can’t be traced back to your own system in a few minutes.
Then there is feature pressure. Development teams are driven by features: the next sprint, the next release. No team ever says, “We don’t have any features right now, so let’s look at security.” Features are always there, and they always take priority. Security competes with them for the same time.
Checking Findings at Code Level Is Expensive
Security findings often can’t be resolved by looking at the code alone, and that is exactly what makes them so costly. An example: values are read from an ini file. The question immediately comes up of who is allowed to write to that file. You can’t tell that from the code.
So the analysis quickly moves away from the individual file toward IT infrastructure, role concepts and organizational questions. Security simply isn’t a pure code topic. The local context of a file is often not enough to assess a finding.
On top of that come false positives, which tend to be more frequent in security than in other kinds of analysis. Wading through them is tedious and not very rewarding. Progress is slow, and disillusionment sets in quickly. That delays the work even further.
Developers and Management Draw Different Conclusions from the Same Findings
The two perspectives on security don’t automatically fit together. The development team has to understand every finding at a detailed code level and decide whether it is real. Management has a legitimate interest in a secure system, often reinforced by regulatory requirements or external guidelines.
In practice, management often looks at the bare numbers. Whether a finding is a false positive fades into the background. Findings like that simply shouldn’t show up. That creates tension with a team that has to assess every single finding at great cost.
This gap between detailed work at the bottom and a numbers view at the top is one of the reasons well-meant security initiatives fall apart.
Ad Hoc Attention Doesn’t Work, Continuous Attention Does
Sporadic attention to security achieves nothing. Something happens, everyone is stirred up, a few things get done, and then the attention is gone again. This pattern demonstrably doesn’t hold.
What holds is working on the topic continuously, and that applies to quality topics in general, not just security. In the short term, not every problem disappears. But in the medium term a positive trend sets in, and that is what counts.
A team that stops the problems from growing has already achieved a lot: things don’t get any worse. That is the first realistic stage. A team that then manages to keep improving is on the right track. Every sensible method aims to build security into the normal development process instead of running it as a special campaign on the side.
Code Security Analysis Belongs in the Merge Request
The biggest lever sits where every change passes through anyway: in the merge request or pull request. GitLab and GitHub established this place long ago, and it is exactly where review happens.
If the information “here are three new security findings” shows up directly in the merge request, you have a checkpoint with a very low threshold. Nobody has to open a second tool or dig a static HTML report out of some directory. The information is right where someone has to approve the change anyway.
A practical rule: as long as the tools still report findings, no human reviewer looks at the change. Human review only starts once the automated checks are clean. That saves reviewer time and makes clean code a prerequisite rather than a nice extra.
This requires transparency. It is unfair when a central security team shows up at some point and unpacks a list of problems. Teams need to know in advance what is being checked and where they can look for themselves. Whatever a tool can check and is relevant in the given context should be switched on. Irrelevant checks should be switched off.
A Baseline Beats the Big Cleanup
With legacy systems and huge numbers of findings, accepting the status quo is the decisive step. Seven-figure finding counts are nothing unusual. Trying to bring everything down to zero runs into reality and fails.
The solution sounds almost trivial at first: set a baseline and accept the current state. With seven million findings, the goal is not to work through all of them but to make sure there are no more by the next retrospective. Reducing the backlog takes a long time. Preventing new problems is the point where the trend turns.
That trend is motivating. At some point the absolute number fades into the background, and you only look at the direction: if it worked again, the arrows point up. That holds up better than any absolute metric.
Big cleanup campaigns, on the other hand, usually backfire. Three weeks without features cause frustration, because the features are missing. Worse still, the fixes often bring in new problems, and then you are left with a weak case.
The campsite rule works better: leave the campsite a little cleaner than you found it.
“When you edit a file and change code there, take it as an opportunity to address the problems in it. You’re in there anyway, you’ve read it, you’ve understood it, and it has to go through testing and review.”
(Nils Göde)
How Much Security Knowledge a Development Team Really Needs
A solid basic knowledge is enough, mainly at code level. Nobody has to become a full-time security expert, and in-depth knowledge of every vulnerability isn’t the goal. For deeper attack surfaces, there is the penetration test as a complement, which catches things other checks don’t see.
Reviews and retrospectives are a good forum for sharing knowledge. Most teams have one or two people who have already dealt with the topic. If you open up two or three example findings in a retrospective and ask why this is a problem, whether it affects you and how you want to handle it in future, you get a real exchange.
Add a bit of documentation and the foundation is solid. Extending the coding guidelines with a security section captures the knowledge and makes it available to everyone.
How a Team Builds Security Audits into Its Development Process
The most pragmatic way in is the tool that is already in use. Many analysis tools already come with a set of security checks. These checks are a usable starting point, without having to think the whole topic through top-down first.
To begin, you probably need some kind of kick-off that puts security on the agenda in the first place. After that, depending on the application, it is worth looking at guidelines such as the OWASP Top 10. The question is: what do our existing tools cover, where are the gaps, and do we need a second tool to close them? An integration platform brings this information together in one place, so nobody has to check five tools in five places.
From there, you work your way forward step by step through retrospectives:
- Checks that are never relevant in your context get deactivated in the configuration, and their findings disappear.
- Checks that are relevant in principle but produce individual irrelevant hits get discussed in the team. Example: passwords in production code are a clear problem, passwords in test code are open to debate.
- Step by step, you arrive at a fitting tool configuration plus guidelines that can be sustained with little effort.
Little effort is the crux. Security must not become an extra project. It has to run along with everything else.
Security vs. Convenience: A Trade-Off Many Never Think Through
Between security and convenience there is a slider, and many teams have never consciously decided where it should sit. One hundred percent security doesn’t exist anyway. But the position on this scale can be moved, toward security or toward convenience.
The ATM is a good illustration. Without a PIN it would be more convenient, but less secure. The same applies to most software systems. An initial meeting is a good occasion to face this question deliberately instead of leaving it unspoken.
Test users show the same thing. Test accounts get flagged in audits, for example because organizational policies require regular password changes. How secure the test infrastructure should be and how convenient it may remain is exactly the kind of trade-off decision that belongs with the team.
What Incidents Like Log4Shell Actually Change
A major incident creates momentum, and that momentum can be turned into lasting attention. With Log4Shell, everyone felt the relevance, and everyone tried to understand where the problem was and how to protect themselves. In that sense, the mechanism worked.
The catch is that reactions like this are still ad hoc. There is a big problem right now, so everyone deals with it. In good cases, teams manage to turn it into an appropriate level of lasting attention to security. That is where the real value of an incident lies.
Unexploited Vulnerabilities Are Sleeping Risks, Not a Free Pass
A vulnerability that causes no damage today is no proof that it is harmless. It builds up risk for the future. At best, it never gets exploited, but you can’t rely on that.
Assuming that unexploited vulnerabilities will never be exploited is risky. Some vulnerabilities are exploited in one way or another without a worst-case disaster. Not every attack aims to take a system down. For some attackers, it is enough to quietly siphon off huge amounts of data without anyone noticing.
That is why honest wording matters: as far as we currently know, nothing has happened. You can’t know for sure. The number of unreported cases is likely high, not least because those affected have no interest in such incidents becoming public.
Frequently Asked Questions
Why is it rarely possible to resolve a security finding based solely on the source code?
The local context of a file is often insufficient. When values are read from an ini file, the question immediately arises as to who is actually authorized to write to that file. This isn’t apparent from the code. The analysis therefore shifts to the IT infrastructure, role-based access controls, and organizational rules. This is exactly what makes evaluating individual findings so costly.
Why do development teams and management assess the same list of findings differently?
The team must review each finding at the detailed code level and decide whether it’s valid. On the management side, it’s often the raw numbers that matter, frequently reinforced by regulatory requirements or external guidelines. Whether a finding is a false positive takes a back seat: it simply shouldn’t appear. This disconnect is what causes well-intentioned security initiatives to fall apart.
At what point in the development process should automated security checks be triggered?
In the merge request or pull request, because that’s where every change passes through anyway and where the review takes place. No one has to open a second tool or search for a static HTML report. A practical rule: As long as the tools are still reporting findings, no human reviewer should touch the change. This requires transparency about what is being checked.
Is it worth spending several weeks on a cleanup effort to eliminate legacy security issues?
Usually not. Three weeks without new features lead to frustration, and the fixes often introduce new problems, which weakens the case for the effort. A more sustainable approach is the “campsite rule”: Whenever you’re editing a file anyway, fix two or three findings right there. Supplement this with a baseline to ensure the number doesn’t increase by the next retrospective.
Does a development team need to build up real security expertise?
No. A solid basic understanding at the code level is sufficient; in-depth knowledge of every single vulnerability isn’t the goal. For deeper vulnerabilities, penetration testing serves as a complementary measure. Reviews and retrospectives serve as a forum: bring up two or three representative findings and clarify why they’re a problem. A security section in the coding guidelines documents the results.
Where does a team that hasn’t systematically addressed security before start?
With the analysis tool that’s already in use. Many of these tools already come with a range of security checks that serve as a good starting point, without the need to first think through the topic top-down. A kick-off meeting puts security on the agenda; afterward, it’s worth comparing the results against guidelines such as the OWASP Top 10: What do the existing tools cover, and where are the gaps?
Is a vulnerability that has never been exploited harmless?
No, it sets the stage for the future. There are vulnerabilities that are exploited without leading to a worst-case scenario: Not every attack aims to cripple a system; for some, it’s enough to siphon off massive amounts of data without being noticed. It’s therefore accurate to say that, based on current knowledge, nothing has happened. The number of unreported incidents is likely high.
