With OSS, know when you’re vulnerable

by Jeremy

Instead of building all software “from scratch” today, developers use open source to their advantage when providing common or repetitive elements. Doing so primarily limits the homegrown code they develop for proprietary features and functionality while also being the adhesive that binds everything together. Consequently, developers spend much of their time on critical differentiators rather than recreating standard features.

0330.sdt news

The measurable benefits of open source have aided the rapid evolution of application development and curtailed development cycles. However, as with any new advancement in technology, there can be risks associated with open source that organizations must identify, prioritize, and address. There is little doubt that open-source vulnerabilities can leave sensitive data exposed to a breach; however, complex license requirements can jeopardize intellectual property, and outdated libraries can place unnecessary support and maintenance burdens on development teams.

RELATED CONTENT: The modern risks of open-source code

In the context of risk, license risk can be addressed in most cases. Still, it can vary depending on how an application is deployed — an internal application, an external-facing application, or a commercial application. Organizational risk (e.g., technical debt) can also be addressed by avoiding outdated open-source projects that the community may adequately support. However, quantifying security risk is not as easy as it sounds. Therefore, the key to open-source security is to know when you are vulnerable and precisely the root cause.

Are we vulnerable?
Most SCA (Software Composition Analysis) tools are designed to detect third-party libraries and versions in use and inform developers of known vulnerabilities. However, it’s essential to acknowledge that not all libraries in a project may apply since some may not be utilized within an application itself. Just because a part of a library is notably vulnerable does not necessarily mean the vulnerable part is actually in use. In other words, the real key to measuring security risk is to determine the exploitability of a vulnerability within the application itself.

The popular method used to determine exploitability is through the Common Vulnerability Scoring System (CVSS), a score given to a vulnerability based on the impact, how easy it is to exploit, etc. Every exposure that has been made public has this score. However, this methodology is too simplistic because exploitability is the essential characteristic to measure risk truly.

Related Posts

Leave a Comment