Every developer wants to create secure applications.
Unfortunately, there are always some limitations to developing secure applications. And since no one in DevOps seems to be able to wish a secure application into existence, they are stuck following a simple two-step process: first they have to develop something and then they have to evaluate it to see how secure it is.
It’s not a Matter of if but When
The only real choice a developer has is when to evaluate the security of their application. Here, they have essentially two choices: during or after development. Evaluating an application’s security post-development is done using pen testing. With pen testing, a different group of engineers, usually those with a particular expertise in security, and independent of the development team, attempt to find and exploit vulnerabilities in the application.
Evaluating an application’s security during development requires threat modeling. Threat modeling highlights vulnerabilities during application development. Threat modeling, in essence, turns DevOps into DevSecOps.
There is little disagreement, that all things being equal, it is better and less expensive to find security vulnerabilities during development than it is to fix them after it’s done. So, why do most organizations still rely on post-development pen tests? There are many reasons, and as things turn out, today most of those reasons no longer apply because threat modeling is now automated.
For years, it was widely believed that threat modeling, while improving application security, slowed down the development process. It kept development teams from launching the application and meeting their deadline. That’s no longer true. Automated threat modeling is now just another step in the CI/CD pipeline. Threat models are automatically built from code with the output pushed to Jira.
Another misconception about threat modeling is that it relies on expensive consultants with proprietary knowledge and tools. That was true, but not anymore. Today, automated threat modeling tools are self-service and template-driven with extensive component libraries. DevOps engineers, with only limited security experience, can create secure applications with the security team providing only governance and some guidance.
Automated and Collaborative Threat Modeling
Threat models are no longer the manually-intensive effort they used to be. Today, threat modeling tools proactively and automatically identify all threats and provide the relevant mitigation controls during the design phase. And they provide complete coverage across the entire tech stack (both application and infrastructure). It has evolved to the point where one click can automatically map, diagram and threat model the entire cloud environment.
More importantly, threat models are automatically updated in response to changes in the architecture. There is no longer any need to be constantly changing model inputs in response to continually changing cloud environments.
The reasons to not use threat modeling are gone. It comes down to a simple decision. Do you want to do DevOps and figure out security afterwards, or do you want to engage in true DevSecOps? Automated threat modeling is now an essential part of DevSecOps
Increasingly sophisticated and ever-changing cyber threats require a proactive approach to uncover security and compliance issues at the design phase across applications and cloud platforms. Threat modeling is the new best practice for SDLC and DevSecOps teams. If you are ready to take the first step to developing secure applications and cloud migration projects by design, then contact us to get started.