[Owasp-leaders] Initiative Bounty program - Heavier testing and requirements for Defender Libraries
claudia.aviles-casanovas at owasp.org
Wed Nov 25 16:48:13 UTC 2015
I just want to be clear I am not accepting or evaluating projects. I have
created platform for volunteers to review projects and the community will
have a chance to provide feedback and before acceptance. We have just
started this effort last week with Project Task Force and currently have
about 6 volunteers on board.
On Wed, Nov 25, 2015 at 8:42 AM, johanna curiel curiel <
johanna.curiel at owasp.org> wrote:
> 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
>> 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
>>> 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
>>> - 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:
>>> 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
>>> OWASP-Leaders mailing list
>>> OWASP-Leaders at lists.owasp.org
Claudia Aviles-Casanovas <claudia.aviles-casanovas at owasp.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-Leaders