8 PATTERNS OF SECURE

AGILE TEAMS

Best practices for integrating code

security with agile development.
Developing secure products in an agile environment can be challenging.
Application vulnerabilities and coding issues are typically time-consuming
to find, document, and fix with traditional testing tools. Short agile sprints
don’t lend themselves to these long processes; however, there are ways to
effectively integrate secure development with agile methods.
Veracode has adopted secure agile processes in its own effort to develop
secure products with rapid delivery cycles. As Veracode moves towards
a completely agile development process, we’ve discovered eight patterns
that lead to successful secure agile development.
These eight patterns work with one another to change cumbersome
waterfall methodologies into efficient agile development methods. No single
practice is more important than another. Rather, secure agile development
only functions well when all of these practices are combined.
1. Think like a developer.
Code security starts with the individual developers who that are in pre-production staging (or public-facing). Manual
create the code. In an agile environment, developers write penetration testing examines applications for specific vulner-
code based on work committed in the current sprint. At abilities that require manual inspection — such as Cross-Site
various points in the process they use their IDE to upload Request Forgery (CSRF) or business logic issues. Software
code to Veracode’s cloud-based service for static applica- composition analysis is used to identify vulnerabilities in
tion security testing (SAST). Once assessment is complete, open source components and frameworks that are often
the results are downloaded to their development envi- leveraged to speed up the development process. Behav-
ronment. Developers can now address any vulnerabilities ioral analysis enables mobile developers to identify risky
introduced before check in. By finding vulnerabilities during application behaviors that can put confidential data at risk. The
coding instead of during a
separate security hard-
ening sprint, developers
need not switch context
to work on code written
long ago. This saves both
time and velocity.

2. Find it early.
Fix it early.
Too often, security
assessment is done only
as a pre-deployment
gateway or checkpoint.
When using agile methods,
development teams often
handle pre-deployment
gateways by schedul-
ing a security hardening
sprint after they have a
functionally complete
release candidate. This
means that security
assessments forces a
hybrid waterfall-agile
development process
instead of truly enabling the best practice of agile — complete appropriate combination of techniques — ideally in a single
the work in the sprint. Frequent assessments allow the platform with consistent policies, metrics and reporting —
team to identify and remediate release blockers early in the gives enterprises the broadest view of application security.
cycle — when they are easier and less expensive to fix. This
reduces the overall risk to the team for successful delivery 4. Automate to blend in.
of their payload. Equally important is that the majority Blending in with developers’ toolchains means leveraging
of Veracode service scans finish quickly — within hours the tools that they already use. This is accomplished by
or overnight (in fact, 80% of assessments for Java and automating the security assessment and results download
.NET applications are turned around in less than 4 hours). between those tools behind the scenes. This happens at
That means that security assessments can fit into a one multiple levels. The first is automation inside of the IDE to
to two week sprint that is typical in most development build, upload and scan and then download results at the
organizations. push of a button. The results are shown against the code
inside of the editor for easy remediation. Then there is
automation at the team or release candidate stage, when
3. Use multiple techniques for the build server makes use of the Veracode API to upload
security assessments. build artifacts for security scans. Automation in the bug
Using multiple assessment techniques ensures better tracking system leverages APIs to download results and
coverage and accuracy. Binary static analysis can analyze manage the vulnerability lifecycle. Tickets for vulnerabilities
the application’s data and control paths without executing are then triaged through the same process used for all bugs.
the application. Dynamic analysis (DAST) identifies When security assessments are blended in, developers do
exploitable vulnerabilities, at run time, in web applications not switch context and they work more efficiently.
 5. Play in the sandbox.
The sandbox is the way for individual developers or devel-
opment teams to assess new code against the required
security policy — without affecting compliance reporting for
the version of the application currently in production. One
way to think about an assessment sandbox is to consider
it as a branch inside the application. Developers can scan
the branch and understand whether it would pass the cur-
rent policy as defined. Each team can also have a sandbox
for merging multiple branches to assess the integration. Then
you would want to merge branches from multiple teams
into the release candidate and reassess. That is a lot of
assessing within a short period of time, but automation
simplifies assessments for the teams and the sandbox
simplifies reporting for compliance and auditing purposes.
6. Avoid replicating vulnerabilities.
If you think about how developers work, there is always a
bit of copy-and-paste that goes on. Developers look at code
and say, “All right, I’m going to use that pattern.” If you do
not encourage and enable developers to check-in secure
code, and those vulnerabilities get copied and replicated
across the code base, it magnifies risk in individual projects
and possibly across multiple projects. Then it becomes a big
development effort to clean up those vulnerabilities.
7. Learn from constant feedback.
Direct and frequent interaction between developers and
detailed vulnerability information — delivered through
their development environments — enables self-reflection.
In other words when people go through this process over
and over again they will start to see their own habits and
gain insight on how to develop better habits. The “aha”
moment comes when a developer says “Oh, I shouldn’t
have coded it this way because as soon as I upload it I’m
going to see the same vulnerability results.” Because they
are getting more timely feedback on the code they write
or change, they are more likely to reuse secure coding
patterns and avoid insecure ones.
8. Be transparent about security risk.
We use labels to identify any vulnerability as a release
blocker if it violates our standard security policy (such as
“No SQL Injection or Cross-Site Scripting Vulnerabilities”).
This is one way to raise the visibility of vulnerabilities and
allow triage of every single application-layer threat prior
to release. Triage involves answers questions such as: Do
we need to remediate this vulnerability? Can we mitigate
it instead, and if so, how? Is this a risk that we’re willing to
accept? The visibility enables a pragmatic discussion about
risk within the normal agile sprint management process.

Adopting these eight patterns for secure agile development

has helped Veracode become more efficient, secure and
successful in producing secure code with fast delivery cycles.

To learn more, see: www.veracode.com/products

Veracode’s cloud-based service and programmatic approach deliver a simpler and

more scalable solution for reducing global application-layer risk across web, mobile
and third-party applications. Recognized as a Gartner Magic Quadrant Leader since
2010, Veracode secures hundreds of the world’s largest global enterprises, including
3 of the top 4 banks in the Fortune 100 and 25+ of the world’s top 100 brands.