Make secure development a pillar of your development process

Here's how to bring security from your backlog to day-to-day development

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 with much enthusiasm among development and business teams. "If I implement all this, I can stop developing" are often the first, not unjustified, reactions.

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, Secure Development Life Cycle). Security is considered from the very beginning (security by design) and integrated into every step of the process - from requirements 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.

Secure Development Training

By the way: 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.
Secure Development Training for Developers

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.

The success is enormous 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 the 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 primary goals of "new features" and "speed".

Secure Development - Retrospective

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 him- or herself, 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 multifaceted 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 also reduces the risks step by step.

In summary

Secure development is now a "must have", both due to legal regulations and the 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 "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.