There’s a significant effort underway right now to increase secure development and secure software supply chain practices in our world. How is this different than every other security effort, why is everyone talking about it and why is it so critical?
I had a chance to discuss this during my virtual Black Hat 2022 presentation recently. And I want to share some key points with you, in the hopes it will help your work within the software supply chain and make all of us more secure.
As Vice President of Product Security at BlackBerry, this is in my wheelhouse — and actually, it often involves wheels. Our safety-certified real-time operating system (RTOS) technology is in more than 215 million software-defined vehicles (SDVs) on the road today, and our cybersecurity platforms secure everything from SMBs to federal, state, and local governments around the world. Whether you need to secure many products or a single one, supply chain security is more closely examined now than ever, and that is here to stay.
The Push for Improving Supply Chain Cybersecurity
U.S. Presidential Executive Order (EO) 14028 is the driving force behind a significant U.S. movement to improve the cybersecurity and integrity of the software supply chain.
However, it is important to know that this is not like a typical ISO standard, or annual certification, where you can engage a third party to get something in writing or receive a stamp of approval once every year or two. This is much different.
In this case, procurement is acting as a gatekeeper for the U.S. government in all software sales. Also, requirements will include ongoing attestation that software developers are following the National Institute of Standards and Technology (NIST) guidance, and artifacts will be used as the “enforcer” of this approach.
How Should We Approach Software Supply Chain Cybersecurity?
One of the interesting challenges is to ask ourselves, as a software industry, how should we think about this challenge from a business perspective?
For starters, I suggest thinking of it from this point of view: “If I purchase your software, what risks do you introduce from your suppliers and your software supply chain into mine?”
And we should look at this question while swapping out at least three different “hats” that we might wear in a software-related transaction: the hat of a software producer, the hat of a software supplier or seller, and then the hat of a software consumer.
I walked through an easy-to-understand approach to this process in my 15-minute presentation at Black Hat and offer that here in hopes you will give it a look.