How the OWASP Application Security Verification Standard Helps Improve Software Security

A short time ago, we announced our integration of OWASP ASVS into our cyber risk management platform. To summarize, OWASP will allow our customers to launch better, more efficient security assessments of cloud apps, while also providing a mechanism by which ISV apps can be evaluated.

Today, we’re going to talk a bit about what OWASP actually is. If you’re a software developer or cybersecurity professional, it’s likely you’re already familiar with the framework — though you might not know the specifics of the most recent release. And if you’re a newcomer or layperson, you likely don’t know a great deal about OWASP, just that it’s important. 

We’ll help clear the air. 

OWASP Application Security Verification Standard Helps Improve Software Security

What Is the OWASP Application Security Verification Standard Project?

First developed in 2009, the open-source OWASP ASVS was created with the objective of normalizing and standardizing security for web applications. At the time it was first released, web app development was still relatively new, and there weren’t a great many guidelines for developers to follow. OWASP sought to change that, and its guidelines were created with the following in mind: 

  • Measurement: OWASP was intended to provide both developers and clients with an established benchmark that could be used to determine an application’s level of security and trust. 
  • Guidance: OWASP’s creators also sought to provide guidelines regarding security controls in relation to the framework’s established security requirements. 
  • Procurement: Finally, OWASP was intended to ease the procurement process, allowing for the specification of verification, access, and security requirements in vendor contracts. 

Since its release, OWASP has gone through multiple iterations as the open-source community that grew around the framework continued to adapt, adjust, and innovate. That community continues to serve it well to this day; OWASP ASVS is hosted on GitHUb and supported by hundreds of global chapters and tens of thousands of volunteers. Today, it is one of the most widely-known cross-platform security frameworks in the world. 

Depending on the required level of security, OWASP is broken into three verification levels

  • ASVS Level 1 (Opportunistic): Basic software that doesn’t require comprehensive or specialized security. Level 1 controls are primarily focused on well-known vulnerabilities and exploits, and are verified chiefly via penetration testing. 
  • ASVS Level 2 (Standard): This is the recommended level for the majority of applications. In addition to requiring that a developer maintains all the controls required for ASVS Level 1, Level 2 verification focuses on slightly more sophisticated attack vectors and tactics. Per OWASP, the standards for level 2 typically apply to B2B software, business-critical functionality, and sensitive data such as payment information.
  • ASVS Level 3 (Advanced): The highest verification level possible under OWASP, Level 3 applications are typically used in sectors such as defense and public infrastructure. Qualification is incredibly involved, requiring in-depth analysis, testing, and auditing from the ground-up.

Although the framework currently applies broadly to all digital software, OWASP plans to retire its section on mobility in the near future and focus entirely on web applications. This specialization will ultimately make it an even more effective tool for training, procurement, and security guidance.  

Start Getting Value With
Centraleyes for Free

See for yourself how the Centraleyes platform exceeds anything an old GRC
system does and eliminates the need for manual processes and spreadsheets
to give you immediate value and run a full risk assessment in less than 30 days

Learn more about how to be compliant with OWASP

What’s New In OWASP ASVS 4.0?

There are two significant additions to OWASP ASVS 4.0. 

First, the framework now features NIST 800-63-3 compliance. Released by the National Institute of Standards and Technology in 2017, the 800-63 standards establish the technical requirements which federal agencies must follow when implementing digital identity services. 800-63-3 is intended to make guidance simpler, easier to understand, and more closely-aligned with commercial organizations and markets. 

ASVS 4.0 also more extensively incorporates Common Weakness Enumeration, a community project that categorizes and classifies security vulnerabilities and weaknesses. In the context of ASVS 4.0, CWE will be used for threat mapping. Other differences between ASVS 3.0 and ASVS 4.0 include: 

  • The introduction of new secure DevOps practices. 
  • A more proactive, holistic approach to security as a whole. 
  • A restructuring and renumbering of the document with the goal of making it easier to follow and understand. 
  • A new section focused on privacy controls. 
  • New password requirements and coverage for GUIDs and Key Vaults. 
  • The addition of threat modeling to ASVS’s Business Logic Verification Requirements. 
  • The establishment of the  Mobile Application Security Verification Standard as its own separate project. 
  • The addition of sensitive private data to the section on GDPR. 

You can view and download ASVS 4.0 through GitHub.

Learn More About OWASP ASVS and Centraleyes

Now that you’re a bit more familiar with what OWASP ASVS is and what it does, you also have a better idea of how it slots into our risk management platform. 

For our clients, ASVS 4.0 will become one more toolkit in their arsenal. One more set of guidelines they can leverage to deploy safer, more secure software. 

Are you interested in learning more about how we’ve integrated OWASP ASVS 4.0 into our platform? Book a demo with one of our cybersecurity specialists today.

Start Getting Value With
Centraleyes for Free

See for yourself how the Centraleyes platform exceeds anything an old GRC
system does and eliminates the need for manual processes and spreadsheets
to give you immediate value and run a full risk assessment in less than 30 days

Does your company need to be compliant with OWASP?

Skip to content