Skip to main content
June 16, 2014

Secure Agile Q&A: Scale, Continuous Integration and Policies

Q&A crop

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.

false postives
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.
view the webinar
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.

As Director of Developer Engagement, Pete provides customers with practical advice on how to successfully roll out developer-centric application security programs. Relying on more than 10 years of direct AppSec experience as both a developer and development leader, Pete provides information on best practices amassed from working with Veracode’s 1,000+ customers.

Pete joined Veracode in 2006 as a platform developer and was instrumental in delivering the first version of Veracode’s service to customers. Later, as Director of Platform Engineering, Pete managed the Agile teams responsible for delivering Veracode’s SaaS platform and built the first DevOps team.  Pete also spearheaded Veracode’s initiative to automate the use of Veracode products into the company’s development processes. Using this experience, he has spoken with hundreds of Veracode customers to help them set up similar programs.

Pete has more than 25 years’ experience developing software and has been developing web applications since 1996, including one of the first applications to be delivered through a web interface. 

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.