When DevOps met Security — DevSecOps in a nutshell

The Creation of Security 😆

In the beginning there was only Waterfall and chaos. But then Agile was created and with it new processes and tools rose from the ashes. DevOps, Continuous Integration, Continuous Delivery, Continuous Deployment, Automation, Alice and Bob. Everything was beauty and perfection. Almost.

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

With the move from Waterfall to Agile development methodology, the development teams moved from long development cycles to short sprints that helped to reduce the time to market. But that was not possible without DevOps.

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

Ok, high quality applications delivered fast, but no one said secure applications.

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

Shift Left model means to put efforts in finding security vulnerabilities during the first phases of the development cycle, during planning, design and coding. It also means educating and guiding developers on security coding practices and help them to test for security during the coding phase.

Continuous Security

The shift left model together with DevOps creates a new world of possibilities where security is integrated in all parts of the DevOps cycle.

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

DevSecOps in practice

The following is a list of real things that you can do in order to secure the DevOps pipeline.

Risk analysis and threat modeling during planning

Risk analysis and threat modeling can help develop applications that are secure from the very beginning. The first step in the threat modeling process is to understand the application or the features that will be developed. You need to understand how the application will be used, what are the entry points that can be used by potential attackers, which data will be exposed and what are the permissions required for the new code.

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

I’m almost certain that every developer heard about code reviews and hopefully many of them are doing it. But how many heard about 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

The purpose of static code analysis tools is to find vulnerabilities by scanning the source code (‘static’ code) of your application during the development phase. This kind of tools are good in finding vulnerabilities that have a certain pattern, like SQL Injections, malicious regular expressions, buffer overflow, etc. In the other hand, static code analysis tools will often produce false positives — vulnerabilities that in fact are not.

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