Change Book title (scope creep?)

[davevs]

While doing the review sessions and adding my comments I can't help to notice that the contents are more about 'how to set up a SecDevOps' organisation and not only about 'Jira Risk Flow'.

Should we consider this a scope creep and refocus or do you want this to be the natural flow of the book and maybe change the title to be more in line?

[DinisCruz]

yeah, I have been thinking about that too, I'm happy to change title

I view the Security Champions and set-up of an SecDevOps a key part of the JIRA Workflow, but given the direction of the content, it might make more sense to shift it around (where the JIRA Workflow is part of the Setting up an organisation organisation' (maybe later I can spin off the JIRA Workflow in its own book

[davevs]

I think the jira workflow deserves it's own place. Could be a book, could be a chapter. If this book will be more about 'setting up a secdevops org' the jira workflow can be a detailed example how to set up the information flow. Just keep in mind not all orgs use jira ...

[DinisCruz]

What about these titles (current title is "JIRA Risk Workflow")

1. How to set up a SecDevOps organisation
2. Creating a SecDevOps organisation
3. Security Champions
4. AppSec Champions
5. Risk Based SecDevOps
6. SecDevOps
7. SecDevOps Workflow
8. SecDevOps Risk Workflow
9. SecDevOps Workflow and Security Champions

[davevs]

I'm not sure if you should use the term 'SecDevOps'. At my company we use it (because I thought it sounded the best basically), but DevSecOps, DevOpsSec and Rugged DevOps are also being used out there. For a book I would go for a title that is more neutral. One of our propositions is for example 'Agile Risk Management' which tells it all, but isn't linked to anything specific.

Looking at the contents of the book so far, I think the 2 most valuable items are 'how to setup an information flow' (with the jira flow as a detailed example) and why it is important to have a champion based approach. All the other things are more or less things you need to do in any security implementation, but these 2 items will make the difference between 'just another security program' and a successful implementation of security in an Agile organization.

So looking at your suggestions I think number 9 fits the best, although I would think about something like 'AppSec Champions & Agile Risk Workflows; a guide to successfully embed security in DevOps'

[DinisCruz]

Good points, only thing about 'agile' is that although the word is exactly the idea of the RISK Workflow, that word as huge connotations with the Agile movement (and the fact that the content is not really covering the whole world of Agile)

[DinisCruz]

Btw, I just added a new section of SecDevOps which include a large number of good links into it, see https://github.com/DinisCruz/Book_Jira_Risk_Workflow/blob/master/content/2.Using-jira-workflow/SecDevOps/Good-resources-on-dev-sec-ops.md

This article for example as a great definition of https://www.linkedin.com/pulse/devsecops-secdevops-difference-kumar-mba-msc-cissp-mbcs-citp

SecDevOps (Securing DevOps) The scenario here is an organisation is embarking on a DevOps and agile ways of working adoption journey. There is concern about security and we are asked to advise on how to embed security into the DevOps style of operation. And this means embedding and ensuring "secure by design" discipline in the software delivery methodology using techniques such as automated security review of code, automated application security testing, educating and empowering developers to use secure design patterns etc.

I also like the idea that Sec-DevOps is about security to the DevOps (i.e. fast development workflow)

I share your concern that there are a number of variations of SecDevOps out there, but it is a term that actually is easy to understand and the audience that is current involved with SecDevOps is the audience of this book

At the moment I'm inclining to change it to "SecDevOps Risk Workflow"

[davevs]

Interesting read about SecDevOps vs DevSecOps; never thought of it that way, but it makes sense. The only issue I see is that in the end don't want these to be separate worlds, but 1 cooperation so how would you call that? SecDevSecOps? :)

[DinisCruz]

Well I like the idea (as I started to put here ) that when Security becomes embedded in the SDL, Sec-DevOps just becomes DevOps

Ultimately my view is that we (Security and AppSec), will be doing our job right, when the devs don't have to think about it (since it happens by default, powered by the AppSec team and Security champions working behind the scenes)

See more on this idea on this blog post Secure coding (and Application Security) must be invisible to developers and this presentation "Making Security Invisible by Becoming the Developer's Best Friends" presentation

[DinisCruz]

Closing ticket since #17 is now going to be used to track the change.

@davevs feel free to continue this thread here

[DinisCruz]

Steve's ideas:

• Improving Application Security using JIRA
• A new approach to application security using JIRA