How to Develop Software That’s Secure by Design: 7 Steps to Follow

What makes a piece of software ‘high quality’? Some people might say it needs to have lots of features. Others may say it needs to be extremely reliable, something that never crashes. And others still might say all you need is a slick UI with satisfying animations. (Don’t let that third group near your dev team.)

‍

But for most people, ‘security’ isn’t usually the first answer that pops up in their heads. Security has always been relegated to stepchild status, an afterthought that’s bolted on to the end product to get it to pass some compliance regulations.

‍

In reality, an application that performs all its intended functions well cannot be considered ‘high-quality’ if it doesn’t also operate securely. Every microservice, every container, every last API can drastically affect how your application processes user data, opening up new channels for bad actors to sneak in and wreak havoc.

‍

How then, can security not be part of the ‘intended experience’? To quote this report by CISA, “Security is not a luxury option but is closer to the standard every customer should expect without negotiating or paying more.”

‍

To that end, a secure application isn’t one that has security features added to it at the end of the build, but one where the controls are baked into the product all the way from design and development, to deployment and production.

‍

Watch our webinar on-demand: “Leveraging SemGrep and Static Analysis for Paved Roads and Secure Defaults”.

‍

The Secure-by-Design philosophy

‍

A product that’s considered ‘secure by design’ is one where the security implementation is deeply enmeshed in the structure of the software, where a lot of planning went into finding and fixing vulnerabilities at the earliest possible stage. That could be performing a static analysis (SAST) scan before each build to check the source code, or analyzing the list of third party components for insecure libraries, or testing the app during runtime with DAST.

‍

Each of these confer their own benefits, but when these activities are performed as part of a CI/CD pipeline, where every step feeds into the next, the resulting stream of useful security data can not only make it easier for the developers to fix pressing security issues, but allow the security team to give actionable feedback.

‍

Over time, incremental improvements in the pipeline can make for serious gains in efficiency, improved documentation, and most importantly, a much more secure product.

‍

Secure-by-design is not to be confused with ‘Secure-by-default’, which refers to a product that is secure out of the box and doesn’t need to be configured by the customer. That means implementing controls like single sign-on (SSO), eliminating default passwords, etc.

‍

Let’s look at some secure software development practices as recommended by CISA.

‍

7 secure development practices for a Secure-by-Design product

‍

Conform to a secure SDLC framework

It’s hard enough to implement consistent security controls across your environment, but to do so without an established set of security guidelines? You’re doing a lot of extra work for no reason.

Identify a secure SDLC framework that lays the groundwork for you by showcasing secure development techniques, actionable inputs, and security best practices that your developers can follow. These need not be strict rules, but instead useful guardrails to help keep your team on track.
Manage your vulnerabilities

One of the most crucial parts of secure development is figuring out how to deal with vulnerabilities. Automated scans result in a ton of false positives. Some vulnerabilities may show up in the results, but be completely inaccessible to an outsider (and therefore, not dangerous).

If you failed the build every time any old vulnerability appeared, the developers will just get annoyed and quickly lose interest in doing anything security-related.

Use a vulnerability correlation/aggregation tool to take in all your scan data, where it will analyze each vulnerability, assign it a severity score, and prioritize them based on how serious they are.
Be careful using open source components

Third party components are a common and necessary part of building software products today. After all, when there’s libraries and databases for almost everything, why bother building them on your own from scratch?

But using third party software can introduce its own set of security risks. From nested dependencies having vulnerabilities you could never anticipate, to package managers installing wrong/malicious components, your software supply chain is fraught with danger.

Maintaining an up-to-date software bill of materials (SBOM) is imperative to performing source composition analysis (SCA), identifying insecure components, and updating/replacing old and outdated libraries.
Provide secure defaults for developers

There’s a concept called the ‘paved road’ in software security, which talks about creating a set of default security controls/protocols that are not only secure, but easy to adhere to.

You can’t expect developers to be experts on writing perfect, always-secure code. You also can’t just give them a laundry list of all the problems in the build and expect them to fix all of them with zero guidance. If they don’t know what to do, they’ll just choose the easy route — one that’s probably less secure.

Reduce the cognitive load on your developers by making the easy solution the secure solution. In other words, pave the road for them so it’s harder for them to choose the insecure option. For example, you could identify a set of well-maintained libraries you know to be secure, or offer tools and services that automatically lint the devs’ code within the IDE itself, so issues can be resolved super early.

If done right, secure defaults can help you eliminate entire classes of vulnerabilities, massively reducing the effort you’ll need to put into fixing bugs with each subsequent build or sprint.
Train your developers in security

Your engineering team doesn’t need to be the SEAL Team Six of security, but they ideally should be familiar with the broader principles and best practices of creating secure software. The best way to do that is through training that doesn’t just teach them, but engages them with hands-on learning.

AppSecEngineer has a massive library of courses, hands-on labs, and Challenges for every member of the product team, including developers. Our courses take them through real-world security scenarios where they have to compromise an insecure app, identify where the vulnerability lies, and fix the issue.

We even have language-specific Playgrounds where you have to find and fix bugs in apps written in Java, Python, Ruby, Go, and much more.
Create a threat model of your apps

Threat models are like a security blueprint for your software: they help you understand the structure of the application, how each part fits in with the whole, and where you can expect to see security threats emerge.

A high-level threat model can help you better design your apps, plan out security activities for each stage of development, and anticipate security risks before they even come to pass.
Implement Defense-in-Depth

One of the biggest advantages of containerized, microservices-driven software is how they all communicate with each other, without being completely dependent on one another. Design infrastructure so that even if a single security control is breached, it does not result in compromise of the entire system.

For example, ensuring that user privileges are narrowly provisioned, and access control lists are employed can reduce how much damage a compromised account can do. Additionally, software sandboxing techniques can quarantine a vulnerability to limit the compromise of an entire application.

‍

Watch our webinar on-demnad: “Leveraging SemGrep and Static Analysis for Paved Roads and Secure Defaults”.

‍

How to learn Secure-by-Design development

‍

A good place to start your secure-by-design journey is with the Secure By Design document by CISA, an in-depth exploration of secure development practices, pro-security business practices, and other useful suggestions on aligning your team and company towards a more security-centric approach.

‍

If you want to learn more about applying secure-by-design practices in your SDLC, you should check out our upcoming webinar: ““Leveraging SemGrep and Static Analysis for Paved Roads and Secure Defaults”. Here, AppSecEngineer CEO Abhay Bhargav looks at how Semgrep can help you establish secure coding practices and enforce policy compliance across your codebase.

‍

Over the course of 90 minutes, this live session will show you how to integrate static analysis seamlessly into your development workflow to enhance security and productivity. It’s free to attend, so tune in on 27th June, at 9AM PT!

Source for article

Aneesh Bhargav

Aneesh Bhargav is the Head of Content Strategy at AppSecEngineer. He has experience in creating long-form written content, copywriting, producing Youtube videos and promotional content. Aneesh has experience working in Application Security industry both as a writer and a marketer, and has hosted booths at globally recognized conferences like Black Hat. He has also assisted the lead trainer at a sold-out DevSecOps training at Black Hat. An avid reader and learner, Aneesh spends much of his time learning not just about the security industry, but the global economy, which directly informs his content strategy at AppSecEngineer. When he's not creating AppSec-related content, he's probably playing video games.