You can edit almost every page by Creating an account. Otherwise, see the FAQ.

Software Composition Analysis

From EverybodyWiki Bios & Wiki


Software Composition Analysis (SCA) is the process of identifying the components that comprise a given piece of software.[1] The components may be identified at a range of levels, from higher-level (for example, corresponding to items in "cloud diagrams"), to mid-level (such as distinct classes, modules, or files), to low-level (e.g. functions or methods comprising a file or class).

The software to be examined may be generally perceived as a single monolithic entity (in which case SCA aims to reveal its constituent components), or it may as in the case of modern operating systems already be seen as a collection of components (in which case SCA may identify components at a greater level of granularity, or identify the interrelationships among already-known components).

The term SCA may also refer to the analysis of a single component, showing for example its inputs, outputs, and side-effects.

The result of SCA is also known as a software bill of materials (BOM)[2] or a "software teardown."

In the industry, SCA is often viewed as limited to identification of open source used within a software product. For example, a typical definition is: "Software Composition Analysis (SCA) is the process of automating visibility into the use of open source software (OSS) for the purpose of risk management, security, and license compliance." However, SCA need not be limited to open source, and may include identification of proprietary third-party or in-house components. The common restriction to open source may be based on a software components are invisible without source code. However, software reverse engineering, including both static examination (e.g. disassembly and decompilation) and dynamic examination (e.g. packet sniffing) of commercial products, provides often-feasible methods to determine the composition of software, without the benefit of source code.

The purposes of SCA include security audits (particularly when a product's use of particular version of a components can be identified, and compared to repositories of known security vulnerabilities), license compliance (both OSS and proprietary components), and intellectual property infringement.

Products[edit]

References[edit]

  1. Chen, Yang, et al. "Automated Identification of Libraries from Vulnerability Data." (2020).
  2. Kuuva, Oula. "LINUX KERNEL MODULE RECOGNITION USING STATIC BINARY ANALYSIS." (2018).
  3. https://www.whitesourcesoftware.com/how-to-choose-a-software-composition-analysis-solution/
  4. https://www.synopsys.com/software-integrity/security-testing/software-composition-analysis.html
  5. https://www.veracode.com/products/software-composition-analysis

shlepsalt[edit]


This article "Software Composition Analysis" is from Wikipedia. The list of its authors can be seen in its historical and/or the page Edithistory:Software Composition Analysis. Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.