SupportContactLogin
Live Demo
Blog
Blog   >   DevSecOps   >   8 Patterns For Continuous Code Security

8 Patterns For Continuous Code Security

Guest post by Chris Wysopal, CTO at Veracode 

This is the fifth installment in our series of weekly blog posts that dives into the role of SecDevOps. This series looks into why we need it in our lives, how we may go about implementing this methodology, and real life stories of how SecDevOps can save the Cloud.

Best practices of secure agile teams

According to the 2014 Verizon Data Breach Investigations Report (DBIR), web applications are the #1 attack vector leading to data breaches.

So deploying insecure web applications into production can be risky — resulting in potential loss of customer data, corporate intellectual property and/or brand value.

Yet 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?  Because traditional approaches to application security are typically complex, manual and time-consuming – deterring agile teams from incorporating code analysis into their sprints.

But it doesn’t have to be that way.  By incorporating key SecDevOps concepts into the Software Development Lifecycle (SDLC) – including the use of cloud-based services with API-driven automation, centralized policies and tighter collaboration and visibility between security and DevOps teams – we can now embed continuous code-level security and assessment into our agile development processes.

In our own development environment, Veracode has adopted secure agile processes with the goal of rapidly delivering code without sacrificing security. Along the way we’ve uncovered eight patterns that lead to successful secure agile development.

These eight patterns work together to transform cumbersome waterfall methodologies into efficient and secure agile development.

1. Think like a developer.

In agile environments, developers write code based on work committed in the current sprint. At various points in the process, our developers upload code to Veracode’s cloud-based application security service, directly from their IDEs. The code is then analyzed and the results downloaded to their development environments, allowing them to address vulnerabilities before check in. By finding vulnerabilities during coding instead of during a separate security hardening 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 testing is only implemented at the end of a sprint, as a pre-deployment gateway or checkpoint. This approach requires a separate security hardening sprint after the team has delivered a functionally-complete release candidate. This results in a hybrid waterfall/agile process instead of enabling the best practice of agile — completing all the work during the sprint.

In comparison, frequent assessments allow the team to identify and remediate release blockers early in the cycle — when they’re easier and less expensive to fix. This also reduces the overall risk of successful delivering the team’s payload. It only works because most Veracode assessments finish within hours or overnight (in fact, 80% of assessments for Java and .NET applications are completed in less than 4 hours). That means that continuous security assessments can fit into a one to two week sprint that’s typical in many development organizations.

3. Use multiple analysis techniques for optimum coverage and accuracy.

The appropriate combination of multiple analysis techniques — ideally in a single centralized platform with consistent policies, metrics and reporting — gives organizations the broadest view of application security.

Binary static analysis – also known as “white box testing” or “inside out testing” – analyzes data and control paths without actually executing the application, looking for vulnerabilities such as SQLi and XSS.

In comparison, dynamic analysis (DAST) – also known as “black box” or “outside in” testing – identifies exploitable vulnerabilities at runtime, during pre-production QA/staging.

Manual penetration testing looks for vulnerabilities that can only be found by humans, such as Cross-Site Request Forgery (CSRF) or business logic issues.

Of course, most modern applications aren’t built from scratch but rather assembled from a mixture of custom code and open source components and frameworks. Software composition analysis (SCA) is a handy way of identifying which components are used where – and which are known to be vulnerable.

4. Automate to blend in.

Blending in with developers’ automated toolchains means leveraging tools they already use. Automation inside the IDE (Eclipse) is used to build, upload, scan and then download results, which are shown against the code inside the editor for easy remediation. Automation at the team or release candidate stage allows the build server (Jenkins) to automatically upload build artifacts for assessment, using Veracode APIs. API-driven automation in the bug tracking system (JIRA) downloads results and manages the vulnerability lifecycle. Tickets for vulnerabilities are then triaged through the same process used for all bugs. When security assessments are blended in, developers don’t switch context – and they work more efficiently.

5. Play in the sandbox.

The sandbox is a way for individual developers or teams to assess new code against the organization’s security policy, without affecting policy compliance for the current version. 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 current policy. Each team can also have a sandbox for merging multiple branches to assess the integration.

6. Avoid replicating vulnerabilities.

If you think about how developers work, there’s always a bit of copy-and-paste going on. Developers look at code and say, “All right, I’m going to use that pattern.” When vulnerabilities get replicated across the code base, it magnifies risk across projects. Then it becomes a big development effort – “security debt” – to clean up those vulnerabilities.

7. Learn from constant feedback.

Direct interaction between developers and detailed vulnerability feedback enables self-reflection. People begin to see their own coding habits and gain insight into how to develop more secure ones. 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 results.” Continuous feedback means they’re more likely to reuse secure patterns and avoid insecure ones.

8. Be transparent about security risk via policies.

We use labels to identify any vulnerability that violates our standard corporate security policy (such as “No OWASP Top 10 Vulnerabilities”) as a release blocker. This raises our visibility into vulnerabilities and allows us to triage every application-layer threat before release. Triage involves answering questions such as: Do we need to remediate this vulnerability? Can we mitigate it instead, and if so, how? Is this a risk we’re willing to accept? Visibility enables a pragmatic discussion about risk within the normal agile sprint management process.

Adopting these eight patterns has helped Veracode become more efficient, secure and successful in delivering code with short delivery cycles – without sacrificing security.

Stay tuned next Wednesday for our sixth installment in this series as we continue to dive deep into SecDevOps implementation.