Security analyses

Security audits for software mean continuously recognizing security vulnerabilities in the development process instead of only reacting after an incident. The key lies not in one-off clean-ups, but in a positive trend: avoiding new problems, gradually reducing existing ones, integrating tools directly into code reviews.

Key Takeaways

• Ad hoc attention to security does not work: If you only address the issue after an incident, you will lose the attention just as quickly as it came.
• The campsite rule is recommended instead of tidying up: if you are going to touch a file or method anyway, you should get rid of two or three security findings at the same time.
• The pull request is the best integration location for security checks because every change is made there anyway and a human reviewer sees the tool results immediately.
• A seven-digit finding number is no reason to panic: If you draw a baseline and continuously improve the trend, you have achieved more than a team that cleans up once and then does nothing.
• Security cannot be answered at code level alone, because role concepts, IT infrastructure and organizational rules must also be taken into account.

Why security problems remain unresolved for so long

Almost everyone thinks security is important, and yet most systems have unresolved security problems. This contradiction is at the heart of the problem. It doesn’t take much convincing to make someone realize that security is relevant. However, the step from awareness to action regularly fails.

One reason is the sheer difficulty of tackling the issue. When a major hacker makes the news, everyone is startled and attention is high. Then comes the sober question: does this affect us at all? In the case of the Log4Shell gap, this was relatively easy to check. Many other problems are more complex and cannot be identified in just a few minutes.

Added to this is the pressure of features. Development teams work feature-driven, the next sprint, the next release. No team says: We don’t have any features at the moment, let’s take care of security. The features are always there, always more prominent. Security competes with them for the same amount of time.

Checking findings at code level is expensive

Security findings often cannot be answered in code alone, and that is precisely what makes them so costly. An example: Values are read from an ini file. The question immediately arises as to who is allowed to write to this file. You can’t tell from the code.

As a result, the analysis quickly moves away from the individual file to the IT infrastructure, role concepts and organizational issues. Security is not just a code issue. The local context of a file is often not enough to evaluate a finding.

There are also false positives, which tend to be more common in the security sector than in other analyses. Digging through these findings is tedious and not very satisfying. Hardly any progress is made and disillusionment quickly sets in. This further delays the debate.

Development and management draw different conclusions from the same findings

The two perspectives on security do not automatically fit together. The development team must understand each finding at a detailed code level and decide whether it is real. Management has a legitimate interest in a secure system, often reinforced by requirements from authorities or external guidelines.

In practice, it is often the bare figures that count on the management side. Whether a finding is a false positive or not takes a back seat. Such findings should simply not appear. This creates tension for a team that has to classify each individual finding at great expense.

This gap between detailed work at the bottom and an eye for numbers at the top is one of the reasons why well-intentioned security initiatives fall apart.

Ad hoc attention does not work, continuous attention does

Sporadic attention to security is useless. Something happens, everyone is startled, a few things are done, and then the attention is gone again. This pattern has been proven not to work.

What works is continuous engagement with the topic, and this applies to quality issues in general, not just security. Not all problems will disappear in the short term. In the medium term, however, a positive trend will emerge, and that is exactly what matters.

A team that stops the problems has already achieved a great deal: things are no longer getting worse. That is the first realistic stage. Anyone who manages to continuously improve after that is on the right track. All sensible methods are aimed at integrating security into the normal development process instead of setting it aside as a special action.

How the merge request becomes the best place for security

The greatest leverage is where every change is made anyway: in the merge request or pull request. GitLab and GitHub have long since established this place, and this is exactly where the review takes place.

If you put the information “here are three new findings in the area of security” directly in the merge request, you have a checkpoint with a very low threshold. Nobody has to open a second tool or search for a static HTML report from any directory. The information is there where someone has to approve the change anyway.

A workable rule: As long as the tools are still reporting findings, no human reviewer goes to the change. Only when the automatic checks are clean does the human review begin. This saves reviewers time and makes the threshold for clean code a prerequisite, not an optional extra.

The prerequisite for this is transparency. It is unfair if a cross-sectional security team turns up at some point and unpacks a list of problems. Teams need to know in advance what is being looked at and where they can check for themselves. What can be checked using a tool and is relevant in the respective context should be activated. Irrelevant checks should be switched off.

A baseline beats the big clean-up operation

For legacy systems with huge numbers of Findings, accepting the status quo is the decisive step. Seven-digit Findings figures are nothing unusual. Anyone who tries to bring everything to zero will fail in the face of reality.

The solution sounds banal at first: You draw a baseline and accept the current status. With seven million findings, the goal is not to work them all off, but to ensure that there are no more at the next retrospective. Reducing the number of findings passed takes a long time. Avoiding new problems is the point at which the trend reverses.

This trend has a motivating effect. At some point, the absolute figure fades into the background and you only look at the direction: if things have worked out again, the arrows are pointing upwards. This is more sustainable than any absolute figure.

Big clean-up campaigns, on the other hand, are usually counterproductive. Three weeks without features create frustration because the features are missing. Worse still, the corrections often lead to new problems, and then you are in a bad position in terms of arguments.

The campsite rule is better: leave the campsite a little cleaner than you found it.

If you edit a file and change code there, use this as an opportunity to address the problems there. You’re in it anyway, you’ve read it, you’ve understood it, it needs to go through testing and review.

• Nils Göde

How much security knowledge a development team really needs

A solid basic knowledge is enough, especially at code level, nobody needs to become a full-time security expert. The aim is not to go into detail in every gap. For deeper attack surfaces, there is also the pen test, which catches things that other tests do not see.

Reviews and retrospectives are a good forum for sharing knowledge. There are usually one or two people in the team who have already dealt with the topic. If you look at two or three exemplary findings in a retrospective and ask: Why is this a problem, does it affect us, how do we deal with it in the future, a real exchange of ideas is created.

Supplemented by some documentation, the basis is solid. Adding a security section to the coding guidelines captures the knowledge and makes it usable for everyone.

This is how a team starts continuous security work

The most pragmatic way to get started is via the tool that is already in use. Many analysis tools already come with a series of security checks. These checks are a useful starting point without having to think through the topic completely top-down beforehand.

You probably need a kind of kick-off to get security on the agenda in the first place. Depending on the application, it is then worth taking a look at guidelines such as the OWASP Top 10. The question here is: what do our existing tools cover, where are the gaps, and do we need a second tool to close them? An integration platform bundles this information in one place so that no one has to check five tools in five places.

From there, you move forward step by step via retrospectives:

• Checks that are never relevant in your own context are deactivated in the configuration and the findings disappear.
• Checks that are fundamentally relevant but deliver individual non-relevant hits are discussed in the team. Example: Passwords in production code are a clear problem, passwords in test code are worth discussing.
• Step by step, a suitable tool configuration and guidelines are created that can be implemented permanently with little effort.

The little effort is the crux of the matter. Security must not become an additional project, but must run alongside the track.

Security versus convenience: a trade-off that many never think through to the end

There is a slider between security and convenience, and many teams have never consciously decided where it should be. There is no such thing as one hundred percent safety anyway. But the position on this scale can be shifted, towards safety or towards comfort.

The ATM is a good example of this. Without a PIN, it would be more convenient, but less secure. The same applies to the vast majority of software systems. An initial meeting is a good opportunity to consciously address this question instead of leaving it implicit.

This can also be seen in the example of test users. Test accounts are used in tests, for example because organizational requirements demand regular password changes. How secure the test infrastructure should be and how convenient it should remain is just such a trade-off decision that belongs in the team.

What incidents like Log4Shell actually change

A major incident creates momentum, and that momentum can be translated into sustained attention. In the case of Log4Shell, the relevance was felt by everyone, everyone was keen to understand what the problem was and how to protect themselves. In this respect, the mechanism worked.

The catch: such reactions still have the character of an ad hoc approach. There’s a big problem at the moment, so everyone takes care of it. In favorable cases, it is possible to establish an appropriate level of permanent attention for security. This is precisely the value of an incident.

Unused vulnerabilities are dormant sleepers, not carte blanche

A vulnerability that causes no damage today is not proof that it is harmless. It pays dividends for the future. At best, it will not be exploited, but you cannot rely on it.

It is risky to assume that unused gaps will never be exploited. There are loopholes that are exploited in some way without causing a super-GAU. Not every attacker wants to paralyze a system. For some, it is enough to siphon off masses of data without anyone noticing.

That’s why it’s important to be honest: to the best of our knowledge, nothing has happened. There is no way of knowing. The number of unreported cases is likely to be high, partly because those affected have no interest in such incidents becoming public.