Last Updated on January 14, 2024
Many organizations that are embracing a microservices approach to software development are decomposing their applications into components implemented as microservices. Which then communicate using APIs.
In short, microservices are the functions and API calls (among various ways of exposing functions) are how we access them. Often some of these microservices have integrations with third-party code, SaaS solutions, and so on.
By creating significant interconnections and data movement between “trust areas” both inside and outside a company’s network, this scenario changes the risk level and the security requirements for software. Because, in effect, it’s now borderless.
Supply chain risk with microservices
Because of the “inheritance chains” that potentially link microservices with vulnerable third-party code, managing software supply chain risk becomes extremely important.
“That’s why we’re seeing it echoed through the guidance coming out of the Cybersecurity and Infrastructure Security Agency (CISA), the executive order from President Biden,” Laura comments. “That software supply chain thing that we’ve been tangentially aware of for awhile… We’re really now starting to realize the impact of it.”
With vulnerabilities like Log4J as reminders, the ripple effect of software supply chain impacts can be massive—and it will take a collective effort across the cybersecurity industry to effectively understand and manage software supply chain risk.
“Checking out and understanding your [software] supply chain and understanding your dependencies is a huge, ongoing, very fast-evolving place,” relates Laura.
SBOMs and microservices
Software supply chain risk management is increasingly aligned with the idea of a Software Bill of Materials (SBOM). Bills of materials are a shared responsibility across the supply chain in mature industries like manufacturing. But the software marketplace is more uneven in terms of vendors’ process maturity and availability of resources to risk by tracing down their dependencies.
Laura sees “an implied responsibility on us as organizations to look at those components [of our SBOMs] and go, ‘Right, which of these that we absolutely are reliant on need a little bit of extra help? Can we provide funding to an open-source project to help them up their game?’ Because if we don’t do that, having the list won’t necessarily help us protect from vulnerabilities. It would just help us know what to watch for on the monitoring lists.”
What’s next?
For more guidance on this topic, listen to Episode 119 of The Virtual CISO Podcast with guest Laura Bell Main, CEO at SafeStack.