How many times have development teams working on new product development using agile approaches had a product release doomed by an impending security review? Development teams using agile delivery frameworks such as scrum deliver new features and package a “potentially shippable increment” of the product as often as every week. Teams using continuous delivery and automation practices such as continuous integration may even get to multiple releases of potentially shippable software every day.
[ Need a primer on continuous integration/continuous delivery? Read What is CI/CD? ]
The hugely understated word in those previous two sentences is “potentially.” What prevents potentially shippable software from being real, shipped software? Sure, it may be purely a business decision. Product ownership may conclude that not enough valuable features have been included in the release to warrant shipping to users. But, often the reasons and impediments are more operational, and we enter into the tail of a “water-scrum-fall” approach struggling to get fewer, bigger releases over the line.
Satisfying the security controller is one of those criteria often overlooked until the eleventh hour that prevents a production release of software.
DevSecOps is a way or working to address this - a set of practices and a mindset that enables a regular flow of continuous delivery of software to production including the satisfaction of security constraints. (Some people describe DevSecOps as baking security into the development process from the start.) Of course, the phenomenon of DevSecOps has brought with it a whole host of new technology and tools to simplify the scanning and protection of software from security threats.
Making security a shared responsibility
But using tools and technology to do DevSecOps is not enough.
If you want to innovate quickly, it’s just as important to make security part of the DevOps culture. Security personnel need to be brought into the process early and often. Security people are critical to success and including them is not a one-time-only move.
The best way to engage security teams is to integrate security into the development teams and its ways of working, and for security to become a shared responsibility across the team. This is often referred to as “shift left,” as we are shifting the focus on security to the left of the overall timeline.
Based on our work during engagements at Red Hat Open Innovation Labs, here are seven ways to better engage people to work security into product development:
1. Product Ownership
The security stakeholders are vital stakeholders to the product owner: From the outset, we should facilitate lots of conversation between development team members and security stakeholders to articulate the value of security in the product.
2. Product Backlog
If there are dedicated features relating to security to be built by one or more teams, each should be visualized on a product backlog, and relatively prioritized according to its value (with economic prioritization models used to justify its relative priority). Getting security people into some product backlog refinement sessions can help generate a shared and negotiated view of security work that the development team needs to undertake.
3. Definition of Done
Where security stakeholders and development teams collaborate over security testing or checks that should be performed for each and every feature, the team should make this a part of their Definition of Done. This ensures security quality as features are built; a team cannot declare a work item as done until the agreed security check has been performed.
4. Continuous Integration and Test Automation
To prevent teams from getting bogged down in too much security testing all the time, look to integrate security testing (including, where feasible, security penetration testing) and scanning tools into the build pipeline. This example video of one of our CI/CD pipelines includes Arachni Zap scanning and OWASP vulnerability checks. Of course, introducing these practices only work if the team adopts a culture to “stop the world” when the build fails because the security checks have failed. Teams need to avoid any more development, fix the problem, get the build passing again, and then progress.
5. Showcase events
Showcase events demonstrate and show the outputs and outcomes of a team’s work over a recent time period. Such events offer an opportunity for teams to show off the work they have been doing to a variety of stakeholders. It’s critical to invite security stakeholders to attend teams’ showcase events at the end of each iteration, to keep abreast of the latest features being built into the solution and to feed back any security concerns to the team and its product owner for inclusion in the next backlog refinement session.
6. Retrospectives
Retrospectives provide opportunities for groups to reflect, inspect and adapt their ways of working. They often take place at the end of sprints but can be scheduled at any time.Teams should be encouraged to inspect data from their own team and solution about performance. This could include static code analysis reports and other reports from security related tooling such that the team can capture continuous improvement actions and items on the product backlog.
7. Empathy mapping
Empathy mapping is a great tool and practice to use to empathize and capture what security stakeholders are thinking, feeling, seeing, and doing in the context of the solution being developed. What better way for development team members to understand and capture the needs of an enterprise’s security team than for them to meet with them face-to-face, interview them and capture the needs, pains, and gains via direct conversation.
So, while technology plays a role in the success of DevSecOps, implementation of it alone is worth nothing. It’s the blend of culture and collaboration with those specific technical practices that enables new confidence and assures continuous and secure delivery of value.
[ Get lessons learned from CIOs applying AI: Download the new HBR Analytic Services report, An Executive's Guide to Real-World AI. ]
