The world's largest enterprises require proof of software security before they purchase new software. Why? Because third-party software is just as vulnerable to attack as software developed by internal teams. In fact, Boeing recently noted that over 90 percent of the third-party software tested as part of its program had significant, compromising flaws. As a software supplier, how do you get ahead of this trend?
Not every supplier has the resources and maturity to develop its own comprehensive secure-development process to the level of the Microsofts of the world, but that doesn't mean security should be thrown out the window. Large, medium and small software suppliers — such as NSFOCUS and GenieConnect — have found significant benefit in incorporating binary static analysis into their development process, addressing vulnerabilities and meeting compliance with industry standards. This has earned them the VerAfied seal, which means their software product had no "very high," "high" or "medium" severity vulnerabilities as defined by the Security Quality Score (SQS), nor any OWASP Top 10 or CWE/SANS Top 25 vulnerabilities that could be discovered using Veracode's automated analysis.
This extra step to meet compliance with software security standards is one most suppliers don't even consider: it could slow down development, add extra cost to the product and potentially reveal software vulnerabilities that the producer would rather not know about. Many software suppliers vainly hope that security is only necessary for a certain class of software — a banking program perhaps, but not a mobile application. However, security is relevant to every supplier, no matter their product or industry.
Software suppliers that neglect the security of their product are in for a rude awakening when the sales pipeline evaporates because they can't answer questions about software security.
What should a supplier do to address a request for proof of software security? Here are four steps:
- Use — and document — secure coding practices when developing software. This may seem obvious, but developer documentation makes it easy to demonstrate that the software was developed to be secure from the very beginning.
- Test for vulnerabilities throughout the development process (the earlier and more frequent, the better). Don't wait until the night before your product's release to run your first security assessment, or your release will be delayed.
- Educate developers on how to find, fix and avoid security flaws. Many developers simply haven't had proper training. Make sure they learn these skills not only for the benefit of your product, but also to improve your human capital.
- Proactively communicate with your customers about the steps you take tosecureyour product. This will improve existing relationships and help differentiate your product in the market.
It's time for the software industry as a whole to embrace the trend of requiring proof of security as an opportunity to improve software everywhere.