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

Dinis Cruz dinis.cruz at owasp.org
Fri Oct 28 23:35:34 UTC 2016


>
> 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"*

Does that make sense?

Btw, do you open JIRA tickets for the issues/risks/threats raised by Threat
Models?

Thanks for the great feedback

Dinis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20161029/5cdeec53/attachment.html>


More information about the OWASP-Leaders mailing list