1. 8 PATTERNS FOR
CONTINUOUS CODE
SECURITY
By Chris Wysopal, CTOVeracode
produced for Threat Stack

2. 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.

3. Best Practices of
Secure Agile Teams

4. Web applications are the #1 attack vector
leading to data breaches.
According to the 2014 Verizon Data Breach
Investigation Report (DBIR)…

5. Deploying insecure web applications into
production can be risky
…resulting in potential loss of customer data,
corporate intellectual property and/or brand value!

6. 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).

7. WHY?

8. Traditional approaches to application security are
complex, manual and time-consuming,
deterring agile teams from incorporating code
analysis into sprints.

9. IT DOESN’T HAVE TO BE THAT WAY…

10. 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.

11. 1. Think Like A Developer

12. •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

13. 2. Find It Early. Fix It Early.

14. •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.

15. 3. Use Multiple Analysis Techniques
For Optimum Coverage
And Accuracy

16. 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.

17. 4. Automate To Blend In

18. • 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.

19. When security assessments are blended in,
developers don’t need to switch context
— and can work more efficiently!

20. 5. Play In The Sandbox

21. • 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.

22. 6. Avoid Replicating Vulnerabilities

23. 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

24. 7. Learn From Constant Feedback

25. Direct interaction between developers
+
detailed vulnerability feedback
=
self-reflection

26. 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

27. 8. Be Transparent About
Security Risk Via Policies

28. 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.

29. 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.

30. Start Implementing
Continuous Code Security Today
threatstack.com veracode.com
@threatstack @veracode