OWASP Security Labeling System Project

"(1) STAGE ONE: Determine the reasons to create the labeling system(you could add more, or send your comments about these reasons):

- Security is invisible. We cannot know if software is 'good enough' in terms of security. The user ( and also the developer who uses shared libraries, or creates derived works) have technical and legal impediments in order to know about vulnerabilities and code bugs. The security labels will make security visible.

- In security there is not perfect, just “good enough”. We know that software flaws and Vulnerabilities will always exist. But the label system could at least certify that certain application is following basic security practices.

- Liability does not solve the problem. Legal liability is not an alternative (unless the power of negotiation of the user is huge). All developers will always avoid including liability clauses in contracts. Furthermore, it does not incentive development, and it is more likely that developers hide vulnerabilities instead of sharing them. A labeling system is the alternative.

- We need transnational solutions. There are many jurisdictions, and applicable laws around the planet. The labeling system has to be transnational, so it can be easily applied.

- We need an attractive and easy going label system. This is the key. Users will benefit because they want security, and to know what components are they getting within a software. Developers will benefit because OWASP labeled software would be preferred by users in terms of security.

(2) STAGE TWO: Choose the Sources for the labeling system:

- Follow OWASP Top Ten. The Top Ten project has been widely recognized, and many developers are following it. If they applied it in their business, they can easily share their reports (through a confidence agreement if required) to the OWASP board. This interaction benefits both sides. It is a good basic departure point for the labeling system.

- Use of secure control programming interfaces. We could use the OWASP Enterprise security APIs project. The use of these interfaces could become another source for the labeling system. However, it would be crucial to finish the development of important ESAPIs for most popular environments, specially PHP.

- Follow Security and verification standards. Standards of Security analysis such as the OWASP ASVS standard project. There is a lack of computer security standards (Do you think the ISO/IEC 27034-1 could help to our labeling system?).

- Include security clauses in contracts?. It would be great to include the legal framework. We could depart from the OWASP secure software contract annex as another source of our labeling system. However, I found a couple issues. (1) Clauses can be changed and adapted. It would rarely be taken as a whole. (2) Most contracts are not open to negotiation, and don't have a particular user (Think about an EULA). I believe the solution would be to create a Soft Law instrument, something like 'the OWASP security software principles' (Soft law instruments such as the principles of the UNIDROIT in International commercial contracts), which includes all the principles and rules contained in the Software Contract Annex. It would be easier to just refer to all the OWASP principles including a Software security clause in the Contract.

(3) STAGE THREE: Application of the labeling system (How to make the labels. No graphics yet). We need ideas here. I am thinking about 4 different kinds of OWASP labels ( Please send your proposals). This is just an idea:

- Ingredients criterion label (I). This label certifies that the software reveals all software components compiled in the binaries(if not FOSS) and used during development. (eg. Shared libraries, APIs, and so on).

- Security 'good enough' criterion label (S). This would be the standard certification label. This label certifies that the software is 'good enough' because follows good security practices in its development life cycle, updates and security patches.

- Legal 'good enough' criterion label (L). This is an additional label in case that the contract includes security software clauses following the OWASP principles.

- Disclosure of vulnerabilities criterion label (D). This label consists in the open disclosure of vulnerabilities of the software or Web Applications to the users. Perhaps not many enterprises or web administrators will like to reveal their vulnerabilities. However, the proposal is interesting."