Using the OWASP ASVS for secure software development


Monday, at BSides Columbus, I premiered a new talk about using the OWASP Application Security Verification Standard as the basis for a secure SDLC, or a software security test plan, or a code review guide, or anything else your company needs to get off the starting blocks with regards to application security. I think the talk was well received, and was asked to put a synopsis on 'paper' for reference.

A system for verifying security controls
The purpose for the ASVS is providing a standard of communication between software vendors and customers. The customer can ask 'How secure are you,' the vendor can answer 'THIS secure,' and everyone is on the same page.


By nature, the ASVS is platform independent and free of technical detail. It is simply a listing of security controls, subcategorized by topic and ordered by relative difficulty to implement. This lends itself tremendously well to supporting the development of an application security platform for any software - not just for communication with tool vendors.

Embedded security principles

The ASVS is tightly integrated with two projects that are core to OWASP: The Top 10 and the Security Principles Project. The Top 10 is nothing new, but the integration of security principles into the core of a security program is strong sauce that isn't easy to make. Using the ASVS to help you integrate the core principles into your program brings a lot of value, virtually for free.
  • Defense in Depth
  • Positive Security Model
  • Fail Securely
  • Principle of Least Privilege
  • Separation of Duties
  • “Security by Obscurity”
  • Do Not Trust the Client
Four verification levels
Since the ASVS is designed to let the tool vendor inform the customer as to 'how secure' they are, it makes sense that the would be 'levels' for the standard. These include:
  • Level 0 (Cursory) indicates that the application has undergone some type of certification.
  • Level 1 (Opportunistic) indicates that the application adequately defends against security vulnerabilities that are easy to discover.
  • Level 2 (Standard) indicates that the application adequately defends against prevalent application security vulnerabilities whose existence poses a moderate to serious risk.
  • Level 3 (Advanced) indicates that the application adequately defends against all advanced application security vulnerabilities.

Thirteen verification requirements
The thirteen verification requirements, and their sub-points - represent some of the best thinking I have ever  seen on the distilling of application security principles into actionable items without specifying platform. These are the core of the standard, and should be used to map to your individual needs. From there you can build a secure SDLC, a test plan, whatever you need.

  • Authentication
  • Session management
  • Access control
  • Input handling
  • Cryptography at rest
  • Error handling and logging
  • Data protection
  • Communication security
  • HTTP security
  • Malicious controls
  • Business logic
  • Files and resources
  • Mobile security
Going forward
Going forward, I recommend a 5 step plan for getting the ASVS installed in your development process:
  1. Approach Management, and tell them you have a plan for application security
  2. Determine your starting level. I recommend Level 1.
  3. Match the requirements to your software - the hardest part. Go point by point and figure out where in your software you need to implement changes based on the requirements.
  4. Assign responsibility to development staff, even if you ahve to break out Microsoft Project.
  5. Implement. Pull the trigger.


Comments are closed

Bill Sempf

Husband. Father. Pentester. Secure software composer. Brewer. Lockpicker. Ninja. Insurrectionist. Lumberjack. All words that have been used to describe me recently. I help people write more secure software.

profile for Bill Sempf on Stack Exchange, a network of free, community-driven Q&A sites

MonthList