Software composition analysis: Difference between revisions

Revision as of 19:53, 26 February 2023

Revision as of 05:16, 27 February 2023

Line 1:

{{Use dmy dates|date=February 2023}}

{{Short description|Software Composition Analysis}}

It is a common [[software engineering]] practice to develop software by using different components.<ref>

{{Cite journal

|last1=Nierstrasz|first1=Oscar

Line 54 ⟶ 55:

* OSS Version Control: risks of changes introduced by new versions

* Security: risks of vulnerabilities in components - [[Common Vulnerabilities and Exposures|Common Vulnerabilities & Exposures]] (or CVEs)

* License: risks of [[Intellectual property|Intellectual Property]] (IP) legal requirements

* Development: risks of compatibility between existing codebase and [[open-source software]]

* Support: risk of poor documentation and [[Obsolescence|Obsolete software components]]

Line 83 ⟶ 84:

==Overview==

'''Software Composition Analysis''' (SCA) is a practice in the fields of [[Information technology]] and [[software engineering]] for analyzing custom-built software applications to detect embedded open-source software and detect if they are up-to-date, contain security flaws, or have licensing requirements.<ref>

{{Cite journal

|last1=Prana|first1=Gede Artha Azriadi

Line 150 ⟶ 151:

== Usage ==

As SCA impacts different functions in organizations, different teams may use the data depending on the organization's corporation size and structure. The IT department will often use SCA for implementing and operationalizing the technology with common stakeholders including the Chiefchief Informationinformation Officerofficer (CIO), the Chief Technology Officer (CTO), and the Chief Enterprise Architects (EA).<ref>{{Cite web|url=https://www.mckinsey.com/capabilities/risk-and-resilience/our-insights/cybersecurity/software-bill-of-materials-managing-software-cybersecurity-risks|title=Software bill of materials: Managing software cybersecurity risks}}</ref> Security and license data are often used by roles such as Chief Information Security Officers (CISO) for security risks, and Chief IP / Compliance officer for Intellectual Property risk management.<ref>{{cite book |last=Popp |first=Karl Michael |author-link= |date= 30 October 2019|title= Best Practices for commercial use of open source software|url= https://books.google.com/books?id=w1a6DwAAQBAJ |publisher=BoD – Books on Demand, 2019 |page=10 |isbn=9783750403093}}</ref>

Depending on the SCA product capabilities, it can be implemented directly within a developer's [[Integrated_development_environment|Integrated Development Environment]] (IDE) who uses and integrates OSS components, or it can be implemented as a dedicated step in the [[software quality control]] process.<ref>

Line 185 ⟶ 186:

}}</ref>

SCA products, and particularly their capacity to generate an SBOM is required in some countries such as the [[United States]] to enforce the security of software delivered to one of their agencies by a vendor.<ref>{{Cite web|url=https://www.federalregister.gov/documents/2021/06/02/2021-11592/software-bill-of-materials-elements-and-considerations|title=Software Bill of Materials Elements and Considerations}}</ref>

Another common use case for SCA is for Technology [[Due diligence|Due Diligence]]. Prior to a [[Mergers and acquisitions|Merger & Acquisition]] (M&A) transaction, [[Independent advisory firm|Advisory firms]] review the risks associated with the software of the target firm.<ref>

{{Cite journal

|last1=Serafini|first1=Daniele

Line 266 ⟶ 267:

}}</ref>

* Limiting vulnerability data to reporting only on vulnerabilities officially reported in the NVD (which can be months after the vulnerability was originally discovered)<ref> {{Cite web|url=https://owasp.org/www-community/Component_Analysis|title=Component Analysis|website=owasp.org}}</ref>

* Lack of automated guidance on actions to take based on SCA reports and data <ref>

{{Cite journal

|last1=Foo|first1=Darius