Computer Security: Fancy dinner or burned pie?

Gosh, do I look forward to cooking for my friends and family again! Inviting them for a fancy dinner. A friends and family special. With a Caesar salad for the vegetarians; a selection of cold cuts for the carnivores; cheese fondue for the Swiss and lactose-tolerant; and, of course, meringue and double crème de la Gruyère for the grand finale! All prepared with care, love and skill, using only the very best, handpicked ingredients from a trip to the local market on a sunny Sunday morning. Preparing a many-star menu for the people I care about – a feast worthy of a chef, foodie and connoisseur.

But I’m not. I don’t know how to cook. I just know Thermomixing. And how to programme my Thermomix. I am a programmer and software developer. And if I were to cook like I programme, my friends wouldn’t come round again, not even for a simple apple pie. Because, as I programmer, I cook by picking the ingredients from random places without checking that the quality of the ingredients, their texture and taste, delicate and subtle flavours, are as they were in the past, as I expect them to be, as they should be, such that they add flavour and pleasure to my dinner. It’s more like I just memorise the location of the market stall, the butcher, the cheese counter, the fruit and vegetable seller, and buy from them over and over again. Trusting those locations blindly. And ignoring that the stall, butcher, counter or seller might have changed their quality, flavour or checks, or just simply changed place or ownership.

No cook would trust a good dinner blindly to market locations. But as a programmer I do. I automatically import software packages and libraries from any source I deem worthy. Worthy at that time, because I found the right code snippets on that webpage. I opt for automatic re-import and update using tools like NPM or PyPi. Easy as apple pie. And risky as burning an apple pie…

Enter supply-chain attacks. Relying on external software packages comes with a risk. Successful attack scenarios have been executed in the past. Packages on NPM, PyPi, GitHub or any other remote-software-provisioning platform have been compromised in the past by accepting backdoored source code into the newest release, by unverified packages and libraries, by compromising the account of the source-code owner or by handing over the maintenance of that source code to a new (evil) maintainer. Just recently, a security researcher executed a successful supply-chain attack against Microsoft, Apple, PayPal, Shopify, Netflix, Tesla, Yelp and Uber simply by publishing public packages using the same name as the company’s internal ones. He took advantage of the fact that PyPi and NPM look out for the newest version and give them priority even over a download from internal sources. Software using NPM or PyPi with internal dependencies on third-party libraries hence fetches newly released dependencies from the internet, first. All the researcher had to do was to figure out the names of those libraries, publish a more “recent” version and wait for PyPi and NPM to do their job.

While CERN was not hit, our development methods do not differ, and the risk remains the same. PyPi. NPM. Automatic internet downloads. While there are mitigations, like using central software dependency curators like Snyk or Nexus, they need to be deployed, centrally managed and curated. Any other means of direct download must be avoided. Hence, I’d like to encourage the developer community at CERN, for the sake of the integrity and security – but also for better version and revision control, dependency management, and license compliance – of the software you develop, including the packages and libraries you import, to think about this and to appeal to your managers to make such a centrally managed service possible! In the end, it’s your call: fancy dinner or burned pie? Bon appétit.

/Public Release. This material comes from the originating organization/author(s)and may be of a point-in-time nature, edited for clarity, style and length. The views and opinions expressed are those of the author(s).View in full here.