Thinking Security: Software Composition
This is the 39th blog in a series about security and how security is about how you think.
Back in blog #9 (“Do I have that?”) I wrote about the dilemma that consumers face when vulnerability reports come out in the media and want to know if they are at risk for that vulnerability. That blog post put the responsibility on the manufacturer (in this case, the company that makes an Internet-connected toaster) to keep up to date on all pieces of the toaster and notify consumers when any updates are ready to alleviate vulnerabilities that could affect the toaster.
But what must the manufacturer do in order to keep all of its clients happy and not vulnerable? The manufacturer must implement many processes and policies to keep all of their products free of any known vulnerabilities. The first process is to document and keep a current list of all modules that are part of any product. This software “bill of materials” contains the name of the component, its version and an indication of author. The author could be the same manufacturer (developed in-house), another company (a commercial component), or an open source project. This author indication should also include a reference to where the latest version can be downloaded as well as a reference to where all of the fixes (whether they reference a vulnerability or not) are documented. These references enable the person in charge of the product to analyze whether or not to build the next version of the product to pick up the outstanding fixes to the components.
This decision is not an easy one. If we trigger a build of the product as soon as one fix is ready, all testing must complete before the next version can be built (which could take days or weeks). If we trigger a build of the product only periodically or sporadically, severe vulnerabilities in the product may be present in the field for days, months, or even years.
What the product owner (the person in charge of the product) must do is evaluate each fix (whether it fixes a vulnerability or not) and then apply the company policy as to when the next version must be built. The manufacturer of the module (self-generated, commercial or open source) will rate each fix according to a scale. One example of a scale would be CRITICAL, REQUIRED, RECOMMENDED and OPTIONAL. This scale indicates the manufacturer’s view of how critical each fix is If the fix addresses a vulnerability, it would also have a CVSSv3 score associated with it (CVSSv3 scores range from 1-10, with 9.0 and higher being CRITICAL, between 7.0 and 8.9 being HIGH, between 4.0 and 6.9 being MEDIUM and 3.9 and lower being LOW).
The manufacturer also would have established a corporate policy about when new builds are required for fixes. For example, a component with a CRITICAL fix or addressing a HIGH or CRITICAL vulnerability would immediately require a new build. A component with a lower-urgency fix or a CVSSv3 score below HIGH would require a new build monthly or quarterly to pick up any known fixes. The manufacturer would publish this corporate policy on its support portal.
Automation is the key to keeping up with this process. As fixes become available, the build process would constantly check to see if they required a new build. If so, the requirement would trigger the build and generate a new software bill of materials. The testing team would receive notification about the need for a new build and would run the testing plan against the new build to ensure that it still fulfilled all of the product requirements.
It comes down to how you think about the software process and how you build software to keep it secure. Knowing what’s in your software (your software bill of materials) is the first step to keep up with each module and its fixes. Then, knowing the details about any fixes and their security impact helps the manufacturer keep its products secure. It’s all about how you THINK about software and its security that keeps the products secure.