How to Approach Integrating Application Security into Your Software Development Lifecycle

In this blog, we will take a deeper dive into exactly how to approach integrating security into your software development lifecycle (SDLC). In addition, we will delve into one available resource that guides how to get started.

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

*Note: 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 is a starting point for understanding DevSecOps, you can download the guide here.

The Benefits of Building in Security Early in SDLC

Let’s start by focusing on application security, which will steer us toward the 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 always have to configure firewalls, apply OS patches, install and maintain Intrusion Detection, etc.

The benefits of building application security 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 at the development level means we need to engage in 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 application security into your security early in the software development lifecycle are well worth the effort.

OWASP Application Security Verification Standard (ASVS)

Various OWASP Foundation projects 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 software development lifecycle.

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

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 are Important to the Software Development Lifecycle

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 for your software development lifecycle.

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 mindset is around the functionality of the application and not on anything but the most obvious weaknesses and vulnerabilities.

By creating either a 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