Citing the OWASP Framework Security project
The most effective way to bring security capabilities to developers is to have them built into the framework.
- Frameworks are not immune to bugs. They are software. As such, they can be affected by security issues too. Security mechanisms can be bypassed or abused.
- Poor or inconsistent documentation. Using appropriate APIs and invoking those calls in the right way is a crucial aspect for leveraging all security mechanisms. Unfortunately, the quality of the documentation doesn't always facilitate the job of developers.
- Negligence. Developers still need to read (and understand) the documentation. Building secure software is complicated and requires in-depth understanding of all subtle details.
Since the very first days, the CVE Editorial Board has recognized the need to address both software flaws (aka vulnerabilities) and mis-configurations (aka exposures). The CCE project is logical next step in the evolution of CVE to finally address the 'E' in CVE.
To reinforce my point, let's think together about real-life examples for each category:
- Frameworks are not immune to bugs. Apache Struts and the countless OGNL expressions code execution bugs (CVE-2014-0094, CVE-2013-2251, CVE-2013-2135, CVE-2013-2134, CVE-2012-0838, ...), Ruby's Action Pack parsing flaw (CVE-2013-0156), Spring's Expression Language injections (CVE-2011-2730), PHP Lavarel cookie forgery to RCE, ....and many others. Just a few examples off the top of my head
- Poor or inconsistent documentation. Scrypt API misuse, ... what else?.. PHP htmlspecialchars
- Negligence. Ruby Mass Assignment, Java SecureRandom, ...it's getting hard