If you are specifying web application security verification requirements in contracts, you can use the OWASP ASVS to do so. One approach is to start with the OWASP Secure Software Contract Annex. The Annex helps software buyers and vendors discuss security and capture the important terms. '''Neither the OWASP ASVS nor the OWASP Legal projects should be considered legal advice, and we strongly recommend that you find competent counsel to assist with your contract negotiations.''' The contract annex and this article have been place in the public domain to facilitate use in private contracts.

+

If you are specifying web application security verification requirements in contracts, you can use the [[OWASP ASVS]] to do so. One approach is to start with the OWASP Secure Software Contract Annex. The Annex helps software buyers and vendors discuss security and capture the important terms. '''Neither the OWASP ASVS nor the OWASP Legal projects should be considered legal advice, and we strongly recommend that you find competent counsel to assist with your contract negotiations.''' The contract annex and this article have been place in the public domain to facilitate use in private contracts.

== Example: Using the OWASP Secure Software Contract Annex ==

== Example: Using the OWASP Secure Software Contract Annex ==

−

The OWASP Secure Software Contract Annex can be updated to make use of the newly-released OWASP ASVS.

+

One of the best things you can do to facilitate communication between a software buyer and seller is to agree on the technical security requirements for the application and how they will be verified. The [[OWASP Application Security Verification Standard]] is a simple way to require all this simply by specifying the a level from 1 to 4.

+

+

== Updating the [[OWASP Secure Software Contract Annex]] ==

+

+

The [[OWASP Secure Software Contract Annex]] can be updated to make use of the OWASP ASVS.

'''Change #1:'''

'''Change #1:'''

Line 35:

Line 39:

''Verifier. Developer will be responsible for providing a person or team to review the web application against the OWASP Application Security Verification Standard requirements.''

''Verifier. Developer will be responsible for providing a person or team to review the web application against the OWASP Application Security Verification Standard requirements.''

−

----

−

The author of this article can be reached at boberski_michael(at)bah.com

−

−

Good luck!

[[Category:OWASP Application Security Verification Standard Project]]

[[Category:OWASP Application Security Verification Standard Project]]

[[Category:OWASP Legal Project]]

[[Category:OWASP Legal Project]]

Revision as of 10:05, 20 December 2008

How to specify verification requirements in contracts

If you are specifying web application security verification requirements in contracts, you can use the OWASP ASVS to do so. One approach is to start with the OWASP Secure Software Contract Annex. The Annex helps software buyers and vendors discuss security and capture the important terms. Neither the OWASP ASVS nor the OWASP Legal projects should be considered legal advice, and we strongly recommend that you find competent counsel to assist with your contract negotiations. The contract annex and this article have been place in the public domain to facilitate use in private contracts.

Example: Using the OWASP Secure Software Contract Annex

One of the best things you can do to facilitate communication between a software buyer and seller is to agree on the technical security requirements for the application and how they will be verified. The OWASP Application Security Verification Standard is a simple way to require all this simply by specifying the a level from 1 to 4.

This agreement uses predefined levels that define ranges in coverage and levels of rigor as defined in the the OWASP Application Security Verification Standard (ASVS). The “level of rigor” for the agreement may be selected by a software development organization by specifying an ASVS level. The ASVS defines four levels of verification that increase in both breadth and depth as one moves up the levels. The breadth is defined in each level by a set of security requirements that must be addressed. The depth of the verification is defined by the approach and level of rigor required in verifying each security requirement.

Change #2:

Update section 9, bullet (e) so that its contents read:

Security Analysis and Testing. Developer agrees to provide and follow a security test plan that defines an approach for performing a level <insert ASVS level here> verification according to OWASP Application Security Verification Standard – Web Edition 2008 (Beta), December 2008. The range in coverage and level of rigor of this activity are defined in the referenced standard. Developer will execute the verification and provide the test results to Client according to the reporting requirements which are also defined in the referenced standard.

Change #3:

Update section 10, first paragraph, so that its contents read:

OWASP Application Security Verification Standard defines topic areas that must be considered during the risk understanding and requirements definition activities for the targeted verification level. This effort should produce a set of specific, tailored, and testable requirements. Both Developer and Client should be involved in this process and must agree on the final set of requirements.

In addition, the requirements shall include a set of specific vulnerabilities that shall not be found in the software. If not otherwise specified, then the software shall not include any of the flaws described in the current “OWASP Top Ten Most Critical Web Application Vulnerabilities.”