DevSecOps - Integrating Security in the Development ProcessTuesday, April 24, 2018
What are the practical benefits of DevSecOps in application security and how can organizations leverage them?
DevOps demands a change of culture in organizations which aren’t prepared or don’t want to change themselves. Using tools and automation is not enough to achieve that culture change. Also, many researchers and authors believe that DevOps itself already includes Security and although they may be right, since Security is closely related to Software Quality, that's not the case on most of the companies adopting it. Many are applying DevOps without thinking about security. Hence a new term was created, first called Rugged DevOps, or SecDevOps, or DevOpsSec and lately DevSecOps. The goal is to raise awareness to the need for security in this shifting culture using the agile and automation mindset. It is an evolution to DevOps to make sure that security teams stop being the barrier or the bottleneck of new software and functionalities.
DevSecOps is changing the Security Industry by integrating security verifications and checks within development process and reducing the vulnerabilities found before launching into production. According to a Gartner study, until 2019, more than 50% of DevOps' enterprise initiatives will have embedded application security tests for internally generated code, compared to less than 10% in 2016.
Currently, security testing is generally performed at the end of the application development process, which increases the risk of software deployment delays and also project costs if vulnerabilities that require recoding or redesign are found. Companies can overcome this problem by using the "Shift Security Left" (SSL) methodology, which basically says to introduce security verifications and validations in the software development lifecycle and performs automated security testing within the project workflow. Please don’t confuse that approach with SSL/TLS encryption protocols. Let’s discuss some of these practices and how you can apply them in your software development scenario.
DevSecOps - Source: Gartner (September 2016)
Outdated and vulnerable libraries
One of the biggest problems related to security that organizations face is patch management. We can all remember the damage that was caused by Wannacry last year, that exploited a vulnerability which was fixed three months before the attack was launched.
Nowadays it is very rare for a developer to write code from scratch, meaning without using any frameworks or libraries. And that also has become a big problem on applications since most of the code being used comes from third-party and is rarely verified or tested for security issues. Recent studies have shown that more than 90% of applications are made up of open source and that 70% of those are outdated or have a public available vulnerability. The OWASP Top 10 2017 addresses this issue in its A9 - Using Components with Known Vulnerabilities.
A great example of this issue is WordPress, a famous CMS system that has a strong and well-tested core nowadays, but its themes and plugins are very problematic and unreliable since they are developed by third party that doesn’t always follow the same security procedures and verifications.
Another big attack that was news all over the world was the Equifax data breach. Which happened because an outdated and vulnerable version of Apache Struts was running and it allowed the execution of remote commands on the system.
There are many tools out there that check for outdated software on servers and even update those for you. But that’s not an easy process because of incompatibility issues with legacy applications. That becomes even harder when the outdated library is embedded in a custom or in-house application and the tools mentioned earlier won’t work on them. So, what can be done is to verify for these issues before the application is even built, generally during the development phase or during pre-build tasks.
There are many tools available that will perform those tasks for you in many different languages and frameworks, some of them can even be integrated in your developers’ IDE and they check and fix these issues before submitting any new code. OWASP has a great free tool available for Java and .NET libraries called OWASP Dependency Check, which also has plugins for CI tools like Jenkins.
Automated security scans
As we mentioned before security scans are mostly performed in the end of the application development process, usually after the application has been done and it is properly working at least on a Development or QA environment. So any flaws or vulnerabilities found would either need a system update of some kind or recode of the application to fix it. It has been proven on many occasions that fixing bugs earlier in the development lifecycle is much cheaper and faster than after the application is in production. So why not run our security scans as soon as possible to find the problems at an earlier stage?
With virtualization and containers it has become easier to create and destroy machines for testing or proof-of-concept purposes. Security teams can use those techniques to create temporary servers to be tested with the new updates as soon as possible and make sure their applications still work. You can also integrate security testing in the build process, so every time a build is generated and all those Q&A testing is done, some security testing is also performed, giving fast feedback for the developers to fix it. Another great tool from OWASP is OWASP ZAP, which is a web proxy, and like Dependency Check it also has a Jenkins plugin to integrate your security scans in the build process.
Security code reviews
Code reviews and refactoring have been in place for a long time, but mostly focusing on code quality and performance. Security code reviews focus on vulnerabilities and security issues, regardless of how the code has been written. Although there are many tools available already, there are also many different languages and also false positives to deal with. In the DevSecOps mindset code reviews should be done at each commit, preferably automated since the objective is to commit small pieces of code many times a day or a week, to make sure that if something happens, it would be easier to debug and fix. In that case you can integrate your security code review tool with your SCM and create alerts or even triggers that execute a scan in your source code every time there is a commit to your SCM.
Performing those checks frequently will significantly reduce the amount of vulnerabilities in your software after deployment that would need any code change. It will also give your developers fast feedback about the mistakes they are making and how to avoid them.
Developers are not security experts, they rarely hear or learn about security during their learning, so don’t expect them to understand and fix all the security issues at once. This process takes time and requires training. The security team has to understand how the development flow works and try to include security in a way that it is transparent and fluent, without adding new barriers. Try to use security verifications and checks inside already well-known tools like IDE, CI/CD, SCM or ALM tools using add-ons or plugins.
Applying those three practices effectively will have a huge impact on the security of your overall applications. Make sure you automate those tasks as much as possible so that your security team can focus more on manual testing and other issues and the developers can have a fast feedback about the security of their applications to take action. Remember what matters to the business and try to balance security with new features. Take the first step to DevSecOps by trying our free application Discovery service and make sure you have a comprehensive inventory of your external applications.