The old world of reusable IT components has been under threat for a while. While it was appreciated, efficient and effective to reuse software components written by others, attacks abusing this kind of “supply chain” are on the rise. For instance, rest-client in 2019, plutov-slack-client in 2020, atomicwrites in 2022, xzutils in 2024, chalk, “Shai-Hulud” 1 and 2 in 2025 and, since then, Trivy (security software!), litellm, telnyx, axios, Bitwarden and, most recently, RedHat cloud services. Who is able to follow up on this exponential growth of compromised dependencies? Who really understands the dependencies of their software and how to protect against them?
Actually, several incidents of exactly this nature turned several CERN webpages into phishing sites (the “Polyfill.io” attack). In another case, a software repository of CERN software hosted on GitHub got compromised and abused GitHub’s public execution pipeline for malicious ends. How can we avoid automatic tools using dependencies from the likes of NPM or PyPi downloading malicious software components and executing them within CERN’s infrastructure? How can we have at least an overview of which software components are actually in use?
We need to gain visibility of our software and their dependencies. This XKCD cartoon is emblematic of the dependency of “all modern digital infrastructure” on this one little “project some random person in Nebraska has been thanklessly maintaining since 2003”. Better visibility not only benefits security but also makes it possible to:
- discover any other (critical) (open source) software components CERN depends on, and understand the risk CERN is exposed to by using this software;
- properly plan software life cycles to avoid particular software simply becoming obsolete when replacing it is impossible (think of the SCADA software* for the cryogenics control system); and, hence:
- better prepare for business continuity in the event that access to a particular software component is denied for maintenance or licence reasons;
- trace software components subject to licence conditions and copyright, as it is not uncommon for freely downloadable software to contain parts that are subject to copyright (like the “Arial Bold and Regular” as well as “Avenir Next Light, Regular and Demi” fonts for websites and mobile apps embedded in the Oculus Unity app framework); and
- control the non-proliferation of certain critical software in line with export controls and export restrictions so that CERN can exercise due diligence in the correct use of that software.
Security-wise, better visibility would help the Computer Security Office to more quickly and effectively notify owners of vulnerable or malicious software so that they can patch or revert back. Today’s methods still depend heavily on the experience of the team’s members concerning whom to contact for which software (plus wider information campaigns via email and Mattermost to catch those who were missed). In fact, visibility would also provide the possibility to actively scan any downloaded software for vulnerabilities (or use a third-party service to do so). And any central proxy for gaining such visibility might also, if developers wish, introduce a caching mechanism that holds anything that is imported in quarantine for a few hours (a so-called “cooldown” period) to wait and see whether someone reports problems with the to-be-imported software component. A short delay to avoid a copy, commit and KO. What do you think?
*Supervisory control and data acquisition software used to run all the CERN experiments and accelerators.
________
Do you want to learn more about computer security incidents and issues at CERN? Follow our Monthly Report. For further information, questions or help, check our websiteor contact us at Computer.Security@cern.ch.