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

johanna curiel curiel johanna.curiel at owasp.org
Wed Nov 25 16:42:07 UTC 2015

Hi Paul,

Sure. I just have one concern.

We need a way to measure the agreement of the proposal.

For the community, I can launch a Survey, but as far as I'm concern and
informed. The project task force is right now quite inactive except for the
work Claudia is doing with accepting and evaluating new projects. The task
force as original intended is run by volunteers with the support of Claudia
as staff and project coordinator.

So the question is : would it be enough to set a survey with the entire
community can participate?



On Wed, Nov 25, 2015 at 12:34 PM, Paul Ritchie <paul.ritchie at owasp.org>

> Johanna, this is great work.
> I had hoped that someone in the community would pick up on all the email
> discussion and "take action" to form a proposal and convert many of the
> good suggestions and recommendations from leaders into "accepted OWASP
> Policy".
> So, Thanks for leading by example.
> As I understand, the next step is to have the Community, and then the
> Project Task Force "agree to the proposal", and once that is done, it would
> go to the Board for a decision at their Dec. 9 meeting for the 'stamp of
> approval' to implement new OWASP policy.
> Again, thanks, Paul
> Best Regards, Paul Ritchie
> OWASP Executive Director
> paul.ritchie at owasp.org
> On Wed, Nov 25, 2015 at 6:31 AM, johanna curiel curiel <
> johanna.curiel at owasp.org> wrote:
>> 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
>> responsability.
>> 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
>> code.
>> 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 validation)
>>    - 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 bug
>>    - 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:
>> https://docs.google.com/document/d/1Br4I8jKc0tyzdBCq4ohO1LcDNL861xldMBlkA_z6v34/edit
>> 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
>> Regards
>> Johanna
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20151125/76d370f8/attachment-0001.html>

More information about the OWASP-Leaders mailing list