From the course: DevSecOps: Building a Secure Continuous Delivery Pipeline

Secure development practices

From the course: DevSecOps: Building a Secure Continuous Delivery Pipeline

Start my 1-month free trial

Secure development practices

“

- [Instructor] Let's talk secure development. This is a really big topic as the develop stage encapsulates all the efforts from design to code commit. In some organizations and products, this stage might consist of hundreds of developers working with a multitude of tools to complete this stage. For others, it might just be one or two people. For our purposes, we're going to look at three key security practices in this stage of the pipeline. They are threat modeling, development standards, and static code analysis. We'll discuss these now and then we'll look at some tooling to address each one of these in following videos. First up is threat modeling. Threat modeling models an application or system and looks for vulnerabilities. This is often done by taking a data flow diagram and then mapping the elements using Stride. Stride is a pneumonic developed by Microsoft. In the process of threat modeling, you might ask, can this element or flow be spoofed? Could it be tampered? Are we open to repudiation, which is where a user denies their actions, such as a purchase or other transaction? Is there a chance of information disclosure or a data leak? Could we be under a denial of service scenario? Or can a user elevate privileges in this process? Threat modeling can be an excellent practice for developers. But it's a slow process that works best when the underlying model of the system doesn't change much. This is definitely a problem in the modern landscape of agile software development where everything changes all the time. To address this, there's been a rise in threat modeling that works with agile development. There are a few approaches I recommend, the OWASP App Threat Modeling Cheat Sheet, the OWASP App Sec Verification Standard, and the Mozilla Rapid Risk Assessment. To see this in action, we'll take a deeper look at the Mozilla Rapid Risk Assessment in a later video. For now, let's move on to our second secure development practice, development standards. Many development organizations have team coding standards. For example, the standards might look something like, 80% of the code will have unit tests. Or a particular list of functions are banned. At work, we enforce limiting and formatting, as well, so that everyone on the team is writing code that is readable and understandable by everyone else. Security can fit in here too by specifying tools that look for secrets that have been accidentally put into the code. Two great options are git-secrets and git-hound. We'll look at how to use git-secrets in an upcoming video. One final key practice we haven't talked about yet is static code analysis. Let's dive into that next.

Contents