We often go to restaurants and treat ourselves to unfamiliar and exotic foods made with ingredients we’re only vaguely aware of. A chef and their team (or a manager and their crew) are our vouchsafe that what’s in there isn’t deadly. Most of the time, that works out just fine; but, very rarely, we end up paying the price. The same is true for food brought home from the supermarket, though for lesser illnesses it is harder to track because they’re not clustered like restaurant customers. While it is indeed exceedingly rare for the results to be fatal, the CDC estimates that around 3,000 people die of food-borne illnesses in the U.S. each year, and millions more are made ill. The U.S. has incredibly safe foods, and yet, we still have these illnesses. Simple things like leaving ingredients out too long, or consuming food sourced from a contaminated production facility can cause problems, even in an otherwise safe environment.
Our code is similar—how it is created and consumed—and increasingly falls in this category. We rely upon a ton of sources for the systems that run our networks, and, quite often, there is no one to tell us how safe our sourcing is, or if changes are happening beneath that escape our notice.
This is why we absolutely must have software composition analysis (SCA). If no one else is going to stand up and verify the safety of all that code we are pulling in, then we need to at least be aware of what is there. We need to understand the inter-relationships of pieces of underlying software, both the known and the unknown. Some libraries are so ubiquitous that you are using them and likely don’t even know it. But that’s not good management; knowing what you have and taking care of it are increasingly becoming a core part of IT. Knowing what alternatives are available in case something goes wrong with your preferred (or automatic) inclusion is imperative for continuity, making SCA a critical part of continuity planning along with the fact that it’s just good business practice.
The good news is, if you are using any of the major code scanning tools from the DevSecOps space, you either already have SCA available to you, or you can buy it as an add-on from the same vendor. Hit their website and find out.
Your systems are out there, every day, serving the needs of your users. Protect those users from unforeseen circumstances like vendor issues, open source changes, security vulnerabilities and nested dependencies. While the vast majority of open source is safe and secure, we use so much of it—and the tools we use link in so much of it—that it’s almost certain there is a bomb hidden somewhere in your code. Think of it like the food-borne illness example above: Would you eat at a restaurant that said “Yeah, 90% of our food is safe, but we’re not sure about the other 10% …”?
You’re building astounding things, and keeping the world moving. Don’t stop, but don’t let your guard down, either. Know what is running in those apps, what its vulnerabilities (both security and downtime) are and what you can do to mitigate those weaknesses–so you can keep making astounding things rather than spend your time fixing what is already there.
