Here’s a supply-chain vulnerability just waiting to occur. A team of analysts looked for, and subsequently registered, neglected Amazon S3 storage buckets for around $400. These storage spaces housed software libraries that remain in use. Presumably, the projects involved are unaware that they have been deserted, and continue to send requests for patches, updates, and so forth.

The summary is that this time, we came across approximately 150 Amazon S3 buckets that had previously been utilized across commercial and open-source software products, government entities, and infrastructure deployment/update systems—and were then left unattended.

Of course, we decided to register them, simply to observe the outcomes—“how many individuals are genuinely trying to request software updates from S3 buckets that seem to have been forsaken months or even years ago?”, we innocently mused.

It turns out they received eight million requests over the span of two months.

If this had been a genuine assault, they would have altered the code within those buckets to include malware and monitored its integration into various software builds throughout the internet. This is fundamentally similar to the SolarWinds incident, but significantly broader in scope.

However, there’s an additional aspect to this threat. Since these update buckets are neglected, the developers utilizing them have also lost the capability to patch them autonomously for protection. The method they would typically employ to do so is now under the control of adversaries. Furthermore, often—but not invariably—losing the bucket they had used for updates also strips the original vendor of the ability to pinpoint the vulnerable software in the first instance. This obstructs their capacity to communicate with affected installations.

Software supply-chain security is an utter chaos. And it won’t be straightforward, or inexpensive, to resolve. This suggests that it most likely won’t be. Which leads to an even more troublesome situation.