SecDevOps Risk Workflow
SecDevOps Risk Workflow
Risk Workflows to enable SecDevOps and manage Software Risks and Quality
About the Book
This is a book about making developers more productive, embedding security practices into the SDL and ensuring that security risks are accepted and understood.
The focus is on the Dev part of SecDevOps, and on the challenges of creating Security Champions for all DevOps stages.
All content is released under an Creative Commons license (CC BY 3.0) and the GitHub repository Book_SecDevOps_Risk_Workflow contains all text, ideas and issues.
Based on real world applications of these ideas.
Reader Testimonials
Elizabeth Lawler
CEO @ConjurInc
So good to see security issues represented a) in plain language and b) as feature which is non-confrontational!
Daniel Cuthbert
Co-author of the @OWASP ASVS standard
SecDevwhat? A great book on SecDevOps and why you should care.
Table of Contents
-
-
Introduction
- Book under construction
- Change log
- Contributions
- Disclaimers
- License
- Printed version
- This Book has a Dual Focus
- Why GitHub and JIRA?
-
Introduction
-
1. Sec-DevOps
-
1.1 Concepts
- 1.1.1 SecDevOps or DevSecOps
- 1.1.2 Don’t blame the developers
- 1.1.3 Good resources on DevSecOps and SecDevOps
- 1.1.4 History of Sec-DevOps
- 1.1.5 Making the Sec part invisble
- 1.1.6 Rugged Software
- 1.1.7 Using Artificial Intelligence for proactive defense
- 1.1.8 When Failed Tests are Good
- 1.1.9 Why SecDevOps?
- 1.1.10 Draft notes - DevOps
-
1.2 Dev-Ops
- 1.2.1 Disposable IT infrastructure
- 1.2.2 Don’t kill the Ops
- 1.2.3 Everything is code
- 1.2.4 History of DevOps
- 1.2.5 Horizontal DevOps
- 1.2.6 In DevOps Everything is Code
- 1.2.7 Infrastructure as code
- 1.2.8 Patch speed as a quality metric
- 1.2.9 Performing root-cause analysis
- 1.2.10 Run Apps Offline
- 1.2.11 When devs are cloud admins
- 1.3 Sec DevOps patterns
-
1.1 Concepts
-
2. Risk Workflow
-
2.1 Concepts
- 2.1.1 Abusing the concept of RISK
- 2.1.2 Accepting risk
- 2.1.3 Can’t do Security Analysis when doing Code Review
- 2.1.4 Creating Small Tests
- 2.1.5 Creating Abuse Cases
- 2.1.6 Deliver PenTest reports using JIRA
- 2.1.7 Email is not an Official Communication Medium
- 2.1.8 Good Managers are not the Solution
- 2.1.9 Hyperlink Everything you do
- 2.1.10 Linking source code to Risks
- 2.1.11 Mitigating Risk
- 2.1.12 Passive aggressive strategy
- 2.1.13 Reducing complexity
- 2.1.14 Start with passing tests
- 2.1.15 Ten minute hack vs one day work
- 2.1.16 The Pollution Analogy
- 2.1.17 Triage issues before developers see them
- 2.1.18 Using AppSec to measure quality
- 2.1.19 Employ Graduates to Manage JIRA
- 2.1.20 Risk Dashboards and emails
-
2.2 For Developers
- 2.2.1 5000% code coverage
- 2.2.2 Backlog Pit of Despair
- 2.2.3 Developer Teams Need Budgets
- 2.2.4 Developers should be able to fire their managers
- 2.2.5 Every Bug is an Opportunity
- 2.2.6 Every project starts with 100% code coverage
- 2.2.7 Feedback Loops
- 2.2.8 Make managers accountable
- 2.2.9 Risk lifecycle
- 2.2.10 Risk profile of Frameworks
- 2.2.11 Security makes you a Better Developer
- 2.2.12 Test lifecycle
- 2.2.13 The Authentication micro-service cache incident
- 2.2.14 Using Git as a Backup Strategy
- 2.2.15 Creating better briefs
-
2.3 For management
- 2.3.1 Annual Reports should contain a section on InfoSec
- 2.3.2 Cloud Security
- 2.3.3 Code Confidence Index
- 2.3.4 Feedback loops are key
- 2.3.5 Getting Assurance and Trust from Application Security Tests
- 2.3.6 I don’t know the security status of a website
- 2.3.7 Inaction is a risk
- 2.3.8 Insurance Driven Security
- 2.3.9 Is the Decision Hyperlinked?
- 2.3.10 Measuring companies’ AppSec
- 2.3.11 OWASP Top 10 Risk methodology
- 2.3.12 Relationship with existing standards
- 2.3.13 Responsible disclosure
- 2.3.14 Third party components and outsourcing
- 2.3.15 Understand Every Project’s Risks
- 2.3.16 Using logs to detect risks exploitation
- 2.3.17 Using Tests to Communicate
- 2.3.18 Who is actually making decisions?
-
2.4 For security Teams
- 2.4.1 Defensible findings
- 2.4.2 Do security reviews every sprint
- 2.4.3 Risk Workflow for Software Vendors
- 2.4.4 Create an Technology Advisory Board
-
2.5 JIRA RISK Workflow
- 2.5.1 Capture knowledge when developers look at code
- 2.5.2 Describe Risks as Features rather than as Wishes
- 2.5.3 Git for security
- 2.5.4 Issue tracking solution
- 2.5.5 Risk accepting threat model
- 2.5.6 Storing risk issues on JIRA
- 2.5.7 The smaller the ticket scope the better
- 2.5.8 Key concepts
-
2.6 JIRA Technologies
- 2.6.1 Confluence
- 2.6.2 JQL Query Language
- 2.6.3 Jira components
- 2.6.4 Copy and paste of images
- 2.6.5 JIRA dashboards
- 2.6.6 JIRA Filters
- 2.6.7 JIRA Kanban boards
- 2.6.8 JIRA Labels
- 2.6.9 JIRA workflows
-
2.7 Security Champions
- 2.7.1 AppSec memo from God
- 2.7.2 AppSec Technologies and tools
- 2.7.3 Collaboration Technologies
- 2.7.4 Conference for Security Champions
- 2.7.5 If you have a heartbeat, you qualify!
- 2.7.6 How to review Applications as a Security Champion
- 2.7.7 Involvement in senior technical discussions
- 2.7.8 Learning-resources
- 2.7.9 Make sure your Security Champions are given time
- 2.7.10 Making Security Champions AppSec Specialists
- 2.7.11 Regular Hackathons
- 2.7.12 Rewarding Security Champions
- 2.7.13 Security Champions activities
- 2.7.14 Security Champions Don’t Take it Personally
- 2.7.15 Involve Security Champions in Decision-making
- 2.7.16 Supported by central AppSec
- 2.7.17 The Security Champions Concept
- 2.7.18 Threat Modeling workshops
- 2.7.19 Training Security Champions
- 2.7.20 Weekly meetings
- 2.7.21 What is a Security Champion and what do they do?
- 2.7.22 What it takes to be a Security Champion
- 2.7.23 To Add
- 2.7.24 Security Champions
- 2.7.25 Becoming a Security Champion
- 2.7.26 Hack anything that moves
- 2.7.27 BugBounties
- 2.7.28 Developers we need YOU in AppSec
- 2.7.29 Big market demand for AppSec Professionals
- 2.7.30 If you don’t have a Security Champion, get a mug
- 2.7.31 Public references to Security Champions teams
- 2.7.32 Draft notes - Threat Models
- 2.7.33 Capture the success stories of your threat models
- 2.7.34 Chained threat models
- 2.7.35 Developers need data classification
- 2.7.36 Threat Models as better briefs
- 2.7.37 Threat Model Case Studies
- 2.7.38 Threat Model Community
- 2.7.39 Threat Model Confirms Pentest
- 2.7.40 Threat Model per Feature
- 2.7.41 Threat Models mapped to Risks
- 2.7.42 Draft notes - Threat Models
- 2.7.43 When to do a threat Model
-
2.1 Concepts
-
3. Appendix
-
3.1 Appendix A: Creating Workflow in JIRA
- 3.1.1 Creating-a-Jira-project
- 3.1.2 Step-by-step instructions
-
3.2 Appendix B: GitHub book workflow
- 3.2.1 Book creation workflow
- 3.2.2 GitHub Leanpub hook
- 3.2.3 GitHub online editing
- 3.2.4 GitHub repos used
- 3.2.5 Tool leanpub-book-site
- 3.2.6 Atom, Markdown, Graphiz, DOT
- 3.3 Appendix C: Security Tests Examples
-
3.4 Appendix D: Case Studies
- 3.4.1 File Upload
- 3.4.2 HTML editing
-
3.5 Appendix E: GitHub Issue worklfow
- 3.5.1 GitHub Labels
- 3.5.2 Reporting issues
-
3.6 Draft Notes
- 3.6.1 Draft notes - AppSec Tools
- 3.6.2 Draft notes - Code Quality
- 3.6.3 Draft notes - DevOps
- 3.6.4 Draft notes - Developers
- 3.6.5 Draft notes - Government
- 3.6.6 Draft notes - PoCs
- 3.6.7 Draft notes - Threat Models
- 3.7 Audio Transcriptions
-
3.1 Appendix A: Creating Workflow in JIRA
- Notes
The Leanpub 60 Day 100% Happiness Guarantee
Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
Now, this is technically risky for us, since you'll have the book or course files either way. But we're so confident in our products and services, and in our authors and readers, that we're happy to offer a full money back guarantee for everything we sell.
You can only find out how good something is by trying it, and because of our 100% money back guarantee there's literally no risk to do so!
So, there's no reason not to click the Add to Cart button, is there?
See full terms...
Earn $8 on a $10 Purchase, and $16 on a $20 Purchase
We pay 80% royalties on purchases of $7.99 or more, and 80% royalties minus a 50 cent flat fee on purchases between $0.99 and $7.98. You earn $8 on a $10 sale, and $16 on a $20 sale. So, if we sell 5000 non-refunded copies of your book for $20, you'll earn $80,000.
(Yes, some authors have already earned much more than that on Leanpub.)
In fact, authors have earnedover $13 millionwriting, publishing and selling on Leanpub.
Learn more about writing on Leanpub
Free Updates. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.
Learn more about Leanpub's ebook formats and where to read them