Secure Software Development – Right from the Start

Academy Compliance | IT-Security Software Developement

Secure software is a wonderful goal—at least as much for manufacturers as it is for innocent users, who ultimately deserve to trust in the reliability of systems. Unfortunately, however, reports of compromised systems are constantly on the rise. The sheer volume of data available to the recommended service Have I been pwned and an evaluation by the BSI underscore this very dramatically.

Secure Software Development:

Security as a Valuable Investment beyond GDPR and the Cyber Resilience Act
Lack of Awareness as a Key Cause
Creating Awareness as an Essential Lever
Principles for Greater Security in Development
Avoiding Programming Errors in Everyday Life
Integration of Tooling
On a Side Note: Contrary to Cognition
Conclusion
We Want to Make the Software World a Little Bit Better

1. Security as a Valuable Investment beyond GDPR and the Cyber Resilience Act

With the GDPR and the very recent Cyber Resilience Act, there are even legal requirements that place considerable responsibility on manufacturers for data protection and product safety. But quite apart from the legal requirements and the penalties associated with violations, there are other good reasons to invest in software security:

Prevention of costs for remedying defects and liability claims
Ensuring continuity in business operations
Protection of data and trade secrets
Trust of customers and partners

Nevertheless, there are still serious gaps in software systems, and no one wants to be responsible for them. But why is that?

2. Lack of Awareness as a Key Cause

By far the greatest risk to software security is a lack of awareness during the software development process, in two respects. This refers to the planning of software projects on the one hand and the technical implementation on the other.
In many software projects, security plays hardly any role at the outset, which is understandable in a way. After all, who wants to think about what could go wrong at the beginning of a great idea? Often, the thought only occurs during development, and sometimes the time or budget pressure is so great that there is no time left to think about security.

3. Creating Awareness as an Essential Lever

Secure software development therefore begins with awareness during the planning stage and, accordingly, at an early phase. The increasingly early consideration of security requirements in the course of software projects is not a new idea. This concept is aptly summarized as “shift left” and “security by design.”
However, it is clear from this that security is not just a matter for software developers. It is essential that everyone involved is aware of this – from management and project management to quality assurance and operations.

4. Principles for Greater Security in Development

Risk assessments should be planned early on in the project, as they enable informed decisions to be made. In an agile approach, reviews focusing on the potential for misuse of a feature can become part of the definition of done. Penetration testing, together with the option of correcting any gaps that arise, should be planned as a milestone before major releases, as this is a useful addition.

Taking software security into account in planning and methodology is an essential part of the challenge and should not be underestimated. Ultimately, this creates the necessary space to pay close attention to secure implementation when developing the software. Many security vulnerabilities are caused by programming errors that do not initially restrict functional correctness.

5. Avoiding Programming Errors in Everyday Life

The Open Web Application Security Project (OWASP) compiles the most common errors as the Top 10 and also provides initial recommendations for avoiding these errors – always worth a look. However, it takes a fair amount of experience and practice to be aware of the variety of these pitfalls “on the side” of implementing requirements – if it is even possible at all.

Peer reviews with experienced or specially trained team members can provide significant support in this regard by separating the responsibility for requirements-compliant implementation from that for rapid implementation.

Incidentally, the consistent implementation of domain-driven design also has a positive influence on software security, because the strong focus on the design of the domain model inherently overlaps with the avoidance of invalid states that are susceptible to abuse.

6. Integration of Tooling

Development teams also have the option of using a wide range of tools. These can be divided into three main categories

Static code analysis
Analysis of third-party components for vulnerabilities
Tools for attacking applications

Of course, the integration of tools is a significant help in preventing programming errors before they can be exploited. However, the responsibility for correct and secure implementation remains in the hands of the development team and is therefore only a useful addition to a well-trained team.

7. On a Side Note: Contrary to Cognition

Measuring the value of an investment in software security poses a particular cognitive challenge. This is because the true value of this investment is largely reflected in the absence of damage. In the best-case scenario, the person responsible will never feel the painful effects that they have actually spared themselves and the users affected. In fact, people sometimes tend to underestimate the probability of occurrence and the effects of adverse events. This effect is called optimism bias and belongs to the category of perception biases.

8. Conclusion

Security in development must be taken into account right from the start of planning, and this requires awareness—both of its value and of the measures needed to prevent problems—among all those involved in the project. This awareness, in turn, forms the basis for the development team to incorporate the extensive knowledge from the field of secure software development into the implementation. Acquiring this knowledge and the associated experience requires intensive engagement with the topic.

An approach that implements the principles and measures mentioned in this article can be described in a nutshell as SecDev (short for Secure Development). It can also be combined with the idea of DevOps to form DevSecOps.

Of course, not all software is fully exposed to the same risks, and it makes economic sense to weigh up the necessary measures. It is precisely this conscious risk management that is an essential part of compliance with the Cyber Resilience Act.

9. We Want to Make the Software World a Little Bit Better

When starting out in software development, whether through Chamber of Industry and Commerce training or a degree program, the initial focus is always on ensuring that a program performs a specific task. Only experience and real-world exposure to the impact of security vulnerabilities raise the secondary condition of “…and nothing more.”

With our workshop “Secure Coding – Security by Design,” we want to help bridge this gap and are happy to contribute to preventing vulnerabilities. The workshop offers the ideal opportunity to familiarize yourself with the topic of SecDev through practical exercises. In particular, being able to identify potential security vulnerabilities from an attacker’s perspective helps to effectively avoid them.