Traditional Software Composition Analysis has been designed security-centric: purposely designed for security analysis of finished applications where security acts as a gatekeeper of release-to-production approval. This has disenfranchised other stakeholders in application risk, including Legal and Engineering. For a successful holistic approach, every element of risk needs to be assessed: holistic Open Source Risk Management.

Software Composition Analysis (SCA) tools have historically focused only on identifying security vulnerabilities in Open Source Software. Software Composition vendors were able to translate early paranoia about OSS into sales of SCA tools to enterprises. Information security groups in these enterprises were already analyzing internally developed code for security vulnerabilities, so expanding security coverage to encompass OSS through OSS-focused SCA tools was a natural next step. SCA became a key component in establishing a holistic security perspective, covering both internally and externally developed code.

Likewise, vendors implemented license identification features to address concerns about Open Source licenses and potential exposure of proprietary IP, such as through the use of OSS with copy-left licenses. Legal departments were potential consumers of this information, but license remediation typically fell into the purview of information security groups since they were already managing the remediation workflow. Although legal teams were stakeholders in OSS risk, they remained mostly concerned with license policy compliance rather than remediation activities.

The need to support stakeholders other than infosec

SCA tools have retained an infosec-centric approach, addressing the needs of these majority stakeholders and disenfranchising other stakeholders. With security historically being an end of the Software Development Lifecycle (SDLC) activity, SCA vendors prolonged this legacy approach to security: the tools were designed for infosec, so infosec were the only ones using them. Consequently, SCA tools were not used throughout the SDLC, resulting in infosec becoming the de facto gatekeepers of the release of applications to production. With the cost of late remediation of vulnerabilities being so high, enterprises were faced with a dilemma of releasing known vulnerable code to meet a deadline, or blowing a deadline to improve security. Neither were palatable options. Just as the emergence of DevOps reduced the cost of operationalizing software by embedding operations in development, SecDevOps seeks to integrate security across the SDLC. With the shift-left of security earlier in the SDLC, SCA tools need to adapt to support stakeholders other than infosec.

Critical aspects of OSS risk that are often overseen

Newer SCA vendors, such as Snyk, approach security “left-first” by targeting developers as primary stakeholders. Snyk’s tools are designed to integrate seamlessly with the tools developers use to build and deploy applications. Snyk’s approach enables developers to address security concerns early and throughout the SDLC, preventing the costly end of production line issues that occur when application security is treated as an afterthought. In this model infosec partners with developers to build security into applications. This focus on security doesn’t address all aspects of OSS risk, which is multifaceted, and includes:


  1. IP risk from the use of OSS with certain types of licenses
  2. Risk from the illegal use of unlicensed proprietary code integrated into OSS
  3. Risk from failing to provide obligatory attribution required by Open Source licenses
  4. Risk from the use of modified versions of OSS licenses
  5. Hidden dependencies that introduce OSS with unacceptable legal risk or obligations


  1. Use of OSS with poor project health: excessively high numbers of issues/bugs, poor project management, missing documentation, lack of responsiveness to questions or issues, etc.
  2. Poor fitness for purpose: OSS with poor performance, scalability, and stability
  3. Use of out of date forks of a mainstream project
  4. Lack of code stability or API backward compatibility that makes upgrading to address issues difficult


  1. Use of software with security vulnerabilities that could be exploited to cause service disruption, exposure of sensitive proprietary information or personal customer information (PII), or credit card data (PCI)
  2. Use of OSS with fundamental security flaws that cannot easily be worked around or are esoteric and easily overlooked
  3. Use of software with poor secure coding practices, such as lacking input validation, encryption, array index bound checking, the potential for memory corruption with large data payloads, etc.

All types of risk must be addressed with equal priority to reduce potential damage from all aspects of the use of OSS. 

Few SCA tools take such a comprehensive approach to OSS risk, leaving enterprises with gaps in risk management. In fact, a myopic focus on deep security analysis and remediation can lead enterprises to mistakenly believe that they have OSS risk covered, when in fact their risk posture is very poor.

Why and how to create a holistic view of risk across all dimensions

Enterprises need a solution that provides coverage of all types of risk and supports all stakeholders equally: developers, infosec engineers, legal counsel, and IP lawyers. This requires a clear understanding of the use cases of each group of stakeholders and the provision of tools and services designed specifically for them. It doesn’t mean giving legal access to an infosec tool, or a developer a legal tool. Each user experience should be tailored to the stakeholder.

For a successful holistic SCA approach, each element of risk needs to roll up to an overall risk map for the enterprise that can be assessed against an enterprise risk compliance goal. A single SCA tool may not provide every part of this map, and analysis from other third-party tools may be required For example, an SCA tool might not perform secure coding analysis of proprietary code, or container security analysis, but other tools can complement the SCA analysis with this additional perspective. 

To address this challenge, many enterprises choose to develop custom risk dashboards, but this is challenging due to incompatible or proprietary data models, inadequate APIs, and disparate application identifiers that make risk correlation across tools difficult. An SCA tool must therefore provide an open and pluggable architecture that enables other sources of risk information to be seamlessly integrated. Ideally, the SCA tool or the integration framework should be made available as OSS so that the open-source community and tool vendors can collaboratively contribute to the development of integrations.

Finally, an open standard is required to measure OSS risk across all dimensions: legal, technical, and security. This would enable every supplier of risk data to assess risk on a common scale, and, finally, a way to compare risk across proprietary enterprise applications, open-source applications, open-source software components, and vendor applications.


Open Source Risk is multi-dimensional, covering legal, technical, and security concerns. Traditional SCA applications have focused almost exclusively on security to the exclusion of other dimensions. Enterprises must manage risk across all dimensions. It’s time for a new type of SCA tool that provides a holistic, complete, and comprehensible perspective that serves all stakeholders equally.

Ready to facilitate the next wave of Open Source adoption?

Get in touch

Looking for more informations? Download our OSS whitepaper.