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

Dinis Cruz dinis.cruz at owasp.org
Thu Nov 3 00:13:56 UTC 2016


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/DinisCruz/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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20161103/0d6f28b4/attachment.html>


More information about the OWASP-Leaders mailing list