[Owasp-leaders] SecDevOps Risk Workflow Book (please help with your feedback)

Dinis Cruz dinis.cruz at owasp.org
Thu Nov 3 12:47:42 UTC 2016

Simon, that is a really good point and one that definitely doesn't happen
as often as it should

I want to add a section about it to book, so I'm tracking it on this
issue "expand
on 'create feedback loop with tool vendors'

I've starting writing a bit about it here Invest In Open Source Products

On 3 November 2016 at 08:44, psiinon <psiinon at gmail.com> wrote:

> Yeah, definitely a good idea.
> Special request - if an issue is a false positive generated by a tool can
> one of the actions be to inform the tool developers (open/closed,
> free/commercial) ?
> People always complain about false positives but very few seem to get
> reported (at least to us) :/
> Cheers,
> Simon
> On Thu, Nov 3, 2016 at 12:13 AM, Dinis Cruz <dinis.cruz at owasp.org> wrote:
>> HI Sherif, that is great feedback, yes it helps a lot
>> I agree that we need to add those workflows. I have a couple examples for
>> them that I need to (re)create in a public JIRA, so that I share it and use
>> their diagrams (btw, do you have examples you can share?).
>> And you are spot on on the need to create a two way communication channel
>> between devs and AppSec
>> I really like those extra metrics and analysis that you are proposing
>> (need to try them out :)  )
>> (btw I created this issue so that I can track all points made and make
>> sure they are all addressed https://github.com/D
>> inisCruz/Book_SecDevOps_Risk_Workflow/issues/146 )
>> On 2 November 2016 at 23:23, Sherif Mansour <sherif.mansour at owasp.org>
>> wrote:
>>> Hi Dinis,
>>> There should be a workflow, when it is a false positive, and for either
>>> the security team to challenge that claim or for them to apply a change in
>>> their tooling to improve the quality of the results.
>>> Additionally, you might also want the option for the developer/tech team
>>> to request more details as info is incomplete to re-create or understand
>>> the security issue.
>>> I think the common theme for those to points is that the developers are
>>> not always at fault and the conversation needs to be a two way street so
>>> security engineers get better and communicating and tuning their tests with
>>> the developers.
>>> Another thing is the resolution state. Jira has a few (User error/will
>>> not fix/fixed/etc..). You might want to use resolution states so you can do
>>> analysis off the back of it. What type of issue resulted in the most false
>>> positives? And which issues did dev teams accept the risk the most? Etc..
>>> Hope that helps :-)
>>> -Sherif
>>> On Sun, Oct 30, 2016 at 11:43 AM, Dinis Cruz <dinis.cruz at owasp.org>
>>> wrote:
>>>> Andre see I just updated Describe Risks as Features rather than as
>>>> Wishes
>>>> <https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/blob/master/content/2.Risk-workflow/Jira-risk-workflow/Describe-risks-as-features.md> which
>>>> expands on this topic (namely how to write those RISK tickets)
>>>> Dinis
>>>> On 29 October 2016 at 00:57, Andre Gironda <andreg+owasp at gmail.com>
>>>> wrote:
>>>>> On Fri, Oct 28, 2016 at 4:35 PM, Dinis Cruz <dinis.cruz at owasp.org>
>>>>> wrote:
>>>>>> Really enjoy the parts on JIRA -- I liked the parts about making Risk
>>>>>>> a separate project but what if appsec requirements/documentation are listed
>>>>>>> in its own Epic instead?
>>>>>> That can work, the prob is that it is easy for those Epics to fall
>>>>>> into the 'backlog pit of despair
>>>>>> <https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/blob/bbb2f5ee5c3e8a0e1f9cca43b47019e8fcfc1d25/content/2.Risk-workflow/For-developers/Backlog%20Pit%20of%20Despair.md>'
>>>>>> and start to be ignored (i.e. unless you have that 'Risk Accepted' button,
>>>>>> it is 'cheap and easy' to just keep prioritising other 'really important'
>>>>>> features required by the business/users). Another issue is that I like to
>>>>>> use the JIRA Risk project to describe 'reality' (i.e. the
>>>>>> Risks/Issues/features that exists or will exist soon) and then let the
>>>>>> dev's use their JIRA project (or whatever bug tracking system they use) to
>>>>>> describe what needs to be done (i.e. how they would address those RISK
>>>>>> issues) For example a RISK issue (in the separate RISK or APPSEC Jira
>>>>>> project) would be *"Xyz app - There is no Authentication on exposed
>>>>>> Web Service's methods" , *who would (when in the 'Allocated for Fix'
>>>>>> stage) be linked into another ticket (or multiple tickets) in the
>>>>>> application's JIRA project that would be called *"Use Spring
>>>>>> Security to authenticate users of service"*
>>>>> This is great and adds context for me. I'll let you know how this
>>>>> conversation goes with the powers that be.
>>>>>> Btw, do you open JIRA tickets for the issues/risks/threats raised by
>>>>>> Threat Models?
>>>>> Yes, and I very-much also enjoyed the notion of Chained Threat Models.
>>>>> I think I used those exact same words the same day that you did to describe
>>>>> the very-same thing. Uncanny.
>>>>> Thank you,
>>>>> Andre
>>>> _______________________________________________
>>>> OWASP-Leaders mailing list
>>>> OWASP-Leaders at lists.owasp.org
>>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
> --
> OWASP ZAP <https://www.owasp.org/index.php/ZAP> Project leader
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20161103/bb0d772d/attachment.html>

More information about the OWASP-Leaders mailing list