In 2014, Lenovo decided to trust third party software.

What became a severe security incident, started when adware from a company named Superfish was installed on Lenovo laptops, ostensibly “to provide users with real-time price comparisons”, but with a nasty side-effect of breaking encrypted traffic by producing fake certificates. Superfish, ironically, blamed the incident on, well, them trusting third party software, from a company called Komodia.

Three years later, headlines about the rise of DevSecOps are usually sandwiched between accident reports that have company A apologizing or deflecting blame for security incident that was caused by replacing security practices with trust in a 3rd party.

There’s no way to curb the ever-expanding reliance on third party software, nor is there a reason to. Vendors, striving to provide ever-richer offerings to their customers, and constrained by budget as well as time, turn to partnerships and third party libraries, which benefits the industry and creates healthy partnerships.

The Customers Don’t Care Who’s Really to Blame

But with DevSecOps teams still not ubiquitous, the people who make the decision to integrate a 3rd party product aren’t necessarily the ones responsible for security. And oftentimes, they simply don’t treat the integrated product as a security risk to their own customers.

And oftentimes, it really isn’t. But when it is, the affected customers don’t really care whose product caused them harm. They trust the brand on the label – it gets the accolades for the stellar performance of good third party products embedded in it, but also gets the brunt of the blame if anything goes wrong.

Risks Are Necessary, Except For The Ones That Aren’t

It would be ridiculous to ask vendors to lower their reliance on third party code. The industry is more globalized than ever, with talent found all over the world. But a vendor should realize that the third party will never be held responsible in the eyes of the users, and start treating that code with the utmost suspicion, until it’s proven safe. It’s their reputation on the line, after all.

There’s no easy way to do it. Not really. Having access to source code reduces the complexity of the task, with excellent static code analysis software already on the market – from Checkmarx, through Veracode and to Micro Focus. Web attack surfaces are well covered as well, with tools like Nessus and IBM AppScan. But what to do with those pesky closed-source binaries?

The default way of ensuring program security in this case is to think like a security researcher, or pay researchers to do the thinking for you. Up until a short while ago, it was  a lengthy, manual and often very costly process. Recently, though, there have been a few developments.

 We, at Cybellum, are trying to make risk assessment easier, with an automated DevSecOps-oriented platform that automatically detects vulnerabilities. Others are now launching their own solution, such as Microsoft’s Security Risk Detection cloud tool, with the express purpose of risk assessment for 3rd parties.

 At this point in time, it seems that the technology has actually surpassed awareness of both the problem and its solvability. The excuses for not treating third party software as a major security risk are wearing thin. And customers? They remember when their brand failed them, even if it was someone else’s fault.