There is a wide variation in functionality across currently available Software Composition Analysis tools, ranging from compliance and security vulnerability features to managing the compliance process and integrating checks across the development process.

Some tools provide degrees of freedom to customize the workflow according to your own policies and processes, whereas others offer a more monolithic approach with a curated set of capabilities. The maturity and specialization of your organization guides which choice that fits your technical, business, and legal goals the best. But when comparing available tools, one observation stands out: the weak, or completely lacking, support for code snippet discoverability.

But why is this important in the context of open source compliance? Why is snippet support critical as part of your security vulnerability detection process?

 

How does source code enter your organization?

Source code enter your organization either via your own developers creating and integrating code from various sources, or via your supply chain. In both cases developers do a combination of:

  1. creating original code,
  2. re-using code from various sources, and
  3. integrating code.

The challenge with open source compliance and security vulnerability detection does not lie in the use of whole components as these are relatively easy to discover and track (we define a whole component as all of the software package, versus a snippet being few lines of lines of code copied from the open source software package.). No, the real challenge is when developers copy open source snippets of code and integrate them in larger bodies of code. With that, it becomes instantly challenging for most of the existing tools in the market to identify the true origin and license of these snippets, together with known security vulnerabilities, and to flag them.

 

Entire Components

Open source projects are continuously being forked and reused, which makes some scanners prone to noisy reports including irrelevant lists of secondary matches. With FOSSID, you ​save a lot of time and analysis effort by using our fast identification method that identifies the true origin of the components automatically, regardless of their current format (code, archives, binaries, etc.).

 

Full Files

Altering files voluntarily or automatically makes identification of matches more challenging and it might even require license compliance actions. FOSSID’s search algorithms find files even if they have been edited and match them to their source of origin and original license.

 

Code Snippets

It is common practice to copy paste code from the web when implementing new features or fixing bugs. With FOSSID, you will find snippets of open source code and their licenses, so that you can follow your corporate guidelines, comply with applicable open source licenses, and focus on what brings real value to your products and services.

 

Why should you care about the discoverability of source code snippets?

Open source compliance and security vulnerability detection is mostly a risk management exercise. You want to be compliant with applicable licenses for all source code included in your products and services and avoid security vulnerabilities.

As a company you want to enable your developers to use open source software, and as a developer you want the flexibility of using both whole components and re-using files or partial code snippets originating from open source projects.

We believe that snippet search and identification is a core proposition and an enabler for you to gain the flexibility you desire while using open source – minimizing your risks, both from a compliance and a security perspective.

 

How is the security vulnerability discovery connected to snippets?

Current tools available in the market support the detection of security vulnerabilities when they discover your use of a whole component. For instance, if you are using zlib (fictional example), and there is a known vulnerability in the source code, the tools will flag it and provide you additional information about the vulnerability. The tools assume the use of whole components (i.e. source code copy/paste use cases are not covered), and they flag any file that matches a vulnerability disclosure for the scanned component. Now, think of all the thousands of components that re-use zlib code (most of them under different licenses), then try to imagine the number of false positives you will have to review as possible matches.

To augment the problem, what happens when developers copy snippets of code from the zlib code base and incorporate that in a product repo? These tools will simply not discover these snippets and as a consequence won’t be able to flag any known vulnerabilities that were copied with the code. So now you have two hidden problems: a compliance issue and a security vulnerability that are not discovered and unresolved.

FOSSID avoids such situations due to our ability to track code at snippet level. We flag our users of code snippets copied from foreign sources into the scanned source code containing known security vulnerabilities. And we provide a reference to its original source, the version number of its original component parent, the license name and version, and any known security vulnerabilities associated with the code with pointers to additional information and possible remediation when applicable.

Let us help you find the vulnerable snippets in your code!

14 + 13 =