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.
Organisations can end up with a confusing software supply chain, or even a supply hyperbolic plane where it is hard to tell where the touchpoints start and end. Organizations can end up being multi-cloud by accident rather than by design. The proliferation of multi-cloud can lead to issues in managing and securing traffic between clouds as well as the customer, so it is important to address the issues earlier on rather than trying secure an accidental multi-cloud architecture. Additonally, customers are becoming more confused and concerned about supply chain issues with their cloud vendors as well as physical production lines.
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?
Who has the role of knowing what ‘good’ looks like? This is a first step in understanding who owns the issue, and who is accountable. Is it the developer’s problem to solve? Often, developers can find it hard to get sign-off for what they would like to do. Developers can be influencers in decision-making but without any real sign-off authority. Organizations can often spend a lot of money to enhance their branding at tech community to woo developers. However, this strategy is often mistaken since they aren’t talking to decision-makers, and developer requests for funding will only go so far. If you are the IT leader, where are you pushing? Many businesses have a bad habit of running servers and WiFi equipment until they are ‘end of life’ – or even beyond. This strategy looks like it ‘works’ because things keep running, somehow. It is not good to carry that strategy over to multi-cloud architectures since organizations should be continually reviewing their architectures to achieve the best results for their business.
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?
Protection or the organisation, suppliers, vendors and downstream data consumers should be of the DNA of the organization. This is a crucial issue of supply chain in multi-cloud environment, so it needs careful management. In our experience, customers do not review contracts well enough, believing that their cloud supplier is more responsible than they actually are. In our experience, organizations like AWS, Snowflake and Google offer stellar support and go ‘above and beyond’ support, helping with wishlist items. We do find that Microsoft Azure support is often a hotchpotch of Azure support trying to meet KPIs rather than offering a customer-centred support. Ultimately, this doesn’t reflect well on the leaders who chose an incorrect cloud support strategy in the first place, and the last thing that many business leaders want is to be embarrassed in front of their teams. So, it is important to carefully reflect on expectations on support in multi-cloud businesses for people reasons as well as technical and business reasons. Security teams are not the only people responsible, however; the developers should also be included in cybersecurity strategies. One way to do this is to consider security as part of DevOps processes, and this includes the supply chain. This strategy could include software from IoT and the Edge right through to the business user. Again – because it needs to be repeated – the developer should be a part of the process. For the organization, does this mean simply changing responsibilities or reducing them? What is the role of the user? Say, a barrister may not be a client, but they may have access to the data via a third party. In terms of ethics and responsibility, what does this mean if one cloud behaves badly, people can go to another cloud? Users want a frictionless experience, but they are increasingly likely to align themselves with organizations that are seen to do good.
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.
