[Owasp-leaders] Initiative Bounty program - Heavier testing and requirements for Defender Libraries

johanna curiel curiel johanna.curiel at owasp.org
Wed Nov 25 14:31:10 UTC 2015

Hi leaders

Recently, I had a wide discussion with the Board regarding setting higher
criteria for projects in the area of defender Libraries such as implement
heavier security testing for them. A couple of weeks ago we also discussed
about this issue, especially because it holds a certain level of

If we are setting projects that are supposed to protect applications, but
if we don't even do a minimum check up on them, then we definitely don't
practice what we preach ;-)

Fact is, there is no testing at all required for these libraries and we
don't know if they withstand  the security as they claim, especially if
these projects are being advertised as 'LAB' or Flagship.Or even worse if
they make the application more insecure ;-P

With some of the ideas and discussions related to this,we came with the
following plan, which I'll be supporting as a Pilot project for one
flagship or lab Defender library, and see if we can implement this as part
of the Process review for defender libraries willing to become Flagship (or
hold their status).

*For incubators(Defender libraries):*
Minimum requirement:
Projects in the area of Incubator defender libraries must provide and
publiciseat least quarterly automated scans (analysis through
Coverity/SWAMP or any other automated DAST/SAST scan tool) to verify their

LAB*(Defender libraries)*:
Minimum requirements
Same as incubator,including a bounty program sponsored by OWASP(with a
maximum amount of US500) to test the project through bug bounty when
requesting to become flagship.

Flagship*(Defender libraries)*
Same as Incubator and labs, including a bounty program sponsored by OWASP,
to test the project through bug bounty program.

The Bug bounty program will be run once a year to verify their status.

The idea is that all these projects must  publicise security scans as a
minimum requirement to verify their security level. We are aware that
automated scans can miss issues and contain false positives, but at least
there is a minimum check up and if issues are found, they must publicise
this on their wiki and avoid any users to use them as they are.

PILOT project proposal for ONE flagship or LAB project (example CRSFGuard)

   - Create draft plan with Project leader
   - Do a static code analysis in the Coverity/SWAMP/similar tool
   - Verify results with Project leader
   - If no major issues are found, deploy library in a dummy site to test
   the scoped issue(s)
   - Do a vulnerability scan using ZAP/BURP to see if they are able to
   catch the scoped vulnerability (in this case CRSF attack)
   - No bug found then proceed to setup 'scoped' bounty program for finding
   specific CRSF vulnerabilities (bypass crypto/CRSF missing server side
   - Run the bounty with a max period of 3 months or less (if scoped issues
   are found before)
   - If issue found, we proceed to log the issue into Github's project
   - Leader must create warning on his wiki and github page regarding the
   - Allow leader to work to fix the issue for a max period of 3 months
   - If issue is not fixed by then, project should be set as inactive or
   'in progress'==> whether way users must be aware of the security issues
   - In case the library is 'unbreakable' after 3 months , no money has
   been spent in this period and we have effectively QA the library until a
   further new version

A draft version right now can be found here:

Jim will be providing also his input on the definition of the scope.

Your feedback and ideas are all welcome as we are in the process to define
the pilot project scope


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20151125/4d3e06c1/attachment.html>

More information about the OWASP-Leaders mailing list