Third-party components, open-source in particular, are an essential part of modern development efforts. These components accelerate development and help your team retain focus on developing the core technology code.
The challenge with adopting third-party components is that the behavioural and security issues of the component are adopted as well.
Behavioural issues are normally discovered quickly: as component functions are used, any failure or unexpected results are identified. The behavioural issues can be worked around or be reported and fixed by the OO community.
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 the third-party components, updates are released. Completely standard 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 our attention; after all, we adopted third-party components so we don't have to worry about them, right?
Recently the world was exposed to the massive Equifax breach and the following aftermath. 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 regular 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 the interfaces and dependencies between the 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.
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. These tests use dynamic analysis 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 Application Security on Cloud (ASoC) we have created ASoC Open Source Analyzer (OSA). The OSA leverages the ASoC Static Analysis tools to generate signatures of all third-party components that your project depends on. These 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 this 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 is integrated into your build pipeline and scans are performed continuously, you see a Zero-Day indication that the component and its specific version is vulnerable. This occurs even if no exploit is available yet. It allows you to get ahead of the hackers and ensure your application is secure.
Until recently, OSA was only available as part of the Static Analysis scan. Application Security on Cloud now allows you to create an OSA-only scan. This increases even further the response time when performing the 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 ensuring your application is secure. And you won’t be in the headlines for the wrong reasons.
Connect with me on LinkedIn