Shifting Left: How to Manage Your Open Source Components
A guest post by our sister company WhiteSource — a leader in the app security testing space.
Pushing solid products through the software development lifecycle while ensuring the highest quality standards can be a serious challenge for teams of any size. There is a great deal of value in using tools to automate our QA processes, cutting time at the end of the process, and picking up on those pesky bugs before the product makes it way out the door.
We understand all the advantages of the use of an automation test platform. However, we must take a step back to recognize there are opportunities to catch issues and vulnerabilities before they reach the QA step. We can do this by essentially shifting left our security checks to the earliest stages of the software development lifecycle (SDLC). Then, as you hit the QA stage it is imperative to continue shifting left. Your testing team can perform this by starting to test early in the SDLC.
Most of us are already familiar with the need to use tools like Static Application Security Testing (SAST) tools to check our proprietary code for potential vulnerabilities, but that only covers a piece of the pie.
Open source components comprise between 60–80% of the code base in modern applications. They contain the libraries and frameworks that are written and maintained by the open source community and are available for reuse by others in line with the licenses. Developers rely on open source without giving it a second thought because it’s cost-effective and efficient, helping them speed up the DevOps lifecycle. Open source also allows them to give their organization’s proprietary codes that extra bit of strength that they need to stand out in today’s marketplace without needing to reinvent the wheel for every single feature.
As this practice continues to grow, it’s important to pause and take a closer look at the processes and tools that we use when we work with open source software. Open source components are not like a proprietary code in how they are written and maintained, and therefore require a different kind of management. They present a challenge that must be managed using different tools which work according to other rules.
Every developer knows that open source components are ready and waiting for download on a number of online repositories like GitHub or Maven Central, but how many developers know the quality, security, or compliance levels of the open source code that they are using? Leaving those issues unattended in the early stages of production could end up costing much more when a product is already nearing its release.
Your open source security won’t manage itself
Security-wise, managing open source security could turn into a full-time job if you’re not familiar with the open source bazaar, sometimes lovingly referred to as the Wild West. Once discovered, open source vulnerabilities can be published across a number of security advisories and databases, rather than in one centralized location. Keeping track of all those known open source vulnerabilities is nearly impossible to carry out manually, especially at a large scale.
The next step is locating the patch, fix, or updated version for remediating the security vulnerability, and that too can turn into an endless task. That leaves us with one last, but in no way small, a task of combing through our code base for dependencies between vulnerable open source components and libraries.
When a security vulnerability is made public, it’s hunting season for hackers. That means we need to locate the risky open source component and all of its active dependencies as quickly as possible if we want to stay one step ahead of the exploits. Manual labor simply won’t cut it.
Automate your way through the open source bazaar
The only way to successfully ensure that you’re using open source without risking your company or your customer’s safety is to implement a DevSecOps approach to your open source management policy. Specifically, automating the open source management process from the earliest stages of the product lifecycle.
Using a Software Composition Analysis (SCA) tool that can automatically and continuously track your project’s open source components will save you, your stakeholders, and your team a lot of time and money as you race to release a new product or version.
An automated SCA tool will do the tedious heavy lifting, continuously tracking open source components in your code, matching them with an up-to-date database of open source vulnerabilities and fixes. The tool runs throughout the software development lifecycle, alerting admins when a vulnerable open source component is found, or even breaking the build to ensure a project’s safety, should a developer attempt to commit a vulnerable component hen provides actionable remediation suggestions for those pesky vulnerable components.
Stay calm and automate your open source management continuously
Open source gives us great opportunities to boost the pace of development, and focus on producing innovative products that make our customers happy in today’s competitive marketplace.
In order to stay on top of our game, we can’t ignore the fact that open source components require a different set of processes and tools than proprietary software. Investing in DevSecOps tools and policies without addressing the risks of open source components will only take us so far. If we really want to harness the power of open source, we need to manage it.
The best way to ensure we are one step ahead of the hackers and out of courtrooms without missing a beat is to incorporate automated tools that continuously track our open source usage and match them up against the most current data about open source components, their vulnerabilities, risks, fixes, and updates.
Originally published at www.testcraft.io on July 19, 2018.
