[Owasp-leaders] SecDevOps Risk Workflow Book (please help with your feedback)
sherif.mansour at owasp.org
Wed Nov 2 23:23:14 UTC 2016
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
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
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 :-)
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)
> 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
>>> 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,
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OWASP-Leaders