These risks can be organized into 5 categories:[5] Shortly after the foundation of the Open Source Initiative in February 1998,[6] the risks associated with OSS were raised[7] and organizations tried to manage this using spreadsheets and documents to track all the open source components used by their developers.
[8] For organizations using open-source components extensively, there was a need to help automate the analysis and management of open source risk.
[13] Depending on the SCA product capabilities, it can be implemented directly within a developer's 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.
[14][15] 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.
Developers don't have to manually do an extra work when using and integrating OSS components.