The realm of application security and cybersecurity is littered with promised silver bullets. New technologies come along and promise to solve all your old security problems and world hunger as an extra bonus. Too often these technologies actual value remains obscured by snake-oil marketing making bold promises as a way to gain market share.
Those who’ve followed me for any period of time know my low tolerance for snake-oil claims. Things like metrics that will point to all your bugs, or static analysis that will eliminate all bugs or allow you to prove that your application is bug free at a few that persist in software development.
These simple solutions find an audience because security is a difficult tedious problem that requires mature thought-out processes and actions. Most security incidents occur not because a super villain targeted an organization with a complex campaign, but because the organization failed to follow best practices like keeping patches up-to-date, having rational password policies (8 characters in this day and age? Really?) and doing secure software engineering like static code analysis or SAST. It’s much easier to hope that you can buy a tool and it’ll just do the job for you. But it won’t. That tool doesn’t exist. For the last decade we’ve had failed SAST organizations buying and building other technologies that properly complement SAST but they’re selling them as a replace because they failed in their SAST business.
Don’t misunderstand me – SCA is just the latest tool in your cybersecurity toolbox. It’s an important addition to what you’re doing and was definitely missing in a world where everyone is using some amount of OSS components. However I fear that its real value will be destroyed by the marketing hype as vendors who are snapping up SCA tools try to sell it as the total final solution to software security problems.
Yes, SCA is important. You should do it. If you’re not doing it, you’re missing the boat. But don’t expect it to solve all your problems, or replace even a single one of the tools and processes in your secure software development lifecycle, because that’s not what it is for. It was created to fill a gap, not replace existing tools and processes. Simply put, software composition analysis finds open source packages in your application (some tools look for other than OSS, but most do not) and then checks for open issues in the form of CVEs against those projects. In other words, SCA looks for known problems like an anti-virus tool would. It doesn’t actually check the security of your application, just the patch level. (Note, some tools also do OSS license management. This is also an important issue, but it’s not a security issue, it’s a business problem.)
As always, beware someone with crazy promises of simple solutions to complex problems. For fun you might want to read my rant on this in SD times. No, this isn’t a rant, when I’m ranting you’ll know it.
Stay secure out there.
Any opinion about CodeMRI? Seems to be a legitimate tool for some purposes, but I’m wary of snake-oil.
Can you refer me to anyone who uses or used Code MRI?
I’m active in SQGNE, where you’ll be presenting May 19
I haven’t used it and I checked around but didn’t find anyone I know that has used it. Probably because it seems to be more targeted toward M&A rather than quality or security.