*Note: Join us live and online for the 2019 Nexus User Conference on June 12.
Helen Beal was once speaking at a conference about what being a DevSecOps engineer is about. To her surprise, many participants in the DevSecOps track were not on board with bringing Security into DevOps. After probing the audience about this, she summed up the concerns into three categories: It could create another silo; that people in organizations have a hard time understanding DevOps, so it could create even more confusion. And maybe there isn't room for another area.
Of course, Helen disagrees, and she knows a thing-or-two about DevOps and DevSecOps after spending nearly 20 years in the technology industry with a focus on the software development life cycle (SDLC). She is a self-titled DevOpsologist at Ranger4, where she helps organizations implement DevOps. She shares her knowledge around the world, and she joined us for our 2018 Nexus User Conference, speaking on artifact repositories and their role in the DevSecOps toolchain.
From a high-level, Helen presented some key recommendations for DevSecOps:
Ensure security is everyone's job
Recognize there is a constraint with security personnel. On average, the personnel ratio is 100 developers: 10 operations: 1 security
Shift responsibility left and test/verify as early as possible. The lack of sufficient security personnel makes it a constraint. Shift left and automate tasks to reduce the bottleneck and resolve problems earlier
Mitigate risk by being proactive
Nurture a safety culture
Helen took some time to nurture a safety culture, laying out key principles/actions organizations can take into behavioral and systemic safety.
Behavioral safety empowers individuals and teams to act safely while moving forward.
To nurture behavioral safety, she recommends:
Training that failure is a learning opportunity
Ensuring shared accountability and goals across and between teams
Accounting for time to experiment
Using collaboration platforms to share learning and best practices
Writing actions from retrospectives as experiments, and making time to ensure follow-up
She mentioned a couple real-world examples, such as awards for failure at Etsy, LEGO, and P&G, and "fail walls" used by Spotify to make failures visible and addressable.
Systemic safety is building safety into your infrastructure. Her recommendations to nurture systemic safety include using:
Continuous Integration to break builds
Deployment automation drives consistency/ auditability and allows instant redeploy of the last known good state
ChatOps to swarm problems and incidents
Application performance management to deliver early warnings
Limited blast radius approaches, such as feature toggles, canary, blue/green, and microservices
Integration between the service desk and the product backlog
Chaos engineering to teach failure as a habit
After making her case for DevSecOps and laying out how to instill a safety culture, she rolled into artifact repositories. After all, it is a Nexus conference, and artifact repositories are a Nexus specialty.
She began with a quote from Manfred Moser, "Manufacturing without a warehouse = development without an artifact repository." You wouldn't dream of running a factory without some inventory, and you should do the same in software development. The artifact repository holds your inventory of building blocks you pull from, and ensures you have the one you are supposed to use.
An artifact repository is the integration stage of a DevOps toolchain, although it can be referenced in ideation to ensure that the tools you want to use are available.
And, you can't have an artifact repository without an open source policy. Well, you shouldn't. The repository automatically enforces your open source policy, so you won't be like the 35% of organizations who have an open source policy but ignore it.
Helen uses Sonatype Lifecycle as it tells developers the best artifact to use, mitigates risk, and assists Operations and Security to ensure the right software is being used.
The big takeaway is that if you aren't doing DevSecOps, you should. It is inevitable, and it is beyond its infancy. It is a mature concept that requires mature tools to assist you. It takes time to get there, but you will be glad you did.
Sonatype Lifecycle is one tool you can use.