When DevOps met Security — DevSecOps in a nutshell

Sebastian Curland
Mar 12, 2018 · 5 min read

The Creation of Security 😆

One day, Alice and Bob were in the Garden of the Web. There were many trees in the garden but one was special. It was the Tree of Code. It had good O(1) code and malicious code. Alice and Bob executed the malicious code. Suddenly, the perfect web was not so perfect, it was full of vulnerabilities. From that moment Alice and Bob were not the same. No one recognized them. They were… Anonymous. And the web? The web was not secure anymore.

The DevOps Era

DevOps brought us new processes and tools that focused on testing and automation. And speed. Developers are now able to release new features and hotfixes to Production in a matter of minutes, and that, of course, after unit tests and the whole testing pyramid ran on the code, several times and in different environments before Production. With DevOps, developers can deliver continuously high quality applications that can be easily monitored and maintained.

Security — the missing link

Traditionally, security was involved only at the end of the development cycle. That is during the testing phase, the deployment phase or even after the application was already deployed. Either way finding a security vulnerability in those phases meant a delay in the release and a lot of pressure to patch the vulnerability if the code was already in Production.

The way we’ve traditionally approached security doesn’t scale in a DevOps world.

I found somewhere that the cost for fixing vulnerabilities is 30x higher after the application has been deployed. In reality that number can be even higher, like in the Equifax case where their shares went down ~14% in one day after they publicly announced a security breach.

Shift Security Left

Continuous Security

So, DevOps + Continuous Security = DevSecOps.
And with DevSecOps we can deliver secure software at DevOps speed.

DevSecOps in practice

Risk analysis and threat modeling during planning

Once you identify the potential threats, the second step in the threat modeling is to categorize the threats (models like STRIDE or Application Security Frame will help you in the categorization process) and give them a “security risk” value or rank (check the DREAD model for that).

The third step would be to define a mitigation plan for the threats found. In most cases the threats with the higher security risk will be mitigated first, although sometimes threats that have a lower risk but a high business impact will be handled first.

Security code reviews

Security code reviews are a powerful tool to find vulnerabilities early in the software development life cycle and they are a complement for the risk analysis and threat modeling. Static code analysis tools does not understand the context in the code and sometimes an additional pair of eyes on the code are the only way to have a security flawless application.

For the code reviewer is important to understand the business purpose of the application and the critical business impacts. As in the threat modeling phase, the reviewer should be familiar with the entry points of the application and think how the application can be potentially attacked. In order to do a productive code review, the reviewer should be also familiar with the (sensitive) data that is being exposed and with the user roles and access rights of the application.

A security code review should be focused on the following areas:

  • Data Validation
  • Authentication
  • Session Management
  • Authorization
  • Cryptography
  • Error Handling
  • Logging
  • Configurations
  • Network Architecture

Static code analysis

Some tools can be integrated into the IDE so the developer will get live alerts while writing the code. Other tools can be integrated in CI build systems like Jenkins, so the code will be analyzed during the build phase.

Some examples of Open Source static code analysis tools are SonarQube and the security plugin of ESLint (for Javascript).

Dependencies analysis

The security of your application is only as strong as the weakest link in your dependencies

Most of the the code that you’ll have in your application will come from third-party dependencies. When we find a dependency that does what we need we feel excited that we saved time writing that code and we blindly trust that piece of code as if it were ours. But unfortunately if that dependency has vulnerabilities our application will be exposed and vulnerable as well.

Tools like OWASP Dependency Check and Snyk can help you find vulnerabilities in your dependencies and you should integrate them during a pre-commit stage, before your code is merged into the “master” branch.

In my next blog posts I’ll deep dive into DevSecOps practices and how to implement them. Stay tuned!

Follow me on twitter @sebcurland


A publication by the Nielsen Marketing Cloud Engineering team, where we talk about what we do and how we do things

Sebastian Curland

Written by

Senior full-stack developer and security champion at the Nielsen Marketing Cloud.


A publication by the Nielsen Marketing Cloud Engineering team, where we talk about what we do and how we do things