Companies that sell software for a living are gradually facing more and more pressure to cough up proof of security for their products. Working on the business development team at Veracode, I’ve seen this tidal wave growing, and my best advice to software vendors is to be proactive. If you learn what to expect and how to answer different attestation requests, you’ll be ahead of many of your competitors in the marketplace. To help wrap your head around what this could mean for your business, try to answer the questions below:
How often do you get requests for security attestation for your software?
Has it happened yet? Maybe once or twice a quarter? Do you feel that requests for proof of security will grow as time passes? If you haven’t received a request yet, rest assured, they will come. Veracode employs a whole team of application security professionals who work on behalf of the world’s largest enterprises to ensure that their software supply-chain is just as secure as their internally developed applications. We’ve seen how seriously these organizations take security, and it makes sense to think that this commitment will trickle down to smaller enterprises over time.
It’s also important to note that different companies want to see different proof. One could require adherence with the OWASP security standards, another might need you to show that no flaws in the SANS Top 25 exist in your software. Perhaps even a very picky client might say no CWE-352, CWE-89 or CWE-306 can be present. Would you know where to look in order to comply?
How Veracode can help: The Veracode Platform has out-of-the-box policies for common security standards and allows our customers to be granular enough to disallow specific CWEs as well. The ability to customize reports on a customer-by-customer basis means you can get proof out the door in a timely manner without slowing down any sales cycles or contract negotiations.
What’s the impact of failing a security audit?
Maybe you haven’t received a formal request from a specific customer or seen an RFP question relating to application security. But your organization could be subject to other types of regulation. PCI, HIPAA, SOX and others include language related to software security. Aside from some hefty fines and potentially losing big-name customers, what kind of impact would failing or inability to provide security reporting have on your company?
How Veracode can help: Payment Card Industry – Data Security Standard (PCI-DSS), for example, includes many items that relate specifically to software security and developer training. To address PCI-DSS 6.5, Veracode Static Analysis enables your developers to identify and remediate application security flaws. Veracode Developer Training helps developers, testers and security to learn the skills they need to understand and address vulnerabilities and achieve the training requirement of PCI-DSS 6.5. Not to mention, Veracode’s ability to integrate with GRC frameworks gives your organization a single view of all pertinent security reporting standards across the organization. These types of tools, training and integrations allow software vendors to deliver applications at the speed to compete without sacrificing security and facing the failure of an audit.
How do you support your development teams in terms of understanding and remediating security flaws? How do your provide them guidance on what to fix?
We all know that the shortage of security professionals is a real and serious problem. Finding folks who are experts at application security is an even smaller niche in that market. It’s rare to find an independent software vendor that has an AppSec expert on staff. So how do companies figure out what to prioritize, how to meet a specific requirement and, most importantly, how to fix the vulnerabilities getting between them and compliance?
How Veracode can help: At Veracode, we have teams of application security consultants and program managers who work with our customers to prioritize and fix vulnerabilities, and address regulations. Our find-and-fix mentality is cheaper than an ad hoc approach, and higher/quicker remediation rates help to reduce your surface area of risk. This adds up to a shorter sales cycle for ISVs as the ability to meet compliance becomes easier and easier.
The Veracode approach allows customers to be proactive where it matters. It’s impossible to eliminate every security defect in your code. But when your business depends on the software you sell, it’s critical to understand your customers’ requirements and how to meet them. Get ahead of the game, and don’t let a security request bottleneck the business.
Ready to move from reactive to proactive AppSec? Get advice from someone who’s been there in our new eBook, 5 Lessons From an Application Security Pro.