How to Approach Integrating Application Security into Your SDLC

Security as Code: How to Get Started

VerSprite’s guide, Integrating Security into Code, introduced the high-level concepts behind Security as Code and how it can be integrated with your DevOps processes. If you are interested in a guide that as a starting point to understanding DevSecOps, you can download the guide here.

In this blog post we will take a deeper dive into exactly how to approach integrating security into your Software Development Life Cycle (SDLC). In addition, we will delve into one available resource that provides guidance on how to get started.

Integrating security into your SDLC will depend strongly on your organization, products covered, business risks, and compliance requirements. There is no one size that fits all, but there are specific fundamentals that all organizations that build applications can utilize and benefit from.

The Benefits of Building in Security Early in SDLC

Let’s start by focusing on application security, which will steer us toward design and development end of the SDLC process. This kind of thinking is often referred to as “Shifting Your Security Program Left.”

At VerSprite, we have found that a large percentage of our clients already have security programs with their operations teams focused on system security. Therefore we are always having to configure firewalls, apply OS patches, install and maintain Intrusion Detection, etc.

The benefits of building application security in early in the SDLC not only include saving your organization time finding and fixing a defect, but also the expense of fixing any security defects found later in the SDLC.

Figure 1. Cost of finding security detects late in the SDLC

Targeting application security and at the development level means we need to engage the Continuous Integration process and involve development teams.

Getting development teams to do something new can always be a challenge, but the benefits of building in application security into your security early in the SDLC is well worth the effort.

OWASP Application Security Verification Standard (ASVS)

There are various OWASP Foundation projects which provide guidance and tooling to help incorporate security into a development and DevOps process.

More specifically, the OWASP Application Security Verification Standard (ASVS) provides a roadmap for incorporating security into several activities throughout your SDLC.

The current version of the Standard is 4.01 updated as of March 2019. The ASVS project has been running for over 10 years and is actively maintained. It is adjusted as needed as processes and technology changes.

The ASVS has two main goals, helping organizations develop and maintain secure applications and allowing security service and tool vendors to align their offerings.

The 3 Levels of ASVS

To help better align guidance with business requirements the ASVS has three levels each with increasing security depth:

Level 1 – First step, automated, defend against vulnerabilities that are easy to discover and included in the OWASP Top 10 and similar list. Can verify with black box testing.

Level 2 – Most applications, defends against most of the risks facing software today.

Level 3 – High value, assurance and/or safe, e.g. military, health and safety, critical infrastructure, etc.

Figure 2. ASVS 4.0 Levels

We recommend using the ASVS as a blueprint to create a Secure Coding Checklist specific to your application, platform, and organization.

The scope of controls covered is broad and complete, so tailoring it for your organization and use cases will allow you to focus the guidance and prioritize based on impact.

Current ASVS Use Cases

• Detailed Security Architecture Guidance
• Secure coding checklist
• Guide for automated unit and integration tests
• Secure development training
• Driver for agile application security
• Framework for guiding procurement of secure software

We recommend that most organizations should start with level 1 and pursue the creation of a secure coding checklist and unit/integration test. The need to move to level 2 and 3 will be dictated later by business needs.

ASVS Control Domains containing automatable level 1 checks

• V2: Authentication Verification Requirements
• V3: Session Management Verification Requirements
• V4: Access Control Verification Requirements
• V5: Validation, Sanitization and Encoding Verification Requirements
• V7: Error Handling and Logging Verification Requirements
• V8: Data Protection Verification Requirements
• V9: Communication Verification Requirements
• V12: File and Resources Verification Requirements
• V13: API and Web Service Verification Requirements

As of version 4.0 of the ASVS, all of the level 1 requirements covered by the various domains have matching Common Weakness Enumeration (CWEs).

For the V2: Authentication and V3: Session Management domains, each ASVS requirement has a matching NIST 800-63 requirement.

Figure 3. A few V2: Authentication Verification Requirements

Although not specifically mapped for each requirement, the level 1 standard is intended to be a comprehensive superset of PCI DSS 3.2.1 Sections 6.5 for application design, coding, testing, secure code review, and penetration tests.

If you have PCI requirements, again the ASVS is a great starting point.

ASVS: Testing Within Your Pipeline

The ASVS is designed to be highly testable, with the sole exception of architectural and malicious code requirements.

It is often a struggle for development teams to create good security test cases from scratch as their mind set is around the functionality of the application and not on anything but the most obvious weaknesses and vulnerabilities.

By creating either unit or integration test for the ASVS control requirements and expanding those for relevant abuse cases for the application, the build becomes nearly self-verifying with every iteration.

Application Security Resources

There are several projects and publications available to help guide in your journey with Security as Code:

• OWASP Testing Guidelines provide guidance for creating security test cases.
• OWASP Proactive Controls are a set of development practices for creating secure applications.

Security as Code:
How to Integrate Security into DevOps

One the main tenets of DevOps is “Infrastructure as Code”. This is accomplished by defining your infrastructure (servers, network, storage) in a programming language and via tools that deploy that infrastructure automatically. By doing so, infrastructure can now benefit from software engineering practices like version control, code review, and unit testing.

Get the Guide