It’s been over 20 years now since we as security professionals have been including SDKs in the software code that our development teams have been writing. In fact, looking at the ACM paper from the year 2000 [1] one can easily venture a guess that SDKs existed even pre the Dot Com Boom in 1999/2000. These are old-world concepts, and in the socially connected, real-time lives we live now it seems strange to refer to something from the aforementioned stone age – this begs the question, why?

It’s certainly not a novel concept and more importantly not an idea only related to the realm of computer science for that matter. When we build a home or cook a dish, we do source our supplies like cinnamon, vanilla, turmeric, garam masala, and more from different suppliers and from different parts of the world. Well, truth be told it seems like McKormick has more or less a monopoly position when it comes to grocery store spice shelves in America. This though illustrates the point that when baking a cake for your precious 3-year-old, and if the powers that be command you to procure the best of the best Vanilla available, essentially Tahitian vanilla beans that are derived from the vanilla plant in Papua New Guinea, you may have to perform calisthenics in order to absorb that ingredient into the “supply chain” which will ultimately allow your household to bake the most delicious vanilla cake ever made.

The point being – you don’t grow your own vanilla, do you? You absorb ingredients and processes from vendors to finally make what you intend to. This supply chain is present in every aspect of life – home construction, cooking, clothing – you name it – there is a supply chain behind it. This is the exact same case with software today.

We no longer write all the software we need in order to perform tasks that are not core to our business. Ever been to a banking login page, ever been asked for Two Factor Authentication? That’s a classic case of the Bank or service using a 3rd party vendor to accomplish a task that the Bank does not want or need to be an expert at. So the question is then, what’s in your software – are you using pre-packaged code or services that your own product depends on to make sure you can perform the basic functions for your revenue generation goals? How dependent are you on these 3rd party pieces of code? Are they safe and compliant with your policies? The list of questions can be endless.

In our survey, 95% of companies clearly admitted that they were using some kind of 3rd party computer code or service in order to power their own revenue generation services. In fact, in the vast majority of cases, it is extremely rare to find a complete list of vendors, data interactions, dependency information, compliance postures for all your 3rd party interactions. Let’s try to understand why it is so difficult. 

Computer code is not some lifeless piece of rock – it is ever-changing – like a coral reef. Every feature that we interact with on most services has been updated in the past few weeks or months at most. Computer code always changes – why? – to provide better, faster functionality, a better user experience, to launch new products, and more. Speed is key. It is in the pursuit of the speed of deployment, launch, and capturing revenue that it makes perfect sense to use what someone has already developed and focus on your expertise and build your own secret sauce. Ever heard of re-inventing the wheel?

Let’s talk about different domains in which this discussion makes sense. Health care is a prime example – how does understanding the Software Supply Chain matter?

Most large organizations must focus on a couple of areas to understand their security posture and protect against software supply chain attacks – a) keep an inventory of the various libraries and the corresponding applications where they are used (clean and up to date CMDB for the codebase) b) include all 3rd party integrations in the overall enterprise’s continuous monitoring program. In fact, most healthcare organizations are aware of HiTrust guidelines and do try to align their security and audit programs with these recommendations. HiTrust clearly defines the need for constant monitoring. When dealing with similar guidelines for ISMS and QMS healthcare companies need to understand the risk exposure they have as a result of using these 3rd party building blocks in their codebase.

Well is this all a one-trick pony? Not really – what about large technical enterprises, why should they care to understand the lay of the land?

We have discussed in this article where are the pertinent areas for investigation when it comes to securing the digital supply chain for healthcare companies. If you would like to share your experience in this area or would like to explore how a complete platform can assist you in your security programs to achieve HiTrust compliance and more – please feel free to get in touch with us at sales@riscosity.com or at +1-888-RISCOSI (888-747-2674).

Authors: Ravi Gunturi, Atif Yusuf, Anirban Banerjee

[1] Benso, A.; Chiusano, S.; Prinetto, P. (2000). “A software development kit for dependable applications in embedded systems”. Proceedings International Test Conference 2000: 170–8