Security regulations such as the Cyber Resilience Act or KRITIS have now legally recognized the need for secure development and demand comprehensive security measures in the development process.

However, these demands are not exactly met with much enthusiasm among development and business teams. "If I implement all of this, I can stop developing altogether" is often the first, not entirely unjustified, reaction.

Secure coding ≠ Secure Development

Secure coding training alone will not make for a secure development process. Secure Coding explains how to write secure code in a specific programming language or framework. It is usually very specific and gives concrete code examples. This is important, but it only really applies in the implementation phase. The previous development phases, as well as the overarching concept of a "Secure Software Development Lifecycle (SSDLC)" are usually not addressed. And this is exactly where the problem arises.

Secure development goes far beyond the mere writing of secure code and covers the entire software development lifecycle (SDLC). Security is considered from the very beginning (security by design) and integrated into every step of the process - from requirements in engineering and the design phase to implementation, validation, testing, deployment and maintenance. Non-technical aspects such as secure design principles, threat modeling, risk assessment, etc. are given focus as well.

As we can see, secure coding alone is not enough to establish proper secure development.

Welcome to the LAB

Our Cyber LAB e-learning for developers is a secure development training that perfectly complements secure coding training and embeds it in the necessary overall context.

Try demo Let's talk

Understanding first, tasks later

Secure Development training courses such as the Cyber LAB e-learning for developers create the right basis. After the training, product managers, application owners, software architects and developers understand why secure development is fundamentally important and which components are required for it.

This is an enormous success and the willingness to invest in security increases significantly. However, this enthusiasm must then be channeled accordingly.

Best practice approach

The following approach has proven successful with our customers:

All relevant people complete the Cyber LAB e-learning for developers. This ensures that everyone has the same level of knowledge about the Secure Software Development Lifecycle and its benefits.

Afterwards, the development team and other stakeholders sit down together in a retrospective. These are an integral part of the development cycle within agile frameworks such as SCRUM, but even teams that do not work in an agile environment can benefit from a retrospective or similar exchange format.

During a retrospective, insights from the training should be freely discussed:

What has been going well so far from a Secure Development perspective and should be maintained?
What is not going so well or is not yet in place?
What measures need to be taken to close the gaps step-by-step?

These important findings should not be left to rot in Confluence or on a whiteboard, but should be stored as concrete work items with responsibilities in DevOps. We recommend establishing the role of a "Secure Development Champ". This person tracks the security backlog and orchestrates the various tasks. It can or should be rolled out on a cyclical basis (for example, semi-annually or annually) so that different people in the team put on the "security glasses" over time.

A practical example

During the retrospective, it becomes apparent that both threat modeling and code reviews are often neglected, sometimes completely forgotten, or only quickly " tucked" into the application at the end of development.

The team has already identified the reasons for this: Lack of time. Product management often plans release cycles too tightly. In the future, the necessary time for threat modeling and code review should be planned in advance of a project.

If Product Managers have also taken the Cyber LAB e-learning for developers, they will be positive about this proposal because they understand the absolute need and benefit. If not, this can be a very tough process as security competes with their default primary goals of "new features" and "speed".

As we can see, it is crucial to convince all stakeholders in the development process, especially the "business" part of it. A common understanding creates a good middle ground between business and security requirements. Secure coding training cannot possibly achieve this; it has a completely different goal.

Back to our practical example: the team has noticed in the retrospective that no or too few code reviews are carried out as part of the software releases. Fortunately, the product manager is also aware that for future releases 5% extra time has to be budgeted to implement the reviews.

Now the task is to embed the code reviews into the existing processes. The security champ could now evaluate tools for static code analysis themselves, or commission them. This can automate part of the reviews and relieve the team. From a certain risk level of the software, manual code reviews are also carried out. In the final process, no software should be put into production in the future without a risk assessment and the corresponding code review.

This example alone shows that integrating security into the development process is not a sprint, but a marathon. The topics are too multi-faceted and too complex to be done on the side. "Implementing SSDLC" (Secure Software Development Life Cycle) has the makings of an epic with many user stories, work items and story points. Priority needs to be aligned with the business functions. Some topics like static code analysis, dependency tracker or secure coding training are almost "quick wins" and significantly reduce typical vulnerabilities in software. Others can take months or years. But the journey is worthwhile: every step towards secure development continues to reduce the risks.

In summary

Secure development is now a "must have", both due to legal regulations and the modern day threat situation. But nobody is waiting for security and looking forward to it, neither in business nor in development. Therefore, it is essential that all stakeholders understand that Secure Development is not just "compliance nonsense", but an important concept that should become the basic attitude of everyone involved. Secure Development training courses such as the Cyber Security LAB e-learning for developers can go a long way towards achieving this understanding. Subsequently, the positive energy generated should be translated into concrete projects and work items and prioritized together with the business department.

The most effective and lasting employee training

Convince yourself of the Cyber LAB with a free demo.

Try free demos Let's talk

Make secure development a pillar of your development process