Attached to this post is a mapping between the two industry leading standards from OWASP regarding penetration testing and application security, the OWASP testing guide 4.0 and the OWASP Application Security Verification Standard (ASVS) 3.0.1. First of all I would like to say that that mapping these two standards is either impossible or has no value to either security testers and/or application developers. Also, this mapping is purely a best effort based on my interpretation of both standards. I would like to invite everyone reading this and to improve the mapping where it came short and provide feedback where applicable.
After completing the mapping the first thing that came to notice was the rather large gap residing between the two standards. I noticed some overlap between requirements and tests and some requirements and/or tests lack mapping in general. This surprises me as I would expect that most requirements set to secure development would be tested by the security tester and vice versa. This means that a security test based on the security testing guide standard is insufficient compared to the requirements set to the application security standard. An application developed using the application security standard contains security issues that are defined in the testing guide and may or may not contain mitigating measures that are not tested.
This mismatch has two outcomes: The developer will not be able to develop a secure application by default and the security tester will not test all security related issues. This leads to inefficient development and incomplete testing.
The second thing that came to notice was the maturity of certain subjects in either the security testing guide or application security standard. Some security related issues are worked out completely in different tests and/or requirements, while other are more high level describing multiple issues. This leads to issues and requirements mapping to multiple counterparts, which makes reporting about these issues more difficult. It appears that instead of overlapping each other they complement each other.
This leads to either high level tests or in depth tests and requirements that may or may not be covered by either standard, resulting in the same conclusion as stated before.
By aligning both standards, developers know which security flaws to prevent and security testers know which security flaws to test. Food for thought: What if both standards define all security related issues from both sides, but align regarding tests and best practice? What if every issue has its own test and requirement? This provides testers a more complete and clearer overview of which issues need to be tested and is able to provide better recommendations to the developer. The developer knows the requirements regarding specific security issues and knows what security issues to prevent or are not applicable within the application.
The point that i am trying to make is that both security testing and secure development still have a certain immaturity that I would like to see grow for a more secure environment for everyone.
You can view the mapping by clicking here (odt format).