The wrong way to do software security

There is yet another example of how so-called ‘hacker’ laws can actually diminish security.

According to a post on DarkReading, a researcher who goes by the name of Acidgen is being threatened with criminal and civil suits by a firm whose software contains a security vulnerability. Acidgen found the stack buffer overflow in Music Maker 16 and made the mistake of telling the vendor, Magix AG.

Not only did Acidgen give the Magix a full description of the firm’s faulty software, he also provided exploit code and offered to help fix the problem.

So how did Magix react? By threatening Acidgen with Germany’s three year-old hacker law - the same one that makes it illegal to possess tools commonly used by security researchers, such as NMAP, Metasploit or Nessus, just because they’re also used by black hats.

This response by Magix isn’t just arrogant and stupid - although it’s certainly both of those things - it also shows a callous disregard for the safety of the company’s customers.

If there were any justice in the world, software firms would be liable for the security of their products. If there were genuine civil or criminal consequences for pushing out code with security vulnerabilities it might finally persuade these firms to invest in proper security training for developers. And they might actually get around to doing genuine risk analysis and security audits as part of the Software Development Lifecycle (SDLC).

As things stand, software companies are too focused on shipping their code. Security is an afterthought, if it’s considered at all. It needs to become an integral part of development processes and culture.

Magix needs to understand that Acidgen is not the chief threat to its customers: Magix’s own shortcomings in shipping faulty code is the problem. The company should own up to its responsibility to ensure its software does not put its customers at risk, call off its attack lawyers, thank Acidgen and fix the problem.