Secure software development based on the

Secure software development based on the "Security by Design" principle

Many online services and websites are vulnerable to cyber-attacks. The development of modern software for web applications is so complex nowadays that errors are difficult or impossible to detect despite intensive testing.

Security plays an important role in software and should therefore be considered right from the start of the project. The necessary steps can be well integrated into the phases of the software development life cycle and thus accompany the development.

In the past, virtually all software was developed over long periods. New versions might have been released once or twice a year, maybe only every few years. A correspondingly large amount of time could have been spent on tests and security concepts.

Nowadays things have to go faster in many cases: sometimes patches should even reach the customer every few weeks. In practice, the focus often goes on delivering tangible content. You focus on functionality and design because the customer can see and evaluate these aspects.

In contrast, sophisticated security mechanisms and thorough test scenarios produce results that are barely visible at first glance. If these points are the last in the development process, sometimes they are neglected too much. Especially when the release cycles are supposed to be short, tasks without tangible results are dropped first. 

So, it makes sense to include the topic of security firmly from the start and thus spread the tasks over the entire cycle. In each phase, the aspects that are at stake can be optimally addressed, and no area is neglected.

However, it will probably be a few years before this knowledge is widely accepted, although there are demonstrably effective methods for avoiding security gaps, such as the "Security by Design" principle presented in this article.

Security and software – does that fit?

If you look at the current situation in software development, it seems reasonable to assume that oftenly, inefficient security measures are used in software development. If you carry out a penetration test on software shortly before it is put into operation, it is usually easy for an experienced tester to break into the application. It is therefore questionable whether a penetration test makes sense at all if the issue of security has not been specifically considered during the development process. In addition, serious security gaps can no longer be shortly remedied before a planned delivery or could be recovered only with great and cost-intensive effort.

Another common measure, the code review, in which a reviewer proofreads a program section after or during development to find errors, suffers from the fact that only qualified personnel can carry out the review, which is also associated with high costs. Therefore, complex programs can hardly be comprehensively checked. In addition, a code review only helps to identify implementation errors but does not reveal any design or configuration errors. 

The main cause of security problems today is that organizations rarely define security as an explicit requirement. It is not uncommon for clients to specify only functional requirements and rely on security methods such as code reviews or penetration tests, which are effective and recommended, but their efficiency depends on their combination and when they are used.

Security in small steps

As you can see, security in software development is more important than ever. New technologies are constantly becoming available, which in turn pave the way for increasingly complex threat scenarios. In addition, the security demands are growing, for example, due to legal requirements or the advancing digitization of everyday life.

For software developers, this means that security should be holistically integrated into every project from the start to cover as many scenarios as possible. This can be planned: in the Secure Software Development Life Cycle, certain steps can take place in each phase that is specifically aimed at the security of the project.

Companies like Microsoft, which were confronted with the effects of unsafe software at an early stage, have been looking for solutions for years and have found, implemented, and continuously revised them. Microsoft's principle is called "Security by Design" and stands for integrated software security or requires security to be included as an explicit requirement in the development process and holistic security measures to be considered, implemented, and tested from initial phase. Consistently implemented, the delivery of software is even postponed until security errors, provided they exceed a defined threshold, have been resolved.

 Security by Design is not a technology, but a security measure that accompanies the development process and is often referred to as the Security Development Lifecycle (SDL). The measures should result in integrated and sustainable security of the developed software.

For you to understand how we develop secure applications, applying the “secure by design” principle, we want to break the phases of security by design down in the next chapter of an article.

Planning and analysis

The project is still at the very beginning. It is currently being planned what the software should be able to do later and how these goals could be achieved. Now is the time to set security guidelines and consider possible vulnerabilities. What should users not be able to do? What could an attacker possibly intend to do and how could he achieve his goal and what should we do to prevent that?

In an agile environment, user stories are often used to map the planned functions. This offers the possibility of including user stories in the planning phase from the perspective of an attacker. They try to figure out malicious intent so that predictive countermeasures can be incorporated later.


At this point, how the requirements can be implemented is specifically planned. This includes, for example, the layout, architecture, technologies, and hardware for the project. How could this or that technology be vulnerable? Which security gaps are known? What measures can be taken against the identified risks? What risks arise from the planned architecture and how can they be avoided? How can the surface contribute to the security of the system? How can the system be hardened against attacks?


Now the technical implementation of the plans begins. The developers and hardware experts are now implementing the specified security measures in parallel to the regular requirements.

Even during development, standardized measures and tools can be used to check whether certain specifications from the security concept have been complied with. These can be automated tests, code reviews, or tools specifically related to security (e.g. tools that search the code for functions that have been classified as unsafe by default). Depending on the approach, testers can already participate and thus point out problems at an early stage.


The system was developed according to the specifications and can now be tested in detail. Testers check whether the specified security guidelines and measures have been complied with and whether the system is vulnerable. If they find deficiencies or security gaps, they document the incident and pass it on to development department. In the case of critical systems, it is advisable to have the integrity of the software checked by external penetration tests – sometimes even after delivery.

Delivery and maintenance

Before the software is available to the customer, a final review of all security activities from the previous phases should be carried out. If something has been forgotten at one point, the error now comes to light and can be corrected.

After delivery, the software finally goes into the maintenance phase. If errors or weak points are found in the system, these must now be corrected.