Governance in Software Composition Analysis
Governance in SCA solutions is an often overlooked yet extremely powerful feature set that can significantly improve a company’s supply chain security, and legal compliance. Governance or Governance Policies consist of the ability to create rules which restrict open source packages based on certain criteria. The result of running these rules is a set of actionable issues, or policy violations, which describe the reason for the violation along with the corresponding package(s) which caused the violation.
Before tackling how and why governance is important, we first need to look at what most SCA solutions on the market provide. Most solutions today provide the ability to create governance policies which allow or exclude certain licenses. This is certainly an important part of legally protecting your company, but it’s really just one aspect of governance.
Let’s break down governance into a couple areas: Legal (protecting against unwanted licenses or legal requirements), Package Statistics (protecting against little used packages), and Internal Company Restrictions (specific packages or versions which have been deemed ill suited for use).
Legal/License Policies
We’ve already touched on creating “allowed” or “excluded” lists of licenses, which is certainly one means to an end, but looking through hundreds of SPDX licenses to decide which to allow or exclude can be time consuming and error prone. Larger companies, especially those with dedicated legal departments, can ensure only the licenses you want to allow through are allowed with this method. This could work for smaller companies, with a limited set of licenses you know you want to exclude, such as the GPL/LGPL family of licenses.
An alternative which SOOS has pioneered, which works for large and small companies, is the ability to leverage license attributes along with specific company requirements to automatically determine if specific groups of licenses should be excluded. Time spent by expensive legal and technical resources on each software change is greatly reduced and accuracy is increased, guaranteeing a high ROI. As an example, let’s take a commercial company who has patents (or patents pending) on their software; wouldn’t it be nice to just say, “exclude any licenses which disallow commercial use, or which restrict the ability to patent software”? Well, that’s exactly the type of thing you can accomplish with SOOS. Quickly, select a few options about your company and within minutes have a list of packages and their corresponding licenses that have legal issues with your specific usage across your projects.
Finally, it is important to be aware of packages without licenses or with unknown licenses. These need to be manually investigated and attested to. There are two parts to this problem, first, identify the packages with unknown/missing licenses, and second, research and attest to the actual license. SOOS provides these abilities through an “Unknown/Missing License” policy which identifies each instance of an unknown/missing license, followed by SOOS’ attestation flow which allows users to provide attestations/suppressions for any issue in the system, along with a corresponding attestation scope. Scopes can include: the issue, issues in the project (current branches), issues in the project (current and future branches), issues in all projects (current and future branches).
By combining all three governance policy types, you can create comprehensive protection and insight into your license usage. You can be more secure, confident of your legal posture and usage rights, in an automated governance process that is always watching for changes to the software and the open source packages.
Package Statistic Policies
Package statistics can be an indicator of reliability, recency and supportability. There are a number of ways to determine the popularity of a package and thus indirectly whether it should be allowed to be used. One of the best metrics available across almost all package managed languages is the concept of downloads or installs. Providing a minimum threshold of downloads allows a company to filter out less used packages which may be risky to rely on.
Company Restriction Policies (restricting specific packages/versions)
In some cases a company or even just a specific development team, may want to restrict the use of a package or even version/range of versions of a package. Maybe a specific package version has breaking functionality and keeps accidentally getting installed, or a package with specific features is being used, but it isn’t the desired package to use from a company perspective. Being able to restrict these specific packages/versions is the most granular level of governance available.
Once you settle on a subset of governance policy rules, there are likely further configurations around how to apply the policies, when to notify, and if the policy is a suggestion or should stop the build.
Global or Per Project?
Often governance policies and specifically license based policies, as dictated by a legal department, should be considered global, that is applying to any project that is scanned within the company. However, there could be nuances even here, for instance internally facing software might have less legal or supportability restrictions than customer facing software. In this case, configuring policies for a specific project or projects provides the flexibility to trigger governance policies only for the codebases that they should be triggered for. SOOS fully supports these configuration options.
What do do with Policy Violations – Notifications, Breaking the Build, Creating Tickets, and more
The final piece in the governance puzzle is what to do with policy violations. Notifying users when violations occur, so users have awareness of new issues, is the obvious first step. This can also be accomplished by configuring a “Break the Build”, or “Fail the Scan” option, possibly with a severity threshold so that only violations that are of a specific severity cause the breakage. Either of these actions cause users to investigate and ultimately decide what to do with the results that were found. There are really only two things to do, either remove the offending package (possibly by pushing the policy violation to the companies ticketing system), or as we discussed above, attest to the violation as known and provide details about why it’s acceptable, and of course maintain a full audit history of all actions taken by users as well as allow attested violations to appear in exported SBOMs.
Wrap Up
Creating comprehensive governance policies to properly protect a company’s software and open source package usage is much more involved than what most SCA solutions offer. It is important to have the ability to configure different types of governance policies to accomplish different goals, and have the flexibility to configure when and how these are applied, as well as the functionality to effectively manage the results.
