8 PATTERNS FOR
CONTINUOUS CODE
SECURITY
By Chris Wysopal, CTOVeracode
produced for Threat Stack
Introductions
Chris Wysopal
Co-Founder and CTO, Veracode
Chris Wysopal, co-founder and CTO of Veracode, is recognized as an expert and a
well-known speaker in the information security field. He has given keynotes at
computer security events and has testified on Capitol Hill on the subjects of
government computer security and how vulnerabilities are discovered in software. At
Veracode, Mr. Wysopal is responsible for the security analysis capabilities of
Veracode technology. He can be found on Twitter as @WeldPond.
Best Practices of 

Secure Agile Teams
Web applications are the #1 attack vector
leading to data breaches.
According to the 2014 Verizon Data Breach
Investigation Report (DBIR)…
Deploying insecure web applications into
production can be risky
…resulting in potential loss of customer data,
corporate intellectual property and/or brand value!
Many organizations still deploy public-facing
applications without assessing them for
common and easily-exploitable
vulnerabilities such as SQL Injection and
Cross-Site Scripting (XSS).
WHY?
Traditional approaches to application security are
complex, manual and time-consuming,
deterring agile teams from incorporating code
analysis into sprints.
IT DOESN’T HAVE TO BE THAT WAY…
Just follow these eight patterns.
Incorporating SecDevOps concepts into the Software
Development Lifecycle (SDLC), we can embed continuous
code-level security and assessment into our agile
development processes.
1. Think Like A Developer
•Upload code to a cloud-based application security
service, such as Veracode, directly from the IDE
•Analyze code automatically
•Results downloaded to development environment —
addressing vulnerabilities before check in
This finds vulnerabilities DURING coding instead of
during a SEPARATE security hardening sprint.
How to do this in agile environments
2. Find It Early. Fix It Early.
•This makes vulnerabilities easier and less
expensive to fix
•It reduces the overall risk of successfully
delivering the team’s payload
•This allows continuous security
assessments to fit into a one to two week
sprint
Frequent assessments allow teams to identify
and remediate blockers early in the cycle.
3. Use Multiple Analysis Techniques
For Optimum Coverage
And Accuracy
Achieving the broadest view of application security
Binary static analysis
Also known as “white box testing” or
“inside out testing”, this analyzes data
and control paths without actually
executing the application, looking for
vulnerabilities such as SQLi and XSS.
3 components:
Dynamic analysis (DAST) Manual penetration testing
Also known as “black box” or “outside
in” testing, identifies exploitable
vulnerabilities at runtime, during pre-
production QA/staging.
This looks for vulnerabilities that can
only be found by humans, such as
Cross-Site Request Forgery (CSRF) or
business logic issues.
4. Automate To Blend In
• Automation inside the IDE (Eclipse): Used to build, upload, scan
and download results, which are shown against the code inside the
editor for easy remediation.
• Automation at team or release candidate stage: Allows the build
server (Jenkins) to automatically upload build artifacts for assessment,
using Veracode APIs.
• API-driven automation in bug tracking system (JIRA): Downloads
results and manages vulnerability lifecycle.
• Tickets for vulnerabilities are triaged: This uses the same process
as all other bugs.
Blending in with developers’ automated toolchains
means leveraging tools they already use.
When security assessments are blended in, 

developers don’t need to switch context 

— and can work more efficiently!
5. Play In The Sandbox
• Consider an assessment sandbox a branch
inside the application
• Developers scan the branch and understand if it
will pass the current policy
• Each team can have a sandbox for merging
multiple branches to assess the integration
Assess new code against the organization’s security
policy without affecting policy compliance.
6. Avoid Replicating Vulnerabilities
Developers work in copy and paste patterns.
But when vulnerabilities get replicated across the code
base, it magnifies risk across project. This causes
a “security debt” to clean up those vulnerabilities
The “copy and paste” effect
7. Learn From Constant Feedback
Direct interaction between developers
+
detailed vulnerability feedback
=
self-reflection
Self-reflection allows developers to see their own
coding habits and gain insights into how to develop
more secure ones.
“Oh I shouldn’t have coded it this way because as soon
as I upload it, I’m going to see the same results.”
Reuse secure patterns and avoid insecure ones!
The “aha” moment
8. Be Transparent About
Security Risk Via Policies
This raises visibility into vulnerabilities and allows for triaging
of every application-layer threat before release.
•Triage involves answering:
•“Do we need to remediate this vulnerability?”
•“Can we mitigate instead, and if so, how?”
•“Is this a risk we’re willing to accept?”
Using labels to identify vulnerabilities that violate
corporate security policies
Visibility enables pragmatic discussions about risk within the normal agile sprint
management process.
Adopting these 8 patterns has helped
Veracode and Threat Stack become more
efficient
secure
successful
in delivering code with short delivery cycles — without sacrificing
security.
Start Implementing
Continuous Code Security Today
threatstack.com	 		 	 	 	 	 	 	 veracode.com
@threatstack 		 	 	 	 	 	 	 	 	 	 @veracode

8 Patterns For Continuous Code Security by Veracode CTO Chris Wysopal

  • 1.
    8 PATTERNS FOR CONTINUOUSCODE SECURITY By Chris Wysopal, CTOVeracode produced for Threat Stack
  • 2.
    Introductions Chris Wysopal Co-Founder andCTO, Veracode Chris Wysopal, co-founder and CTO of Veracode, is recognized as an expert and a well-known speaker in the information security field. He has given keynotes at computer security events and has testified on Capitol Hill on the subjects of government computer security and how vulnerabilities are discovered in software. At Veracode, Mr. Wysopal is responsible for the security analysis capabilities of Veracode technology. He can be found on Twitter as @WeldPond.
  • 3.
    Best Practices of Secure Agile Teams
  • 4.
    Web applications arethe #1 attack vector leading to data breaches. According to the 2014 Verizon Data Breach Investigation Report (DBIR)…
  • 5.
    Deploying insecure webapplications into production can be risky …resulting in potential loss of customer data, corporate intellectual property and/or brand value!
  • 6.
    Many organizations stilldeploy public-facing applications without assessing them for common and easily-exploitable vulnerabilities such as SQL Injection and Cross-Site Scripting (XSS).
  • 7.
  • 8.
    Traditional approaches toapplication security are complex, manual and time-consuming, deterring agile teams from incorporating code analysis into sprints.
  • 9.
    IT DOESN’T HAVETO BE THAT WAY…
  • 10.
    Just follow theseeight patterns. Incorporating SecDevOps concepts into the Software Development Lifecycle (SDLC), we can embed continuous code-level security and assessment into our agile development processes.
  • 11.
    1. Think LikeA Developer
  • 12.
    •Upload code toa cloud-based application security service, such as Veracode, directly from the IDE •Analyze code automatically •Results downloaded to development environment — addressing vulnerabilities before check in This finds vulnerabilities DURING coding instead of during a SEPARATE security hardening sprint. How to do this in agile environments
  • 13.
    2. Find ItEarly. Fix It Early.
  • 14.
    •This makes vulnerabilitieseasier and less expensive to fix •It reduces the overall risk of successfully delivering the team’s payload •This allows continuous security assessments to fit into a one to two week sprint Frequent assessments allow teams to identify and remediate blockers early in the cycle.
  • 15.
    3. Use MultipleAnalysis Techniques For Optimum Coverage And Accuracy
  • 16.
    Achieving the broadestview of application security Binary static analysis Also known as “white box testing” or “inside out testing”, this analyzes data and control paths without actually executing the application, looking for vulnerabilities such as SQLi and XSS. 3 components: Dynamic analysis (DAST) Manual penetration testing Also known as “black box” or “outside in” testing, identifies exploitable vulnerabilities at runtime, during pre- production QA/staging. This looks for vulnerabilities that can only be found by humans, such as Cross-Site Request Forgery (CSRF) or business logic issues.
  • 17.
  • 18.
    • Automation insidethe IDE (Eclipse): Used to build, upload, scan and download results, which are shown against the code inside the editor for easy remediation. • Automation at team or release candidate stage: Allows the build server (Jenkins) to automatically upload build artifacts for assessment, using Veracode APIs. • API-driven automation in bug tracking system (JIRA): Downloads results and manages vulnerability lifecycle. • Tickets for vulnerabilities are triaged: This uses the same process as all other bugs. Blending in with developers’ automated toolchains means leveraging tools they already use.
  • 19.
    When security assessmentsare blended in, developers don’t need to switch context — and can work more efficiently!
  • 20.
    5. Play InThe Sandbox
  • 21.
    • Consider anassessment sandbox a branch inside the application • Developers scan the branch and understand if it will pass the current policy • Each team can have a sandbox for merging multiple branches to assess the integration Assess new code against the organization’s security policy without affecting policy compliance.
  • 22.
    6. Avoid ReplicatingVulnerabilities
  • 23.
    Developers work incopy and paste patterns. But when vulnerabilities get replicated across the code base, it magnifies risk across project. This causes a “security debt” to clean up those vulnerabilities The “copy and paste” effect
  • 24.
    7. Learn FromConstant Feedback
  • 25.
    Direct interaction betweendevelopers + detailed vulnerability feedback = self-reflection
  • 26.
    Self-reflection allows developersto see their own coding habits and gain insights into how to develop more secure ones. “Oh I shouldn’t have coded it this way because as soon as I upload it, I’m going to see the same results.” Reuse secure patterns and avoid insecure ones! The “aha” moment
  • 27.
    8. Be TransparentAbout Security Risk Via Policies
  • 28.
    This raises visibilityinto vulnerabilities and allows for triaging of every application-layer threat before release. •Triage involves answering: •“Do we need to remediate this vulnerability?” •“Can we mitigate instead, and if so, how?” •“Is this a risk we’re willing to accept?” Using labels to identify vulnerabilities that violate corporate security policies Visibility enables pragmatic discussions about risk within the normal agile sprint management process.
  • 29.
    Adopting these 8patterns has helped Veracode and Threat Stack become more efficient secure successful in delivering code with short delivery cycles — without sacrificing security.
  • 30.
    Start Implementing Continuous CodeSecurity Today threatstack.com veracode.com @threatstack @veracode