Implementing a secure by design approach in software development teams

This article identifies four recommendations that are important for organisations aiming to implement a secure by design approach in their software development lifecycle (SDLC): 

• Nurture a strong security culture across your organisation 

• Build your security maturity over time and measure your effectiveness using offensive security testing 

• Build a community of security champions to amplify the effect of your security team 

• Use threat modelling to build understanding of the threats to your applications and their mitigations 

The importance of security culture 

Maybe the most important part of a secure by design approach is to focus on nurturing a culture where application builders want to deliver good security simply because it is the right thing to do.  

The security team needs to work carefully and continually to support this culture. We can’t behave like gatekeepers (although that is sometimes needed). Instead, we must make sure we are part of the solution building team.  

This is not always easy to achieve but a key success factor is the hiring process. When hiring into the security team, put as much emphasis on interpersonal skills as on security knowledge. Obviously, this makes an already difficult hiring process even harder, but the mindset and approach of the security team can make or break the security culture. It is better to be flexible on location, experience, qualifications and technical background than on the competencies needed to work well with people. 

Building maturity and measuring effectiveness 

There are many activities that application teams can do to strengthen their security approach, so it is important to adopt an approach of:  

• Continuously building security over time in a structured way 

• Measuring progress and effectiveness 

This continuous improvement approach is often based on a maturity model. Two popular maturity models for application security are BSIMM (the Building Security in Maturity Model) and OWASP SAMM (Software Assurance Maturity Model). Both recommend activities covering different aspects of software development lifecycle, divided into 3 maturity levels. 

All these activities are inputs to an SDLC. The desired output is that teams build applications with fewer and less severe vulnerabilities. This output is best measures by offensive security testing, where testers search for vulnerabilities using a range of tools and techniques. Offensive security can be broadly divided into three forms: 

• Application penetration testing 

• Bug bounty programs 

• Red team exercises 

Each of these forms has different strengths and weaknesses, depending on the nature and maturity of application being tested. 

Security champions 

One of the most popular measures identified in both BSIMM and OWASP SAMM is to establish security champions. At version 10 of BSIMM, it was reported that 86% of the top 35 BSIMM organisations have security champions.  

Security champions are a community of people embedded in application teams. They are not full-time security professionals, but they have a strong interest in and passion for security which they channel to help build the security capability of their teams. It is important to support and develop security champions though specialised training and knowledge sharing events. In return, they act as an important force multiplier for the security team, promoting and leading a wide variety of security activities and (if needed) standing up for security when prioritising work items for their teams. 

Threat modelling 

One of the most foundational activities for security by design is threat modelling. This is a structured approach to help application teams think about how their applications might be attacked and then design ways to mitigate these attacks. 

There are several ways of doing threat modelling but generally it has three stages: 

• Decomposing an application into its component parts, usually using a diagram. 

• Identifying threats by asking questions about the decomposed application to try to guess how someone might attack it. 

• Designing mitigations to block, avoid or minimise the threats. 

Threat modelling is foundational because it forces application builders to think hard about the security of their applications. This drives a deep understanding of why different security mitigations are needed. Also, it is fundamentally a team activity: The best threat modelling sessions include people from all aspects of an application team so that different people get exposed to security thinking and can contribute meaningfully to it.  

You can read all our other guest blogs throughout the week here.