The following is a guest post from IT Central Station, a peer review site for enterprise technology users.
Open source software (OSS) now comprises around 90% of modern applications. Of course, companies that use OSS need to know what’s in it. Any number of legal, quality, and security problems can arise if open source software (OSS) dependencies are not well understood.
This is the role of software composition analysis (SCA) solutions. They enable development teams to identify and mitigate OSS risks by scanning open source code and identifying potential issues related to licensing, security. and so forth.
What makes for an effective SCA solution? IT Central Station members weighed in on this question, based on their experiences with FOSSA's SCA solution.
1. Conducts Dependency Scanning
Dependencies between OSS components occur when a piece of open source software in an application must “pull” code from an OSS library that’s hosted elsewhere. Dependencies have the potential to create security vulnerabilities because it can be difficult for users to know what’s actually contained in a dependent code library. The code in the library might feed the app malware or include a strong copyleft license that puts an organization at legal risk.
A communications service provider’s Sr. Director of Open Source spoke to this need, saying “The build script calls FOSSA automatically and determines through the FOSSA scan what licenses are being used in the dependencies, and it determines if they comply with our policies.”
2. Includes a Vulnerability Database
A huge amount of information about OSS vulnerabilities exists in various databases. An effective SCA tool will connect with these information sources, enabling stakeholders to have the most current vulnerability data possible. The best of these databases are continuously updated from multiple reputable sources. They are curated to avoid false positives.
3. Enables License Compliance
An SCA solution should provide an audit-grade inventory of open source license types that are in use within an organization. It should also offer visibility into any hidden, embedded, and declared OSS licenses in the source code — this gives users detailed metadata information, including license text, copyright info, and licensing obligations.
As a Manager of the Open Source Program Office at a financial services firm put it, “The most valuable feature is [an SCA solution’s] ability to identify all of the components in a build, and then surface the licenses that are associated with it, allowing us to make a decision as to whether or not we allow a team to use the components. That eliminates the risk that comes with running consumer software that contains open source components.”
4. Is Developer-Friendly
Ideally, an SCA tool will form a natural fit with DevOps and other software development and release workflows. This makes sense, because if the SCA tool does not function well in the development and release process, it will not serve its intended purpose. Indeed, it might be abandoned at that point.
A Program Manager at a consumer goods company with more than 10,000 employees addressed this issue, saying that FOSSA “cuts the software engineers’ work a lot.” He added, “Because if it is already approved and scanned, then they don't have to do it again. It improves productivity, saving a lot of time for our software developers.”
5. Integrates with CI/CD Workflows and the Shift-Left Agenda
SCA needs to be part of the Continuous Integration/Continuous Development (CI/CD) workflow. CI/CD moves too quickly for SCA to be an external process. That approach will not work.
A Sr. Security Architect at a software company put it this way: “Just executing FOSSA can be achieved by adding a single line to a continuous integration pipeline. FOSSA wants to come in as soon as that dependency gets introduced. This reduces the amount of work and everything that would need to be done in order to replace that dependency with something else.”
6. Offers Remediation Support
An SCA solution works best if it can give developers some guidance on how to fix a problem it discovers. A cold handoff — a problem without a solution — doesn’t accomplish much. Such guidance could include items like succinct, actionable steps and release comparisons that preview patches and proactively visualize changes.