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