Our biggest goal with this version of the standard
was to increase adoption.
One of the major challenges of a standard such as this is that it needs to satisfy two distinct, and very
different, targets: individuals who are involved in organizing or executing a software security program within
their organization, and software security professionals who conduct verification of applications. While both
targets seek an industry-accepted standard for verification of applications, they operate under different
constraints. For example, one of the most widely voiced criticisms of ASVS 2009 standard was that it
specified automated assessments as one of the levels (or sub-levels). Many large organizations see
automated assessments as a point of entry into the verification hierarchy, and thus a fully automated level is
a convenient concept for them. Information security professionals, however, know that the depth and
breadth of such a review will depend on what technology is used to perform the scan, thus leaving too much
room for interpretation of the standard. ASVS 2014 introduces a Cursory Level 0 to allow for the flexibility
needed to overcome this challenge.
On a similar note, one of the main goals for this version of the standard was to focus on the "what" and not
the "how". Whereas the previous version of the standard talked about dynamic scanning, static analysis,
Threat Modeling, and design reviews, you will notice that such terms do not appear in this version of the
standard. Instead, we essentially define security requirements that must be verified for an application to
achieve a certain level. How those requirements are verified is left up to the verifier.
Another major challenge that we overcame is to clearly separate requirements from design from scope. The
previous version of the standard did not clearly distinguish between these concepts, leaving room for
confusion. In this version, Level 3 is where design considerations are introduced and clearly separated from
detailed verification requirements. Furthermore, we have now separated out the concept of scope
completely – the new (+) notation allows for a verifier to optionally include third party components and
frameworks in their review.
We expect that there will most likely never be 100% agreement on this standard. Risk analysis is always
subjective to some extent, which creates a challenge when attempting to generalize in a one size fits all
standard. However, we hope that the latest updates made in this version are a step in the right direction, and
respectfully enhance the concepts introduced in this important industry standard.
