The car has no seatbelts, no brake pedal and, on closer inspection, no brakes of any kind. Do you listen to the salesperson drone on about how powerful the engine is, or do you buy a different car?
The same principle applies to software, Peiter “Mudge” Zatko, the well-known l0pht hacker and software security expert who has worked across industry and government for the last twenty-odd years, tells CSO. Checking for basic security features before buying software can and should be part of the enterprise purchasing cycle.
Doing so is not labor- or time-intensive, either. Evaluating software binaries for basic compile-time security flags is as simple as running existing open-source scripts against the binaries in question. While this won’t offer a comprehensive analysis of the software, it will tell you whether the software maker has bothered to do the bare minimum. If they haven’t bothered to do the bare minimum, that is a huge red flag, Mudge says.
“This stuff is so basic (fundamental) that the checks are the same on both sides,” Mudge tells CSO, meaning that the security checks a purchasing organization makes are the same checks a software maker should make before releasing their software. “It’s like looking in a car to make sure it has seatbelts and looking to make sure there is a brake pedal and some disc brakes on the wheels.”
“[These checks] should be done by the manufacturer before being sent out to be sold,” he adds. “Blame is also on the consumer if it’s missing and they couldn’t be bothered to look (since there are no mandated safety laws here).”
