Lever le voile sur les cybervulnérabilités des pipelines de la chaîne d'approvisionnement du gouvernement

A version of this article appeared in TechCrunch. It has been updated and syndicated here.

‍

As if we hadn’t had enough disruptions in the Year That Cannot Be Named, 2021 started off with a deafening bang for the U.S. government, in the form of one of the worst data breaches on record. The SolarWinds incident was a devastating, sophisticated nation-state attack that sent several government departments and large organizations into a panic, scrambling to secure their endpoints. Virtually every end-user of the SolarWinds software was compromised, and the incident made it abundantly clear that cybersecurity and defense in software supply chains are critical.

It’s obvious that cybersecurity is important, but what does it actually mean in the context of supply chains?

The state of cybersecurity in the average development team

An enormous amount of software is being produced every single day, representing billions of lines of code every year, and that is only increasing with the demand created by our progressively digital lifestyles. The global developer population is on track to swell to almost 29 million by 2024, and currently, no formal certification exists to assess and certify their ability to code securely. That’s not to say that every developer produces or re-uses insecure code, but there is undoubtedly a sustained risk that basic security weaknesses can be introduced into the software we trust with our data. 

Developers are assessed on their ability to create features and ship code as fast as possible. Security hasn’t been a benchmark for their success in most organizations, but that sentiment is starting to change as more companies realize the potential they hold in preventing common security bugs at the earliest stage of software creation. However, realization and implementation are two different things, and since most tertiary development courses omit any context around secure coding practices, it’s often up to a developer’s workplace to make up the shortfall. If skills building and knowledge sharing are infrequent or irrelevant, then it will likely be ineffective. And so, the cycle of recurring vulnerabilities through lack of skill development remains unbroken. 

Naturally, it is not the responsibility of your average software developer to solve the world’s cybersecurity woes; after all, organizations hire those very expensive security professionals for a reason. Security gurus are in short supply, however, and developers can certainly play a role in reducing the strain. 

But where does this leave us - and the vendors creating software for critical infrastructure and sensitive organizations - in terms of preventing a devastating cyberattack? It’s going to require a shift in the status quo of software procurement, at the very least.

The pitfalls that stand in the way of a secure software supply chain

The tired adage of a chain only being as strong as its weakest link is, unfortunately, just as true when it comes to software supply. It really doesn’t matter if your company has come to the party with beefed up security best practices, investment in developer upskilling, and a move towards a functional DevSecOps environment (i.e. everyone sharing the responsibility for software being made as securely as possible); if you use software from a vendor that has security problems, you will inherit them into your ecosystem and bear the consequences.

Sure, the security team should be helping to assess the safety of third-party additions to the tech stack, but decisions can be made based on a business need with little choice among solutions. At this point, it can be a trust exercise. Does the vendor care about security as much as your company does? And can the vendor actually assess the risks as only you could understand them, as well as the assets you need to protect?

Transparency is an all-important factor in assessing the security viability of vendor software additions. Are they up-front with their own security practices? They should take pride in their approach to keeping data safe, and it should be a top priority. If the security practices are not published anywhere, or no information is available, there is a strong chance that security is not top-of-mind. The vendor should be able to answer technical questions, and independent certifications like ISO27001 and SOC2 wouldn’t hurt either. Also, if you can’t “look under the hood” and scan for vulnerabilities as part of your own internal due diligence and security practices, forget it. 

With demand driving such fast-paced implementation of software needs, especially if vendor code is being folded into existing systems to perform actions in a new context, both the vendor and buyer need to be at the top of their game, and both should have their developers as the boots on the ground to pick up common security bugs and flaws before they ship. There could be hundreds - or thousands - of dependencies compromised if a new addition to the existing spider web of tech solutions is added to, and one small failure could lead to a catastrophic undoing. 

So, what’s the solution? Code everything in-house, from scratch? If it was 1998, that might make sense. However, just as we no longer “Ask Jeeves” where the closest car wash is, we need to implement realistic safeguards that work in today’s context.

There is still no silver bullet, but there are solutions

For buyers, security assessment of vendor software and development practices should be a priority of the overall security program and risk mitigation plan. Ask questions around their certifications, practices, and security reputation of their developers.

Vendors (and indeed any companies creating software), must be prepared to demonstrate that security is top-of-mind, and should focus on upskilling. Security-skilled developers are in high demand, and with the right tools and support, they can be built up from your existing team and empowered to defend against attacks resulting from common vulnerabilities. But don’t throw any old training at them. Give them time to thrive with security tooling that is complementary to their existing workflows. Make it as easy as possible, and watch those pesky bugs start to thin out among the code powering the business.

The bottom line is that any software risks are immediately exacerbated if they are part of the supply chain, affecting all users and any systems where vulnerable components have been utilized. If vendors aren’t as serious about security as the companies implementing their software - or both the vendor and organization are lacking in their security program - then more  devastating, far-reaching supply chain attacks like SolarWinds will inevitably become the norm - and this is a critical problem for everyone.