Secure Software Development and OWASP

By Peter van Schelven


For years now, IT practice has shown us that so many contracts on the development of software have been troublesome on one main subject: the specifications of what has to be developed, delivered and implemented. These specifications often turn out to be vague, incomplete, inconsistent or incomprehensible. As a result, the features and capabilities of software can be disappointing and parties can easily argue about what has actually been agreed to. We see this problem even more regularly with regard to the security of software. A lot of software development contracts are rather silent on security-related specifications and security-specific terms and conditions.


When developing and implementing websites and web applications, software developers sometimes ignore the Open Web Application Security Project (OWASP). That is remarkable. After all, OWASP is a security platform on which software professionals, companies and other organizations share useful information and techniques about the security of web-applications. OWASP, a non-profit organization, has more than 200 branches in about 100 countries, including the Netherlands. In particular, the organization has gained global authority for its OWASP Top 10, a standard for web application security. It describes the ten major threats against web applications. The OWASP Top 10 represents a broad consensus about the most common security risks to web applications and how to protect oneself against such threats.


For more than a decade, the list of ten critical threats has been topped by injection flaws, e.g. SQL-injections. Structured Query Language (SQL) is a textual language used to interact with relational databases. SQL-injection can be used to send untrusted data – a SQL-query – to such a database. Information on a server can be accessed by means of SQL-injection, which access would be impossible without that injection. If one gains unauthorized access to information on a server by means of SQL-injection, this can constitute criminal hacking. One can say that a SQL-injection is a ‘penetration using false signals’ as referred to in article 138ab of the Dutch Criminal Code.


Although SQL-injection now represents about 65% of all web application attacks, generally rather little attention is given to it, both by software developers and their clients. What stands out is that this subject is often not addressed in the terms and conditions of the agreement between the parties. This may be explained in part by a lack of in-depth knowledge about security among the (legal) people involved in drafting or assessing the agreement. The easy way to promote secure code is by explicit stipulating that the software developers will have to take all necessary technical and organizational security measures in order to ensure that the web application will be at least state of the art protected against vulnerabilities as described in the OWASP Top 10. Such a contractual provision has to be described as a minimum level of security.


A more thorough approach can be reached by using the so called ‘Secure Software Development Contract Annex’, a public domain document published by OWASP. This Annex is intended to be appended – in whole or in part, and whether or not modified – to a software development contract. The Annex is focused on encouraging the quality of security. It provides 16 detailed clauses, so each stage of the life cycle of the software is covered. Among all kinds of relevant subjects attention is given to, for instance, security requirements as a part of the specification of the software to be developed, the design and the structuring of secure software code, the complex interaction of the software with other custom software and third party software (e.g. libraries, frameworks, components, and other products, whether commercial, free, open-source or closed-source), the use of a set of common security control programming interfaces, security analysis and security testing according to a specific OWASP standard (OWASP Application Security Verification Standard), security acceptance and maintenance. An important aspect of the Annex is that a security review of web applications should not only cover all of the agreed security requirements, but also other common vulnerabilities. From that point of view there is a link between the OWASP Top 10 and the Annex. The review may include vulnerability scanning, static analysis of the source code, expert code review, penetration testing or a combination of these methods.


Security risks
The OWASP Annex does not only provide legal text. It is also an instrument to facilitate discussions and negotiations between software developer and client on the question who will take the risk for security vulnerabilities. The document says: “Currently, in this agreement, the Developer takes the risk for problems that were covered in the requirements or should be covered by reasonable testing efforts. But remediation of “novel” security issues is to be paid for by the Client. We believe this is a useful balance, as the Developer can bound their risk, and encourages Client to get the security requirements correct up front.”


Due to the comprehensiveness of the Contract Annex of OWASP, it is rather difficult to understand why the document, to my impression, has barely found its way into IT practice (in the Netherlands). To my opinion legal professionals working on IT Law and IT contract managers would be wise to familiarize themselves with the OWASP Top 10, the OWASP Contract Annex and the OWASP Application Security Verification Standard. The undisputed importance of secure software development justifies that IT lawyers and anyone else who drafts or assesses software contracts should have a certain knowledge of the standards and facilities provided by OWASP.


OWASP Top 10 Vulnerabilities (2017)
1. Injection flaws (e.g. a SQL-injection)
2. Broken Authentication
3. Sensitive Data Exposure
4. XML External Entities (XXE)
5. Broken Access Control
6. Security Misconfiguration
7. Cross-Site Scripting XSS
8. Insecure Deserialization
9. Using Components with Known Vulnerabilities
10. Insufficient Logging & Monitoring


About the author
Peter van Schelven is a specialist in IT and IP law and the founder of his practice Bij Peter – Wet & Recht. As legal counsel, Peter deals with issues relating to data protection and cybersecurity. His area of expertise also extends to alternative dispute resolution and arbitrarion in IT.