Zooming through the rainbow roads of Mario Kart may seem worlds apart from the technical world of a software bill of materials (SBOM), but it is more alike than you might think.
If you have ever played the newer Mario Kart (6 or later), one of the critical elements of the game is selecting the right cart. Before each race, a player must go through the process of choosing which vehicle is best for them. Each cart has unique attributes and abilities to help players win the race. This cart selection process is highly comparable to choosing components for SBOMs.
Mario Kart to SBOMs: the art of choosing components
Much like a racer in Mario Kart, developers face a laundry list of obstacles that prevent them from reaching the finish line.
- External security threats (red attack shells from other players)
- The race to finish coding a project (boundless rainbow tracks)
- Technical debt that comes back to haunt them (those darn bananas)
For the less experienced players, knowing what components to use on their vehicles is daunting.
On average, most players will pick any piece based on its appearance and are unaware of how these components affect them during the race. In the software world, this is no different.
Default settings in Mario Kart help players choose the best options. Image credit: User NaviandMii - Nintendo Life
Sonatype’s 8th Annual State of the Software Supply Chain report notes that 62% of open source consumers used an avoidable vulnerable version of their dependencies. Developers have a large market of open source options to choose from and often select those that will "get the job done" as quickly as possible, without investigating their dependencies. Much like when playing Mario Kart, developers, like players, only care about getting started. But how do we simplify this process?
The creators of Mario Kart made it easy for their new racers to get running by recommending a starting cart before allowing them to customize areas of their vehicles. The Sonatype Research Team did the same for developers. They created a free tool that quickly scans the open source options to suggest the optimum "cart" for a developer. It runs algorithms that provide dependency recommendations for developers using open source components and provides a visual for developers to quickly spot where their vulnerabilities lie within an SBOM.
This new free tool is called BOM Doctor. Consider the BOM Doctor like your pit crew in this scenario, helping you recognize which parts to change quickly, efficiently, and with the best value.
The algorithms within BOM Doctor tailor its recommendations based on specific data-driven rules. This ensures developers are guided towards the best open source components for their particular build.
It is worth pointing out that Nintendo created their cart recommendations in a closed system since they designed every aspect of their game. The Sonatype’s Research Team works with open source, where external contributors create and add new components daily or upgrade existing components. The algorithms the research team created analyzes millions of combinations and complications to ensure developers feel empowered to make good decisions with their recommendations.
So how does the BOM Doctor make these recommendations on dependency selection?
How do BOM Doctor’s recommendations work?
Sonatype aims to help developers by streamlining the process of maintaining and upgrading SBOMs. Our Research Team has been analyzing open source components for years, observing that 69% of all upgrade decisions were suboptimal. These observations were verified through data gathered from Maven Central and additional proprietary data hosted by Sonatype.
Recommendations are made through a series of component scores that make it easy for developers to spot vulnerabilities visually, making upgrading or maintaining dependencies a breeze.
If we return to Mario Kart, upgrading and maintaining carts are limited to three categories: gliders, tires, and cart bodies. These influence acceleration, traction, handling, weight, and speed.
Using proprietary and open source data, Sonatype’s Research Team identifies four critical categories developers should consider when evaluating dependencies to upgrade or maintain
- Component quality
- Legal
- Category popularity
- Security scores
These factors can significantly impact a program’s
- Performance and uptime (speed)
- Security (handling)
- Compatibility (traction)
- Build time (acceleration)
Choosing the best component version in today's landscape can be a gamble. But developers can leverage statistics to improve their odds.
Let’s review the considerations that went into BOM Doctor's algorithm.
Quality (the chassis)
The quality of a component is the foundation that will affect everything from its performance to its run time. A race car's chassis is the most fundamental aspect of the overall cart. This is very similar to how the quality of a software dependency is based on the quality of the version the project is built with. To avoid bad-quality versions, a general rule is to only use a beta version or a pre-release if it solves a more significant problem. Otherwise, it’s best to avoid the latest version of a component, as it may be susceptible to vulnerabilities. BOM Doctor’s algorithm considers the frequency of release updates as a measure of its quality.
Legal
Thankfully, licenses typically don’t change across versions. But when they do, our algorithm considers this and measures the risk levels associated with its current state.
This aspect has no parallel in Mario Kart. Unless, of course, we could legally sue our friends for releasing a blue shell at the finish line.
Category popularity (gliders)
Category popularity is a factor many developers depend on. While following the crowd isn’t always foolproof, there is a certain level of safety in numbers. Sonatype’s algorithm considers the number of people using a specific version. By tracking version-specific relative popularity, BOM Doctor can consistently determine which versions are popular. As users gravitate towards particular versions for specific reasons, Sonatype’s algorithm adjusts its weighting for popularity to avoid penalizing newer versions.
Security scores (tires)
Security scoring is different from the other considerations. In this category, the algorithm takes into account the context of the dependency and combines risk factors into a combination score. For example, if one version has a high risk, and the next version has two medium threats, which one is safer? Context matters since it allows the algorithm to compare changing risks across versions.
Sonatype’s algorithm takes into account situations where these factors carry equal weight. The latest version might be risky and include supply chain attacks. However, Sonatype has a release integrity monitoring system that identifies malicious attacks. This contributes to the version's overall security risk score.
The comparison in Mario Kart is how the tires must consider the type of terrain the race is on. Without the right type of tire on the right surface, the significant risk of sliding instead of drifting can cause a player to spin out of control. Any player knows the Mushroom Cup is played on multiple surfaces, so players must choose the best tire to keep their car’s integrity throughout the competition.
How to choose the right version
There are six things to consider when selecting the best version:
- Choose a version with the lowest security risk
- Avoid pre-releases unless they solve a prominent problem
- Select a version with minimal legal risk
- Steer clear of known bad versions
- Choose a relatively popular version
- Favor a more recent version
Upgrading is challenging and expensive. Many projects hesitate to upgrade due to the daunting nature of the work involved. Factors developers think about are:
- The amount of effort required
- Whether upgrading will disrupt the build or application’s functionality
- The adequacy of test coverage
- Whether the new version complies with organizational policies
There are a lot of tools out there that are complicated and generate noise. BOM Doctor simplifies the process, focusing on effort analysis to determine if an automatable version is available or if the project will require additional work for upgrading.
Let us help select your cart
The parallels between Mario Karts and SBOM management are helpful to understand the importance of choosing the right components for the best build. Sonatype leverages proprietary data to delve deeper into open source patterns and create a customized SBOM (starting cart) like Nintendo tailors parts for their players.
With BOM Doctor, developers can experience the power to easily select parts for their "cart" and unlock a safer, more efficient development journey.
What are you waiting for? Try BOM Doctor today and “Let’s-a-go”!
