Last week I took some time to answer viewer questions from my webinar, “Secure Agile Through Automated Toolchains: How Veracode R&D Does It”. This is my second post to respond to questions from the webinar so if you haven’t yet read the the first one check it out here. My first post focused on questions regarding integration with environments such as Microsoft Team Foundation Server, Maven and Bamboo CI. This post will focus on other broader security and platform questions that came up during the webinar. Without further adieu, let me get to your questions. Q: What is your recommendation for the ratio of application security specialists to developers? Do you have any other recommendations to scale code scanning across a large organization with a limited number of security experts? A: That is a great question and one that many of our customers face. The ratio that we would recommend depends directly on the level of security knowledge within your development teams, their size, the length of your sprints and the frequency of your releases. I would recommend starting with one to cover every handful of teams and grow the program as needed. I also recommend leveraging Veracode’s expertise and services. Our services allow enterprises to scale application security across a diverse portfolio and development teams that range in security expertise. With this model large customers have been able to statically analyze and remediate over 1,000 applications within one year of working with us. My biggest recommendation for scaling your program successfully is to integrate static and dynamic scanning into your SDLC. If you help developers perform their scanning inside of their current development tools, they will use it automatically. This frequent interaction with security results will help them become more aware of correct secure coding practices. Q: For sandbox a developer is always making changes many times … how do you determine best way to upload and scan so that they get back results in timely manner? If we do 3 builds in 30 mins (CI) how do you design Jenkins/Veracode to get results for multiple builds? A: We encourage developers to scan their code prior to checkin. If they do then your Jenkins release candidate scans will just verify that no flaws were accidentally introduced in the merge. The majority of scans done on the platform finish within 4 hours. If you have a development process that is faster than that you may want to develop additional criteria for scanning with Veracode. One thing to keep in mind is that we perform a deep data and control flow analysis across the boundaries of individual files and components. Fixing some of the critical issues, review and coordination with other developer may take longer than 30 minutes. For these reasons we have had customers who run the Veracode integration process on a daily and/or weekly basis. Q: How does Veracode compare to solutions like Coverity and Klocwork? A: Coverity and Klocwork started as solutions focused on software quality. Veracode technology is designed specifically to address application security. Note that Veracode offers a complete package as a part of our solutions – a package that includes not only technology, but also security expertise and services many of which are included with each application that you upload. We understand that application security is a significant challenge and we believe that you can be successful and scale only with a combination of technology, expertise and services (SaaS). Q: What version of C# do you cover? A: Veracode is always looking to improve our support. Currently Veracode Static Analysis supports .net Framework 2.5 and newer.
Q: What is the level of collaborative customization allowed by the policy engine in this implementation? Can individuals/teams/project customize rules (e.g common false positives)? To be precise, can individuals/team/project “share” customized rules? A: Veracode rules are not customizable. Our False Positive rate is one of the lowest in the industry at under 15%. When we identify and find a false positive we want to fix it for all customers rather than to provide functionality that will make it difficult to measure improvements. You can customize a policy for application security testing, just as our team has done in order to focus only on the highest severity issues to test daily builds. A big thank you to everyone that submitted questions during the webinar, and if you have any questions or comments, I would love to hear from you in the comments section below.
Be sure to check out the webinar if you missed it, and if you are interested in learning more about Agile SDLC, check out Chris Eng, VP of research at Veracode, and Senior Security Researcher, Ryan O’Boyle’s webinar: “Building Security Into the Agile SDLC: View from the Trenches”, where they discuss how we’ve embedded security into our own Agile Scrum processes – to rapidly deliver new applications without exposing them to critical vulnerabilities.