Skip to main content
December 15, 2014

Find it Early, Fix it Early: PETETalks

In my recent blog post I discussed some of the fundamental tenets of the agile methodology of software development – one of which is keeping developers working efficiently within their tool chain.  Having held the role of Scrum Master myself, I’ve had the responsibility to ensure that members of my development team have the tools they need to finish their tasks at hand before they move on to the next story within a sprint. This begs the question of how to embed security into an actual sprint – increasing effectiveness and reducing time spent on the security assessment process.

Too often, security assessment is done only as a pre-deployment gateway or checkpoint. When using agile methods, development teams often handle these requirements by scheduling a security hardening sprint after they have a functionally complete release candidate. This means that the security assessment forces a hybrid waterfall-agile development process instead of truly enabling the best practice of agile — complete the work in the sprint. Frequent assessments allow the team to identify and remediate release blockers early in the cycle — when they are easier and less expensive to fix. This reduces the overall risk to the team for successful delivery of their payload. Equally important is that the majority of Veracode service scans finish quickly — within hours or overnight (in fact, 80% of assessments for Java and .NET applications are turned around in less than 4 hours). That means that security assessments can fit into a one to two week sprint that is typical in most development organizations.

Independent security analyst group Securosis echoes these sentiments and specifically recommends making security requirements and tests part of the story by selecting small items that quickly help identify whether code passes or fails to meet requirements. With regards to new features, the key is to have the developer understand the core security requirement by having them construct acceptance tests to get an early idea of whether or not they are on track. For vulnerabilities and flaws, managers should ask for security regression tests to be included with the fix to ensure that mistakes are not repeated. If your organization automates static testing during the development phase you will need to integrate results into tracking tools so developers can leverage them while the code changes are fresh in their minds.

Stay tuned for my next post on how to use multiple techniques for security assessments. In the meantime, I welcome any thoughts or experiences you can share on securing code early in the agile development process.

Related Content

More PETETalks

Use Multiple Techniques for Security Assessments

Think Like a Developer

Related Content

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.