DevSecOps: How to Systematize Security into the Dev Pipeline Information Security Specialist

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 organizations:

Outdated and vulnerable libraries (SCA)

One of the biggest security problems that organizations 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 defenses 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 organization. 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.

There are several tools and services that can help automate security for you. OWASP Zed Attack Proxy (ZAP), a web proxy like Dependency-check, 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 minimize 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 organization 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.

Read More HERE