Software Composition Analysis and Ecosystem: A Deep Dive

In the traditional sense, software platforms, frameworks and libraries were implemented using proprietary software. They would consist of various building blocks originating from internal development or third-party commercial software providers. Over time, companies started to incorporate open source software into their platforms and software stacks. This was because of the numerous advantages it offers, both from a strategic perspective and also practical, engineering perspective. A new multi-source development model then emerged.

Paradigm shift

Following the multi-source development model, source code packages stem from many sources and are licensed under different licenses. A product or a service could now have any combination of the following:

  1. Proprietary source code developed by your internal team, with a high likelihood of them containing open source code
  2. Third-party commercial source code developed by software providers or partners
  3. Open source code developed by the open source community

Before this paradigm shift, organizations would manage and mitigate their security and compliance risks through company-to-company licensing agreements. Fast forward to today, these risks are managed through careful engineering practices, improved secure coding guidelines and compliance efforts. This process is what we call software composition analysis.

What is software composition analysis?

Software Composition Analysis is the process of analyzing source code to identify open source software in the code base, and to determine applicable licenses. The process also enables the evaluation of any security risks resulting from discovered vulnerabilities. It requires a body of source code on which to run the analysis, and the sample output typically includes one or more of the following:

Output of software composition analysis
  • Software Bill of Materials (SBOM): A list of all discovered software components with their corresponding licenses. In some cases, it flags licensing issues based on company policies.  
  • Security Vulnerabilities: A list of known security vulnerabilities discovered in the codebase. It corresponds to specific software components, including severity classification and recommendations for mitigation.
  • Project Health Metrics: Specific metrics related to the health of open source projects discovered in the body of code analyzed.

The importance of software composition analysis has grown year over year along with the increased adoption of open source software. This growth has led to the creation of a new breed of tools, software composition analysis tools (SCA tools). These tools vary in functionality, but most of them offer automation of the process of discovery and mitigation. Additionally, they can be integrated with the development environment & CI/CD Systems to provide a seamless experience for its users.

Core elements of software composition analysis

Diving deeper into its core, there are three elements of software composition analysis. Some of these elements correspond one-to-one to essential functionality provided by tools that automate the analysis. The first one is adhering to open source licence compliance requirements. It means that organizations use software composition analysis to determine what open source software they’re using in their source codebases. This includes its origin as well as applicable licenses. The information allows companies to compile the list of license obligations and fulfill them when shipping a product, or releasing a service.

The second element is the discovery of vulnerabilities in the source codebase with remediation suggestions (if any) to neutralize them. Software composition analysis gives developers detailed information about vulnerable packages and possibly specific vulnerable functions. Such information helps developers prioritize the effort to fix these discovered vulnerabilities.

The generation of software bill of materials is the last core element. SBOM is an inventory of all software packages with detailed information that varies by the tool provider. Any organization must understand its software supply chain and have a detailed SBOM for any given product or service.

When is a software composition analysis needed?

While software composition analysis bridges the gap between discovery and mitigation, there are certain use cases the analysis is needed. These situations can be a one-off exercise; others are an ongoing effort based on software development efforts.

Three use cases where software composition analysis is needed.

Software development is a typical use case. Organizations developing software use components from third-party software vendors as well as open source ecosystem channels, such as GitHub.

Corporate transactions is the second use case that needs such analysis. Virtually any technology transaction (e.g. a merger, an acquisition and technology investment) will involve software in some form. The software due diligence process is becoming a standard part of such corporate transactions. Hence, insights into any security or compliance risks associated with the codebase are vital. 

Another situation requiring SCA is when establishing baseline security and compliance. Organizations perform a software composition analysis on older software stacks to achieve baseline license compliance. This is also performed to uncover any known security vulnerabilities. Then, they would maintain this security and compliance adherence incrementally as they develop the code further and introduce new functionalities.

Software composition analysis and its benefits

Besides the efficient management of open source component use, there are many direct and indirect benefits of software composition analysis. The direct benefits include better license compliance, more secure code and more trust in the distributed software.

Performing SCA helps organizations gain a better understanding of the open source packages used in their applications as well as their liscensing information. In turn, this information leads to better open source license compliance. Since the running security audit will uncover any security vulnerabilities found in the code base, it automatically means decreased security risks. Increasing credibility is also the result of the complete SBOM that can be communicated within the software supply chain.

On the more obscure side, software composition analysis brings about diverse indirect business benefits. Firstly, it enables organizations’ contribution to critical open source projects to ensure their sustainability. Once organizations have gained a deeper understanding of the software stack, they will also realize the reliance on open source in their product development.

In many cases, software composition analysis tools provide functionalities to manage the governance aspect of using open source code. The organization can then enforce adherence with its own security and compliance policies. 

Lastly, organizations will be able to maintain proper practices within the software supply chain by providing SBOM up or down the supply chain.

Automation of software composition analysis

In the early 2000s, the analysis was mostly a manual exercise infused with some ad-hoc created tools internally. It was discovered shortly after that the increased use of open source made the manual work impossible. 

Companies were founded on the promise to enable automation as a result of this market need. In addition to commercial solutions, several open source projects aim to implement the various functionalities of a software composition analysis. You can read more about the automation of SCA on our “Your Top Five Questions about SCA” blog post.

Nonetheless, it’s not always clear-cut how to choose the right tool due to lack of general standards. Despite this shortcoming, there are a number of metrics used to evaluate SCA tools that can simplify the process. These metrics include knowledge base, detection capabilities and ease of use.

What is the future outlook for software composition analysis?

Looking ahead, there are some very exciting developments that can benefit organizations with their open source legal compliance and security efforts.

  1. Full automation that covers both security and compliance with assistance of artificial intelligence and machine learning technologies 
  2. Increased detection accuracy in terms of correctly identifying the true origin of the code and the license under which it was released
  3. Improved data quality with knowledge bases and better coverage in line with the fast development cycles that we witness in open source
  4. Seamless integration with developers workflows that allows any developer to run the analysis, interpret the result, and make a decision on the use of a piece of code while remaining compliant, all in real time 
  5. Improved discovery of security vulnerabilities and the availability of a larger more accurate pool of security vulnerabilities sources. 

Open source security and compliance audits are an ongoing process and not a destination. It allows organizations to be prepared for any scenario where software changes hands – from a possible acquisition, a sale, to product or service release

Similarly, organizations will always need to ensure less risks associated with security vulnerabilities, thus the need of continuous security audits. Organizations are highly encouraged to invest in building and improving upon their open source security and compliance management programs.

If you are looking for a solution that helps you stay on top of security while maintaining your development speed, create a free account and try out the Debricked tool today!

Want to stay up to date with our lastet news and products?

Share on linkedin
Share on twitter
Share on facebook
Share on google

2 thoughts on “Software Composition Analysis and Ecosystem: A Deep Dive”

  1. Pingback: OWASP Top 10 Security Vulnerabilities in 2021 | Debricked

  2. Pingback: Comply with the SBOM Requirements of the New Cybersecurity Executive Order - Debricked

Leave a Comment

Your email address will not be published. Required fields are marked *