Can't security professionals and developers just get along? Consider this – If the number one job of a security professional is to place a developer’s code under a microscope and highlight each and every flaw, you can appreciate why there may be some tension. The majority of solutions used by security professionals to test developer code only offer assessments of what they did wrong. Can we apply a different lens while having this conversation? Recently we featured a webinar where Donna Durkin, CISO of Computershare, and Tim Jarrett, Director of Product Management, candidly discussed what works and doesn’t when talking to development about security. Key highlights of the discussion included:
- Common pitfalls when security professionals talk to developers about secure coding
- A new way of reporting on security best practices that will drive more positive conversations about secure code
If you would like to view the webinar, click here. In addition, we are sharing some highlights from the Q&A at the end of the discussion in this post. Enjoy!
Q: Has there been an increase in the overall development efforts through setting security policy and the use of Greenlight reports? Donna Durkin: Great question – as developers are becoming familiar with the Veracode platform, as well as when we discuss what types of testing should be occurring, there is a little bit of overhead that’s adding to the process. But, in the long run Policy and reports actually have a positive impact on the development resources who likely have moved on to other things and now have to go back and remediate after the fact. Once a development team is familiar with the platform, and they were doing testing, we have not seen any real impact on overhead in regards to the release cycle. Q: Is there any impact on the scan times with the Veracode Platform as a result of the report coming from Project Greenlight? Tim Jarrett: It turns out that because we were already looking at all of the possible points where a flaw could happen, like all the places the application was writing too, an HTML page, all the places it was touching the database, stopping to write down that these points were successfully protected really added very little in terms of the overall results turnaround time. I think that if we were using a different approach other than the really thorough deep-dive that we were taking it might have been a different story, so operationally there has been no impact. Q: What would a code review process with developers doing a manual peer review of others look like with the Veracode Platform adjunct to the SDLC? Are code reviewers going to get pulled into a Veracode handled security check? Tim Jarrett: It is important to recognize Veracode is part of your security “balanced diet,” we are providing a lot of value in terms of audit information and looking for lots and lots of ways things can go wrong in code. There are still the things that require a certain amount of human intervention, so we certainly recommend using the threat model early in the design process. We also recommend for the mission critical applications you include manual and hands-on testing of the application for security issues. I think that the way we look at is it's really part of your overall approach and the real benefit that we bring - because of the automation - and because of the ease of getting started - is being able to cover a large set of types of attacks for a very large number of applications. To view a demo of the Veracode platform, click here. As always, we would love to continue the discussion, so feel free to comment and or view the entire webcast here.