Security: How safe is your vendor’s source code?
The real issue here of course is not that source to a popular AV app has been stolen – the core problems, that a lot of the commentary seems to be missing, is that of due diligence and vendor control.
Most companies will do some sort of due diligence on their suppliers. It varies between industries, and what the software solution is going to be used for – but usually things like credit checks, lists of reference sites, etc. are done. Depending on what the software does, the due diligence can also include things like looking at recent security audit reports, viewing physical and virtual site security procedures, and sometimes even penetration testing of the vendor.
But how many companies check who else has their vendor’s source? Is it held in escrow somewhere (which is very often a contractual requirement)? How secure is the escrow provider? Has the vendor done any deals with third parties that gives them access to the source? How secure are *they*?
Symantec’s problems are much greater than the loss of the source to an older version of Norton’s AV. They’ve suffered reputational damage because of the lapses of a third party – something they have no control over. The damage here is particularly severe, because Symantec have been growing their enterprise security business.
Customers will be asking awkward questions about how much of that Norton AV source has made it into Symantec’s other enterprise solutions. They’ll also be asking Symantec what other products the breached third party had the source to. These concerns will count heavily against Symantec in any competitive tender, and the damage for Symantec will continue for a long while after the noise around this breach has subsided.
The lesson to be learned from this – for both customers and vendors – is what impact loss of control over your source code has on your security stance, and the risks that that poses to your business. Both of these need to be factored into any vendor assessment and risk analysis.