What is the SDLC, and why should you care?

What is the SDLC, and why should you care?

Security plays an important role in software and should therefore be considered 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, practically 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 be spent on tests and security concepts.

Nowadays, things have to go faster in many cases: changes should reach the customer in some cases every few weeks. In practice, the focus is often 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 hardly visible at first glance. If these points are the last in the development process, they are sometimes overly neglected. Especially when the release cycles are short, tasks without tangible results are dropped first.

So, it makes sense to include the topic of safety 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.

SDLC in a nutshell

The Software Development Life Cycle, SDLC for short, describes the life cycle of a software product from creation to the cessation of all activities. Software engineers like to use the formula “from the cradle to the grave” based on human genesis.

Software engineering is responsible for software production. This process includes the conception, development, and commissioning of software products.

Complex software applications place high demands on development and support. An essential basic requirement for the production of a solution-oriented, practical application is the division of labor. That is why experts from different disciplines are involved in the creation process. Experienced specialists from the departments of research, development, product documentation, marketing, sales, and product service make significant contributions to the value chain.

The acronym SDLC traditionally stands for Systems Development Life Cycle. Such a system is established to be able to build, expand, and operating systems properly. Through the various phases of the cycle, optimizations in terms of efficiency and reliability should be achieved and maintained. At the same time, however, it also creates the possibility of consistently introducing security. This article discusses the principle of the Security Development Lifecycle, which focuses on the security aspects of corresponding solutions.

SDLC is a cycle that consists of the following four repeating phases:

  1. Planning
  2. Analysis
  3. Design
  4. Implementation

The cycle means that after maintenance, planning for the next iteration always takes place. With SDLC, a classic principle of information security is considered, which was constantly preached by the American cryptologist Bruce Schneier:

Security is a process, not a condition.

Indeed, one cannot simply create security and expect it from then on after it has been achieved. Internal and external influences can make it necessary that security must be constantly achieved and managed.

Security development lifecycle

The Security Development Lifecycle is intended to help plan, implement, and manage systems in a comprehensible and secure manner. For this purpose, the following seven phases are established (based on the approach propagated by Microsoft):

  1. Training
  2. Conditions
  3. Design
  4. Implementation
  5. Examination
  6. Publication
  7. Reaction

It can be seen that the original phases of the classic SDLC can be found here. However, these are expanded with a focus on security.

Design and implementation requirements

The security development lifecycle is all about security requirements. In phase 2, these requirements are determined. Questions are answered, such as:

1 Which user groups should be able to access components? 

2 How should the authentication take place? For example, strict authentication (username, password, etc.)

3 What are the availability requirements? 

Design, these loose requirements are then incorporated into the concrete design for the solution. For example, question 1 requires a role and authorization concept, question 2 requires an access and authentication concept and question 3 has to deal with availability, backup/restore, and business continuity management (BCM).

 Implementation. Thus step in the project deals with implementation across departments. This phase is determined by software development, documentation, and application-oriented implementation. The tangible results include the documentation required for the life cycle of a new software product: accompanying manuals for installation, administrative matters, and an operating manual. The definition of needs-based test scenarios and acceptance procedures also takes place in the implementation phase.


The Security Development Lifecycle introduces an important tool so that security requirements are not only discussed but are implemented. This step verifies whether the previously defined and implemented security mechanisms have been implemented. The postulations from the previous phases are compared with the current status and deviations are documented. The classic tools of security testing are ideal for this. For example:

  1. Source code analysis
  2. Reverse engineering
  3. Vulnerability scanning
  4. Penetration testing
  5. Config Reviews
  6. Firewall Rule Reviews
  7. Concept review

There is no general definition of which approach and to what extent testing should be carried out. The aim of every analysis should be the standardization of reliability and economic efficiency. If, for example, the source code of a solution is available, it is preferable to analyze it. If not, more time-consuming reverse engineering can be used or dynamic tests (e.g. vulnerability scanning and penetration testing) can be used.

It is essential to understand that each test mechanism has different requirements and can guarantee coverage. Limiting verification to a source code analysis is just as dangerous as relying only on a network-based vulnerability scan. Technical understanding and experience are required here.

End of life

As was clearly shown here, the SDLC describes the complete life cycle of a software product. But when is the end near? The answer is technological progress. Software programs are among those technology products that work when embedded in technologically demanding environments.

This fact suggests that the product life cycle largely depends on the technology life cycle. In the course of the introduction of new technologies, further developments are required as a minimum, which builds on the existing. If a product proves to be no longer viable, the end of its life cycle has been reached. It will be withdrawn from the market.

Patches, releases, and vulnerabilities

Security adjustments may be necessary both in the verification phase and during the management of the established solution. This happens for two reasons:

External influences: New attack scenarios become relevant (e.g. new attack techniques, business processes, workflows).

Internal influences: New functions are required; existing processes are adapted or weak points are found in the given solution.

To be able to perceive these influences and react promptly to them, the threat situation must be reassessed at regular intervals as part of risk management. The market for attack tools (techniques, tools, and exploits) needs to be monitored and relevant changes are taken into account.

Vulnerability Management is responsible for recognizing, documenting, and considering weaknesses in the products. On the one hand, various sources are managed here (e.g. vulnerability databases, mailing lists, social media) to be able to identify newly published vulnerabilities as early as possible. On the other hand, active programs such as bug bounties can be launched with additional effort. The reporting of newly found vulnerabilities by third parties is rewarded, which creates a dialogue and reduces the time window for abuse.

The patch and release management are also responsible for ensuring that addressed vulnerabilities can be eliminated through bug fixes and new versions. The preparation, testing, rollout, and verification of these optimizations must also be done professionally.

The Security Development Lifecycle is a powerful tool with which security can be established. By accompanying the life cycle of a product from the start with consideration of the safety requirements, a good level can be achieved and maintained and this can also be checked.

There is no question that this level of professionalization belongs today. Without SDLC, the security of a solution is primarily based on luck. And time works consistently to ensure that this runs out at some point.