The world’s reliance on software is already great and will continue to grow. That's why the security of applications will also become increasingly important. This development is further reinforced by the global pandemic, as more businesses and services have increased their online availability. The U.S. Federal Bureau of Investigation (FBI), for example, has reported a 300% increase in cybercrime since the beginning of the pandemic: This shows that with the growing reliance on software and applications, the risk of attacks is also increasing.

Software developing companies are therefore in a dilemma: On the one hand, they have to release new products and upgrades quickly in order to be successful on the market. On the other hand, these should also be secure in order to avoid successful attacks. However, security is often seen as a brake on rapid development - and therefore unfortunately neglected.
Note: Some tests, "penetration tests" for example, can take a very long time (2 weeks) - a contradiction to short development cycles.

This opinion comes from the fact that for a very long time development and security teams worked separately. Development teams write new code and get it ready for release. Before release, the security team looks at the code again and makes security requests before GoLive. This loop sometimes makes the development process extremely prolonged. It can also create tension between teams, as it is seen more as criticism than a security improvement.

DevSecOps for better integration of security in software development

The DevSecOps approach offers an answer to these challenges. It is an evolution of the DevOps approach that allows development and operations teams to work more closely together. In DevSecOps, security teams are integrated into DevOps teams.

From being reactive to being proactive in security.

No matter how teams are organized, in most cases (security) mistakes are corrected reactively. This is usually done in these ways:

• Automated tests are written to check for known vulnerabilities.
• A bug is reported that was discovered either in manual tests or in production.

The goal should be to detect bugs as early as possible so that the effort to fix it is as low as possible. The shift-left approach does exactly that and has been around for a very long time. However, no matter how early a bug is found in the development process, it always requires that someone from the team has to go back into the old code to correct the bug. Reducing the effort further only works by proactively preventing bugs. For more information about how expensive it is to fix security issues, see here.

Learn to write secure code and not discover vulnerabilities

In order to proactively prevent (security) bugs, developers must be provided with appropriate security guidelines and knowledge about security vulnerabilities. The Open Web Application Security Project (OWASP) has defined 10 measures for this purpose:

• Define security requirements
• Use security frameworks and libraries
• Secure access to databases
• Encrypt and escape data
• Validate all input
• Implement digital identities
• Enforce authorization systems
• Protect data everywhere
• Log and monitor security-relevant events
• Handle all errors and exceptions

Learning approaches to increase security in software development

In order for developers to be able to implement these measures, they must of course have the necessary knowledge. There are a wide variety of approaches for this, which can be used for learning depending on the topic and personal preference. The important thing is, that the learning material should not only be easily accessible, but also timely.

Security training in DevSecOps

According to traditional understanding, security is not one of the core tasks of developers, namely the implementation of new functions. That's why training on security topics needs to be fun, challenging, and engaging in order to impart critical knowledge. It is important that trainings are conducted using real code, in the respective language and according to prior knowledge in order to have a direct knowledge transfer.
Since the security awareness of the developers should be strengthened, it makes sense to conduct trainings regularly in small units and not, for example, to attend a training once a year.

Tournaments for more web security

Learning, as mentioned before, should be fun, challenging, and engaging for developers. All of this is achieved through contests where participants compete to win by fixing security vulnerabilities. Such contests can last as little as a few hours or as long as several days. And because the topic of web security is so important to us, we have planned a competition on the topic of security to coincide with the launch of the Secure Code Warrior plugin in our SCM-Manager.

Learn more about the free tournament here.

Automated real-time coaching

Meanwhile, there are extensions for development environments that check the code in real time against specified security policies. This way, developers get feedback on whether or not their code meets security specifications right as they are writing the code. Ideally, they are given direct suggestions for corrections, as with a spell checker. In addition, suitable exercises can also be suggested. This is very much in the spirit of gamification or e-learning.

Assessing the security leak

In order to be able to define measures to improve security, it is first necessary to determine what the current status is. This is the only way to identify weak points. Ideally, the status quo should not be determined only once, but the development should be monitored continuously.
One way to see the current state of knowledge of the team is to introduce badges or awards for developers who have completed certain trainings, for example.

Conclusion

To make software applications more secure without extending the development time, it is necessary to proactively write secure code. To achieve this, traditional structures must be broken down and more responsibility for the security of applications must be transferred directly to the developers. The basic prerequisite for this is that the developers have the necessary knowledge. Fortunately, there are now many interactive and engaging ways of imparting knowledge, such as training, tournaments, real-time coaching and assessments, which provide knowledge with a high level of practical relevance in small learning units.