Software composition analysis: Difference between revisions

Revision as of 17:37, 13 January 2023

Revision as of 17:38, 13 January 2023

Line 1:

{{AFC submission|d|reason|Sending back to submitter to work on and resubmit per comment.|u=Adwerald|ns=118|decliner=Mattdaviesfsic|declinets=20230113173841|ts=20221109174935}} <!-- Do not remove this line! -->

{{AFC comment|1="Usage" section almost entirely unsourced. First paragraph of "Overview" section also unsourced. Other than that, looks good, and would be happy to accept when these minor things are sorted! [[User:Mattdaviesfsic|Mattdaviesfsic]] ([[User talk:Mattdaviesfsic|talk]]) 17:37, 13 January 2023 (UTC)}}

Line 9:

{{AfC topic|other}}

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

{{Cite journal

|last1=Nierstrasz|first1=Oscar

Line 144:

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|software quality control]] process.

SCA products, and particularly their capacity to generate an SBOM is required in some countries such as the [[United_States|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.