8 PATTERNS FOR CONTINUOUS CODE

SECURITYBy Chris Wysopal, CTO Veracode

produced for Threat Stack

Introductions

Chris WysopalCo-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