Software supply chain attacks have been a talk of the town since start of 2021. Starting from SolarWinds attacks (refer
here and
here) and the topics have just not stopped being in limelight. Software Supply chain attacks are basically targeting entities which are not in your direct control but are a major contributor in your application development process. This includes but not limited to:
- Development Tools (IDE’s, supporting tools..)
- OS repositories (Debian / RedHat / Chocolatey repositories…)
- Language specific repositories (npm, php, ruby, python pip…)
- CI / CD Tools (Jenkins, TravisCI, TeamCity…)
If we consider these, the typical supply chains go 2-3-4 or more levels deep in terms of vendor connections. There is no straightforward way to detect and preemptively protect yourself against such attacks. (Haroon also deliberated on this
here and
here)
Haroon has painted a very grim but very real picture here
The current focus on “supply chain” security will no doubt see the VC-backed creation of next-gen start-ups claiming to solve the problem, but this part of the problem seems intractable. There’s the “easy” suite of software you know about: applications installed on your infrastructure and their dependencies. But, for one, this ignores your vendor’s own vendors. In addition, what product is going to provide guidance on the provenance of the code running in your monitors (on processors we didn’t even know were there?). Will we examine the firmware on the microphone that people are now using for their Zoom calls? Will we re-examine it post-automatic-update? There are way too many connected pieces of code to tackle the problem from this angle.
While we are on “attacks on supply chain systems” some interesting references I would like to add.