Third-Party Component Security: The Good, The Not So Good and the Downright Ugly

Third-party components, open-source in particular, are an essential part of modern development efforts. Those components accelerate development and help your team to retain focus on developing core technology code.

That’s good.

The challenge with adopting third-party components is that the behavioral and security issues of the components are adopted as well.
​

Behavioral issues are normally discovered quickly: as component functions are used, any failure or unexpected results are identified. The behavioral issues can be worked around or reported and fixed by the OS community.

Security issues are harder to detect

It’s a little more complex with security issues, however. Security issues are harder to detect because it is the unexpected usages that identify them, and most development teams do not have the inherent skills required to identify security flaws. Vulnerabilities can occur in functionality that is used by the application. However, many vulnerabilities can be exploited in functionality that is exposed by a component but not used by the application. This makes the vulnerabilities particularly dangerous when the component is used in Web or mobile applications, where they can be exploited by remote attackers.
​
That’s not so good. It’s bad.

When vulnerabilities are identified in third-party components, updates are released. It’s a completely standardized and expected practice. But just because a component has provided an update doesn’t mean it’s been updated in all the applications that use that component.

This is where things get not just bad, but ugly. Nobody wants to be in the headlines because of unpatched third-party components.

Teams happily adopt third-party, mostly open-source, components, but they don’t prepare for rapid updates of the components. We tend to put a component in our code and then forget about it. Our own code gets all of our attention; after all, we adopted third-party components so we don’t have to worry about them, right?

Real-life consequences of not addressing third-party components 

Several years ago, the world was exposed to the massive Equifax breach and the aftermath that followed. The vulnerabilities that were exploited in a third-party component between May and July of 2017 were reported as early as March of 2017 – but they weren’t addressed within Equifax immediately.

Preparing for rapid updates is key, but the inherently urgent and unknown element of a rapid update is why it’s so often ignored as part of regular protocols. For most teams, it’s a panicked emergency the first time a severe vulnerability forces an update – when it should be part of a routine preparedness drill.

Don’t fear running the drill! The reason we drill is to be prepared: the drill provides you with the skills and mindset to do better when an emergency upgrade comes along. Make sure your developers understand – to the point of owning – all of the interfaces and dependencies between proprietary and third-party code. Prepare your testing environment to check those dependencies, so when the change is required you can do it quickly and confidently.

How can you tell if an application is at risk? 

That takes care of one challenge around third-party component security. But what about identifying security issues to begin with? Knowing that your application is at risk? And how to get those indications as quickly as possible?

Dynamic analysis has had, for a long time, tests that identify published third-party vulnerabilities. Those tests use dynamic analysis (DAST) techniques to perform a test exploit that identifies CVEs disclosed by vendors. However, it may take a long time to produce an exploit for a vulnerability — but you don’t want to wait until the hackers come up with one first.

In HCL AppScan on Cloud (ASoC), we have created the ASoC Open Source Analyzer (OSA). The OSA leverages ASoC’s Static Analysis tools to generate signatures of all third-party components that your project depends on. Those signatures are uploaded to the ASoC service. OSA doesn’t indicate specific exposure in the application, but rather that the component is vulnerable and what it is vulnerable to.

How does that help? When a new version of a third-party open-source component is released, a signature of the library is created and stored. When vulnerabilities are reported against the component, OSA is immediately aware and the vulnerability is associated with the component’s signature. If Static Analysis or Open Source Analysis are integrated into your build pipeline and scans are performed continuously, you see a Zero-Day indication that the component and its specific version are vulnerable. This occurs even if no exploit is available yet. It allows you to get ahead of hackers and confirm that your application is secure.

Until recently, OSA was only available as part of a Static Analysis scan. AppScan on Cloud now allows you to create an OSA-only scan. This increases even further the response time when performing open-source scans.So go ahead, introduce third-party open-source components into your pipeline regardless of proprietary code changes. You’ll accelerate development while confirming that your application is secure. And you won’t be in the headlines for the wrong reasons.

​That’s good.

Learn More

To test-drive HCL AppScan on Cloud on your own, register now for our 30-day free trial.