Under the name “DevSecOps”, the topic of security becomes the central tenet of the DevOps approach. This is a holistic approach that considers security in all phases of the software life cycle (SDLC) – that is, from development to delivery and operation of software. All teams involved are jointly responsible for the security area.
For DevSecOps initiatives to succeed, the following three principles must be adhered to:
Securing code as fast as you write it with tools that easily integrate with your IDE (Integrated Development Environment).
Run the right tests at the right time in the SDLC.
The ability to filter out as much noise as possible and focus on the data collected through intelligent testing.
Ideally, the different development teams work together on software development. In DevSecOps environments, specially trained and sensitized “Software Security Champions” play a central role. They support other developers in the team with their knowledge of security issues – directly in connection with day-to-day development. “Software Security Champions” have undergone special security training and consistently analyze other developers’ code to see how it can be optimized for greater security. The great advantage of a master is that he himself speaks the language of the developers. At best, he can convey his additional security expertise in a plausible manner. Developers not only benefit from this in specific individual cases, they also learn to develop more securely. This knowledge naturally accumulates over time and almost inevitably leads to high-quality code that is secure at the same time.
Developers usually deal with security information anyway. However, what is often neglected in training is the question of how to optimally program secure code. In order for software to become more secure in general, you must constantly engage with the subject, directly and specifically related to your own code. General education courses do not go far enough. Holistic training, on the other hand, specifically supports your own specialist knowledge (developing high-quality code) and extends it to include security-related aspects. To this end, developers receive basic training in security and at the same time special “Software Security Champions” are trained.
Ideally, developers are trained accordingly at an early stage in the software life cycle (software development life cycle, SDLC). The more a developer knows about quality and security, the better he can use security functions and the possibilities within the relevant development environments, programming languages and infrastructures. Safety is top priority and starts with the design and planning phase of new projects.
Software security masters, in turn, educate other developers while collaborating with them. It is very important that the masters themselves are full-time developers – and not security experts who only know the development from the outside. Because of their specialization in security topics, such masters usually recognize very quickly exactly where improvements are needed in the code. And they are able to convey this knowledge to their colleagues in their own language.
Ideally, programmers should be trained to become software security masters, since they already deal intensively with the topic of security and have a strong interest in secure software. At the same time, development teams benefit from this tight integration, and friction losses can be largely avoided.
Often, the champions on each team also work more closely with other teams to solve security issues together (and faster). In this way, security knowledge is multiplied internally in the company and between the developers, and any existing silos can be broken down.
If developers already at the start of the project have the necessary knowledge to program secure, high-quality code, common errors and vulnerabilities can be avoided. If you look at the top 10 of the Open Web Application Security Project (OWASP), you will see that many application security problems could be avoided. For example, vulnerabilities such as server-side request forgery (SSRF), i.e. server-side request forgery, injection problems (including XSS and SQLi), and broken access controls are addressed at the coding stage. However, only if developers are aware of these problems and know how to prevent them.
Reading tips: Aqua Security Analysis – How to protect your software supply chain
Dynamic and Static Application Security Testing – The Best DAST and SAST Tools
Holistic learning plays a central role in the continuing education of developers. Through ongoing training, developers gradually expand their skills and then generally fall back on “best practices”. Unfortunately, a number of courses are often used. Developers often use different platforms and different lab environments to further their education in the individual areas. Most of the time this information is not prepared in a targeted manner and is kept too general.
Here, central platforms should be used, in which the developer code can be included. This way you can improve the code directly from practice. The training should be an integral part of the development, if possible already at the programming stage. Often you then realize that very similar security issues occur more frequently in software or within a team. Then it might make sense to address this problem head on to avoid it altogether in the future. With this approach, developers learn where vulnerabilities commonly occur and how to improve their code as they code.
Interactive training of this type has a number of advantages. If you analyze the written code at an early stage, in most cases it leads to concrete suggestions for improvements. These can be implemented immediately, possibly even in a specially designed virtual test environment. This not only reveals fundamental weaknesses in programming, but also allows you to improve your own approach.
If a training is running while a developer is programming, this is the perfect time to change behavior. There are two different programming modes. First, the creative artistic mode where the developer writes unique code, solves problems and dives into new features. The second mode is often referred to as “whack-a-mole” mode, when the code doesn’t do what it’s supposed to and you struggle to fix bugs and vulnerabilities.
In the phase where a developer sees himself as an artist, he is open to new information. That’s it in “Whack-a-Mole” mode. Developers then tend to become frantic and eliminate the bugs that arise as quickly as possible. If you want to permanently change this behavior and teach developers how to develop secure code, then you need to do it in artist mode.
A training system that works intelligently with the real development context and the integrated development environment (IDE) is the most effective way to positively influence application security (AppSec, application security).
One aspect that should not be underestimated is changing the perspective. In other words, to think into an attacker’s approach. When developers understand how hackers and malware authors think, this knowledge flows directly into programming their own code, making it more secure.
In theory, many companies are prepared for attacks from hackers and malware or ransomware attacks. However, practical procedures are often lacking, and only in the rarest of cases is one’s own network seen from the perspective of a potential attacker. This also applies to developers. Most attackers use vulnerabilities in an application to gain access to a network. If developers are familiar with these procedures, it helps to program their own applications in such a way that attackers have little or no opportunity to exploit security holes. (jm)