The multi-cloud question in THE SOFTWARE SUPPLY CHAIN
Nowadays, we now take it for granted that we go to the cloud. The question is no longer “should we go to the cloud?” although we do meet customers who still need some help to get there, and who need to understand which cloud suits them best. Businesses need to maximise their multi-cloud investment because this will create a software supply chain where the organization is consuming software that intersects. Organisations are now looking at how they manage multi-cloud estates rather than a single cloud, and considering their software supply chain.
When businesses get into discussion with cloud vendors, they can often get dazzled by features which neatly deflects and distracts away from broader multi-cloud questions. In this post, we address some strategic questions that go beyond the snazzy features.
who needs to own what 'good' looks like?
Open SourcE supply chain attacks in multi-cloud environments
Businesses need to be very sensitive to the challenges in adopting open-source software from a cybersecurity perspective. Developers can also inadvertently introduce issues when they introduce open source technologies without oversight, or checking for current and future vulnerabilities. One area is the open source supply chain attack, which is a way to attack software by taking advantage of weak elements in the supply chain to attack more substantial parts that they supply.
A supply chain attack targets weaker aspects of the customer’s supply chain. The attack identifies and targets a worthwhile package. Then, the malicious payload surreptitiously creates a new release. By delivering malware through trusted open-source channels, they become harder to identify and resolve, as automated searches designed to catch out issues do not discover them. Consequently, they often remain undiscovered until they are serendipitously stumbled upon. They can remain in situ for a long time, unfortunately, before that happens.
Where does the responsibility start and end?
Do you ‘pay it twice’ or ‘pay it forward’ for your organization?
Often, organizations are happier to ‘pay it twice’ rather than ‘pay it forward’. This means that there is always budget and time to do something again rather than doing it properly the first time. Again, this is where developers don’t have a strong voice. To get things done quickly, code can often be shovelled out to create some new feature dreamed up by the product manager and the marketing team.
As a strategy at Data Relish, we set aside every fourth sprint to tackle burning issues that generate technical debt and data debt. Here, we give developers a strong say in the activities completed during the fourth sprint. This, of course, deviates from standard agile since we aren’t following always what the Product Owner wants to do, which is normally to push out more and more features. Instead, we find that developers are happier and more productive when they are more confident about the products they produce, so we endeavour to give them time and space to deliver as strongly as they would like.
Rules and more rules
One area of progress is in the regulatory business. If your organization is in the area of regulatory risk, then supply chain issues in multi-cloud technology estates are becoming more widely discussed in order to reduce risk. It is wiser to get out in front of the issues, rather than playing catchup.
Is your multi-cloud architecture insured as well as you think?
Another area to consider is double-checking what your cybersecurity insurance actually says, and double-checking your responsibilities.
Recent conversations with business owners have shown that insurers are now requiring Cyber Essentials as a minimum, prior to providing cybersecurity insurance.
One prospect did tell me that he wasn’t worried about GDPR because his cybersecurity insurance would ‘take care of it’ but I’m not sure that’s true! He had obviously not read his T&Cs. We do not often fire customers or prospects but, in that case, we did. Risk reduction is important for us too, and it’s hard to work with people who aren’t taking ownership of their responsibilities and leading other people not to do the same.
Dependencies
As part of an ongoing process, it is crucial to review software dependencies regularly to prevent cybersecurity breaches and damage from malicious software and its consequences. For this purpose, having a private and complete software bill of materials (SBOM) affords better understanding of the overall technical architecture in its planning and design stages.
Get in touch
Do you know your software supply chain, or is it turning into a supply hyperbolic plane? Also, open-source can appear unruly due to its nature, and there is a need to bring a degree of extra control to inspect and manage the supply chain.
Let us know in the comments. As always, please get in touch if you’d like to learn how to make your data work in multi-cloud environments.