Developing Secure Software - Challenging but Possible

Developing secure software is challenging, but not impossible. I wrote about threat modeling which helps to eliminate security vulnerabilities in the design phase. Identifying and addressing the biggest threats early is essential. But how about other important activities such as security testing or code reviews? There is a need to integrate security into the software development lifecycle. Our preferred solution is SDL.

Security Development Lifecycle

Security Development Lifecycle (SDL) is a software development process - or set of practices - that helps to build more secure software. Microsoft’s SDL is a well-known process definition used by many organizations. It currently contains 17 practices, which may sound like a lot of work. In fact, implementing full SDL at once is not an option for many organizations. Good news is that you can start with the essential practices and improve along the way.

When organizations start talking about SDL implementation, they face a number of questions. Most common ones:

  1. What is the cost?  You need to justify the need for security spending. 

    Justifying the cost for more secure software should be a no-brainer. The cost to prevent a data breach or a serious security vulnerability far outweighs the cost to recover from a successful cyberattack. 
  2. Do we need change our organization because of SDL?

    No. You can and probably should integrate SDL into existing development processes.
  3. Do we need change our organization because of SDL?

    Most likely not. SDL may require new job roles, but those are usually not full-time positions.

Case study: Light-weight agile SDL

Implementing SDL into existing organization and processes can be challenging. Here is one real-life example of planning and implementing SDL. Our task was to plan and implement SDL for an agile software product team. They had no previous experience of SDL, but they were familiar with secure design, coding and testing. We defined a minimum set of SDL practices together with the product owner and project manager.

Initial SDL definition (modified from Microsoft’s agile SDL):

SDL definition

  • One-time practices are done once per software release (new version)
  • Per-bucket practices: tasks must be completed on regular basis but can be spread across multiple sprints.
  • Per sprint: these tasks are done in every sprint.

We went through all practices during a SDL trial phase with the following results:

  1. Core security training. In this project, we decided that this task includes the SDL training.
  2. Establish security requirements. This step is mostly about assigning security experts and deploying a security vulnerability tracking system. Most of this was already covered. The project team wanted to use this step to nominate a SDL Lead for each release. SDL Lead, typically the project manager, is responsible for making sure all the SDL steps are carried out.
  3. Perform security and privacy risk assessments. This is a key practice for planning and deciding the SDL work for each software release. During this activity, we look at all the new planned features and determine if threat modeling or security testing is required.
  4. Establish design requirements. Validating all design specifications against functional specifications was already an established practice. After reviewing the practice, we removed this step from the SDL definition.
  5. Perform attack surface analysis reduction. Again, we learned that this activity was an established practice. However, this was not documented so it stayed as part of the SDL.
  6. Use threat modeling. Threat model is created or updated depending on step 3.
  7. Perform static analysis. The Continuous Integration practice already included an automated static analysis tool and reporting. We fine-tuned the quality criteria (“bug bar”) and added static analysis for the installation scripts.
  8. Security testing. This team was already familiar with security testing, but there was room for improvement. We introduced threat-model driven security testing. Furthermore, we introduced new testing methodologies like fuzzing and code reviews. Note that security testing often requires expert support. The team implementing SDL does not necessarily have the required expertize. Many organizations have outsourced the actual security testing.
  9. Conduct attack surface review. We decided that this practice is part of the threat modeling, because the attack surface was known and relatively small.
  10. Create an incident response plan. This already established practice required only fine-tuning (see step 13).
  11. Final security review. Review of all planned and performed security activities helps to ensure software release readiness. This step also includes a business decision on potential residual risk. For example, if the threat model includes security requirements that have not been implemented yet, the review team needs to make a decision on whether the release can be approved or not.
  12. Release and archive. This already established practice required some fine-tuning. Archiving should include all specifications, source code, binaries, threat models, documentation etc. This is essential for performing post-release servicing tasks.
  13. Execute incident response plan. The organization already had an incident response and support teams. We tested the incident response readiness and made some improvements.

One important part of SDL implementation is evidence of activities. This is why it is important to go through the steps carefully including the already established practices. The technical format of the evidence is not important. There is no need to introduce new document templates or separate evidence tracking. Evidence can be stored using existing systems such as wiki-pages or version control as long as they can be easily found.

When the development team started to use SDL, there was only two new practices. Some established practices were fine-tuned during the trial phase. After couple of release rounds, the team was quite happy about the end-result. Introduction of SDL was not overwhelming, and it provided structure and visibility to security engineering. The security posture of the development team and product clearly improved.

Optimizing SDL

The example SDL was implemented for a mid-sized development organization working on a stable product. Smaller organizations may benefit from a more optimized SDL. Remember that main driver for implementing SDL is making more secure software, not the process itself. Process is just a tool: think of it as set of important activities. Implement the ones that are crucial to your business and product.

Here is one possible agile SDL model for a software product, project or service. The idea is to build the SDL around threat modeling and product backlog. In this example, we assume threat modeling is already used.

SDL model

  1. Roadmap or release plan. Contains information about planned new features and changes, which will end up in product backlog. If a planned feature or change has security implications, add a backlog item to update the threat model.
  2. Threat modeling may introduce new requirements or tasks such as security testing. Add those to product backlog.

Threat modeling may also produce new items to the roadmap. For example, if a security requirement leads to architectural changes, add it to the product roadmap.

This kind of simple SDL model might be useful. Once it is in use, adding new SDL practices is not that complicated. For example, you could implement incident response to existing bug tracking system.


This article is a brief description of SDL and related practices. We will discuss these topics in future posts. 

Further reading:

You can also contact us if you need any help with SDL or with security testing.