The SolarWinds attack in late 2020 exposed the data of more than 18,000 businesses and governmental departments – many of which are gatekeepers for the country’s most vital infrastructure. While attacks against the software supply chain aren’t new, they are increasing exponentially.
As a result of the SolarWinds attack and the massive uptick in total software supply chain attacks, governmental entities are now focused on preventing such cyberattacks. An executive order early this year outlines changes that must be made, including the need for all software to contain a software bill of materials (SBOM), which is a formal, machine-readable inventory of software components and dependencies used to track supply chain relationships, dependencies, and hierarchical relationships.
SBOMs are often referred to as an ingredient list for software, and that’s not a bad description. But truly effective SBOMs also need to include changes made to that ingredient list as well as provide a way to remediate vulnerabilities when they’re identified so the final recipe always turns out better than the last.
To better understand that analogy, it helps to consider SBOMs in terms of one of my favorite treats: a well-known brand of dark sea salt chocolate.
It’s only fair that I begin with a personal disclosure: I like chocolate. More specifically, I really like dark sea salt chocolate. Even more specifically, I like to indulge in a weekly fix of a certain well-known brand of dark sea salt chocolate.
As I was growing up, the packaging of said chocolate mostly promoted the exquisiteness of the cocoa used in its making with little detail about other ingredients. One day, as I was purchasing my weekly dose, I noticed that the packaging had changed. The new packaging now featured a list of nutrition facts in miniscule type.
I was surprised to learn that the main ingredient in my chocolate was not exotic cocoa, but sugar. Nevertheless, I purchased the chocolate bar and ate with great enjoyment that was now sprinkled with a tiny pinch of guilt. What I didn’t know at the time was that the packaging change was a result of the 1990 Nutrition Labeling and Education Act (NLEA), an early regulatory attempt at addressing obesity and other food-related health problems by promoting transparency in food labeling.
A few more years passed, and the packaging changed again. This time, the packaging included the amount of saturated fat in the chocolate. While still small, the type was larger. Once again, I continued to purchase and eat the candy with great enjoyment and a smidgen of shame.
More years passed, and the label changed again. This time, it included a prominent red label on the front indicating that the product had excessive sugar and fat. I could not in all good faith continue as before, which is why I have since made it a habit of carefully discarding the external packaging prior to consuming my weekly chocolate treat.
Although amusing, my experience is not unique. Food labeling in and of itself has done little to address or modify people’s unhealthy eating habits. Because transparency in itself is not enough to drive outcomes.
The same holds true with SBOMs. Many solutions aren’t much more than a list of ingredients. These reporting-centric solutions do nothing to stop cyberattacks, and they fail to meet the government’s SBOM mandates.
What’s needed is a remediation-centric solution like the new WhiteSource SBOM. Remediation-centric SBOMs contain all the “ingredients” of software, but they also provide a path to remediation when vulnerabilities are identified.
To use my chocolate example one last time, my remediation was to simply throw away the packaging without checking for new changes. Thankfully, the remediation process of WhiteSource SBOM is much more effective – and it ultimately enables organizations to meet the government’s new regulations, while providing a number of additional benefits.