What Secure by Design means for software development teams
So, you’ve read the first blog post in our series, about the global move to make software more secure — huzzah! We're diving into the second one here. Keen to read the third (and last) one too?
The Secure by Design approach features heavily in the guide the Australian government put out together with international government agencies and partners. But what is Secure by Design, and how does this shift in mindset impact your work as a software developer or team lead? Let’s dive in.
What is Secure by Design?
The idea of Secure by Design applies to the secure development lifecycle, which is a framework to layer people, processes, and technology throughout a software development lifecycle (also known as an SDLC) with the goal of building software securely.
One of the first publicly shared secure development lifecycle frameworks was released by Microsoft back in the 2000s, and was focused on finding and fixing software security flaws throughout a typical software project. Much of this work was made available to everyone as part of the Microsoft Security Development Lifecycle.
Over time, both software development methodologies and means of securing software have evolved. These days, many teams use agile software development approaches, which means they have to put security in place in very different ways, and often while moving much more quickly.
Whether your organization uses agile or other methodologies, there are common themes in most secure development frameworks, including:
Defined responsibilities for software and product security
Security training
Security architecture and design requirements or patterns
Security risk assessment, or threat modeling
Security automation technology, like static application security testing tools
Security testing, such as penetration testing
Security operations
There’s also the Secure Software Development Framework (SSDF - NIST 800-218), which teams can use to be more effective at finding and removing vulnerabilities in software they’ve already released. This approach mitigates the potential impact of those vulnerabilities being exploited, and addresses the root causes of them so they don’t happen again. The best way to put this into practice is through a written roadmap that outlines how Secure by Design software development practices are being adopted across your business.
Don’t be put off by the formality of this and other NIST resources. If you’re willing to spend a bit of time with them, they can be a great way to think not only about common software vulnerabilities and weaknesses, but also what structures you need to avoid them.
How to create a Secure by Design roadmap
There are many approaches to SSDF, ranging from the comprehensive government level frameworks like NIST 800-218 as mentioned above, or more community-driven options like the OWASP SAMM project.
Whichever framework you choose, the first step is doing an assessment of where you are right now. Our blog post about lifecycle security maturity will help you do that — have a read, give it a go, and let us know how you get on.
Once you’ve done that assessment, the next step is creating a roadmap. This is a tailored plan of how you can get from where you are to where you need to be. While this journey looks different for everyone, the speed at which you want to travel and your intended final destination will be your guides when it come to working out how many people and how much money it will take to get you there.