Multi Cloud
DevSecOps: How to Systematize Security into the Dev Pipeline
Security within an organization cannot be siloed or left up for DevOps teams to figure out and manage. Learn how applying DevSecOps best practices will have a noticeable positive impact on the security of your overall applications.
Lately, we’ve been hearing a lot about Dev Ops and DevSecOps, and why they’re so important. While integrating these are considered very good practices, organisations may be unintentionally unaware of how to maximise DevOps to ensure security and compliance are being met without delays. This could be because many researchers and authors believe DevOps already includes security at its core, since software security and quality are closely related. However, in today’s cloud environment, one cannot assume that DevOps can do it all. That’s where a strong DevSecOps strategy and mindset comes into play…
DevOps vs DevSecOps
To put it simply, DevOps is a range of tools and unique cultural philosophies that focuses on helping organisations streamline software or application release cycles to further improve their quality, security, and scalability. This concept was introduced in 2008, and since then, much has changed.
Due to the rise of agile cloud computing platforms, deployment cycles have increased in speed and frequency, therefore leaving security until the end of the pipeline is no longer effective nor efficient.
In response to the changing security landscape and ensure best practices, a new term was created. Initially called Rugged DevOps, it morphed to SecDevOps then to DevOpsSec and now, DevSecOps. You may have also heard Agile Security, Agile SDLC, or DevOps Security. No matter what you call it, the meaning remains the same. DevSecOps is meant to emphasise the need to build security into the foundation of DevOps projects.
In order to meet the business’ need for rapid-fire deployment, security must not lag behind and cause delays. Generally, security testing is performed at the end of the application development process, which increases the risks of deployment delays and project costs, especially if vulnerabilities that require recoding or redesign are found.
DevSecOps means considering application and infrastructure security from the very start without slowing down DevOps workflow. This DevSecOps strategy is often referred to asa “shift-left” security approach, which according to Accenture and Amazon Web Services (AWS), “introduces security at the inception of the development lifecycle and automates testing within the DevOps workflow.” Automating security verifications and checks within the development process helps reduce the vulnerabilities found before launching into production
Definition of DevSecOps:
“DevSecOps can be depicted graphically as the rapid and agile iteration from development (the left side of Figure 1) into operations (the right side of Figure 1), with continuous monitoring and analytics at the core. Our goal as information security architects must be to automatically incorporate security controls without manual configuration throughout this cycle in a way that is as transparent as possible to DevOps teams and doesn't impede DevOps agility, but fulfils our legal and regulatory compliance requirements as well as manages risk.” Gartner - DevSecOps: How to Seamlessly Integrate Security Into DevOps
Figure 1 - DevSecOps - Source: Gartner (September 2016)
Before we take a dive into DevSecOps best practices, let’s take a look at one of the most common security grips for developers that impact organisations:
Outdated and vulnerable libraries (SCA)
One of the biggest security problems that organisations face is knowing what’s exactly inside their applications and how to properly and securely patch it.
Remember the damage that was caused by Wannacry in 2017? It exploited a vulnerability which was fixed three months before the attack was launched. In the same year, Equifax was also breached in another big attack because of an outdated and vulnerable version of the Apache Struts library, which allowed the execution of remote commands on their systems.
Nowadays it is very rare for a developer to write code from scratch, meaning without using any frameworks or libraries. This has led to 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. Using components with known vulnerabilities is considered one of The OWASP Top 10 web application security risks.
"Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defences and enable various attacks and impacts."
How DevSecOps can Prevent Common Vulnerabilities
Go beyond the CVE Program
You can search the Common Vulnerabilities and Exposures (CVE) system or NIST Vulnerability Database, but you may not be seeing the entire picture. This is because information on open-source vulnerabilities is distributed by a multitude of sources, so it’s very hard to track it. These resources are certainly still handy, but there’s nothing wrong with using some back up to make sure your code is as secure as possible.
You can take matters into your own hands and try to inventory components to check for vulnerabilities, but this doesn’t scale well, and it isn’t cost-effective for the organisation. Plus, it doesn’t sound all that exciting for you, does it?
There are many tools out there that check for outdated software on servers and even update those for you in many different languages and frameworks. Some of them can even be integrated in your integrated development environment and can check and fix these issues before submitting any new code.
But these tools may not work because of the incompatibility issues with legacy applications and the lack of proper regression testing to make sure everything is working properly once the updates are made. It becomes even harder when the outdated library is embedded in a custom or in-house application.
All hope it not lost. OWASP has a great, easy-to-use, free tool available for Java and.NET libraries called OWASP Dependency-Check, which also has plugins for continuous integration (CI) tools like Jenkins. Other commercial tools that can help you in this process are Snyk, WhiteSource, Synopsis BlackDuck, Veracode SCA, Conviso AppSec Flow, and Sonatype Nexus IQ Server.
Pssst—Trend Micro and Snyk have partnered to create Trend Micro Cloud One™ – Open Source Security by Snyk, the newest Trend Micro Cloud One™ solution that addresses your open source package vulnerabilities lurking in your code source repository (such as GitHub, GitLab, and Atlassian).
Automated security scans (DAST)
You have a need for speed that cannot be compromised by security. Right now, security scans are mostly performed at the end of the application development process, usually after the application is complete and properly working at least on a Dev or quality assurance (QA) environment. That means any issues later found would either need a system update of some kind or recode to fix the application.
DevSecOps makes sure you can sprint toward deployment with the best security posture thanks to automation. By incorporating automated security scans early in the development cycle, you can ensure you’re meeting security and compliance needs while building as lightning speed. CISOs will thank you as well, because automation pays off; 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.
Some several tools and services can help automate security for you. For example, OWASP Zed Attack Proxy (ZAP), which is a free and open source web proxy and like Dependency Check, it also has a Jenkins plugin to integrate your security scans in the build process. Other tools that can help you in this process are w3af, Arachni, BurpSuite Enterprise, Acunetix, Netsparker, WebInspect, AppScan, Conviso AppSec Flow, and Veracode.
Trend Micro Cloud One™ – Application Security can also help to minimise design and deployment risks thanks to runtime self-protection technology. It only takes 2 minutes to install and doesn’t require any additional code changes or rules to set up. See for yourself with our free 30-day trial.
Security code reviews (SAST)
Code reviews and refactoring have been in place for a long time, but they mostly focus on code quality and performance, whereas 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 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 source code management (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 changes. It will also give your developers fast feedback about the mistakes being made and how to avoid them.
Some tools to help in this process are: Checkmarx, Fortify, HuskyCI, Horusec, AppScan, SonarQube, Conviso AppSec Flow, and many others. Please check out this detailed list of Source Code Analysis tools by OWASP for more options.
Conclusion: Team work makes dream-work
Security within an organisation cannot be siloed or left up for DevOps teams to figure out and manage—they are not security experts.
DevSecOps is based on the shared responsibility model, meaning security is everyone’s responsibility. A successful DevSecOps culture builds security in the DevOps processes and encourages collaboration amongst developers and security teams.
The security team has to understand how the development flow works and provide support via expertise and proper tools, without adding new barriers. Security teams should suggest alternatives, instead of leaving it up to DevOps, that use security verifications and checks within developer-friendly tools like IDE, CI/CD, SCM or Application Lifecycle Management (ALM).
Automating security processes helps both teams out. Now, the security team can focus on more manual testing and other issues, while developers can receive fast feedback about the security of their applications and take necessary remediation steps.
Effectively applying DevSecOps best practices will have a noticeable positive impact on the security of your overall applications. Remember what matters to the business and try to balance security with new features.
