DevSecOps for a Dollar or Less
DevSecOps for a Dollar or Less
It's time to break down the walls that the terminal model of software development created and scale departments together.
Join the DZone community and get the full member experience.Join For Free
Anyone who grew up with siblings knows the phrase, "There is a wall here!!!!!" Of course, there wasn't a physical wall, but an imaginary border that separated you and protected your space.
In software development, walls aren't helpful. We don't need to protect our space (although sometimes we might feel like it). We need to break down the walls.
In traditional software development, invisible walls exist between the business requirements and the development teams. Development may not fully understand the business goals, the users, etc. The risk is developing software that doesn't meet the goals of the organization.
Enter Agile. It was a positive advancement in communication between the business managers, users, and developers. Still, a wall of confusion may remain between developers and operations. They do not always communicate well. Operations often doesn't understand all that development needs, and development doesn't understand all of operations requirements, or takes shortcuts to work around them.
DevOps seeks to break down the walls so that all of the functions work well with each other, continuously. This enables better understanding and helps stakeholders meet the organization's shared goals and requirements. Mohammed Imran (@secfigo), a security engineer and DevSecOps trainer, spoke on the concepts behind implementing DevSecOps into your organization at last year's All Day DevOps conference.
Mohammed introduced the concept of the evolution of the walls between different business units to start his presentation. He emphasizes how the old software development lifecycle (SDLC) had a definite start and end, but now software development is endless, constantly seeking to monitor, fix, and improve.
But DevOps, not fully implemented, can create a Wall of Compliance between development and security. In reality, security in most organizations has a love/hate relationship with everyone else (kind of like siblings) and they are outnumbered. The oft-quoted statistic is that, on average, there are one hundred developers for each security person, although Mohammed believes it is closer to 500:1.
DevSecOps is the increasingly-common term to note the injection of Security into DevOps, but, done well, Security will already be part of DevOps. Mohammed quotes Bass, Zeber, and Zhu, "DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality." Security is part of DevOps, giving you resilience, speed, automation, flexibility, and reliability.
How do you ensure you are doing DevOps well? To fully implement DevOps, you need to:
- Have a culture that breaks down barriers
- Measure continuously
- Automate the repeatable
- Share tools and best practices
You need all four or you won't reap the benefits.
DevOps is about setting these into motion, giving individuals the ability to collaborate, share, and innovate with responsibility. You let developers drive the car, but you still have guardrails on the road. As Mohammed says — they can go the speed of DevOps, but not beyond where they are supposed to go.
What does it look like to scale security with DevOps? You need to:
- Shift security left by giving the ability and responsibility to implement security at the beginning of the CI/CD pipeline
- Give developers and operations visibility into security activities with self-service tools
- Designate security champions to pick security tasks
- Implement Everything as Code (EAC)
- Use secure by default frameworks and services
- Use the DevSecOps Maturity Model to improve
The DevSecOps Maturity Model (DSOMM) might be a new concept for some. A maturity model helps you analyze your organization to see where you need to improve — or mature. It measures:
- Static Depth: How deep is static code analysis?
- Dynamic Depth: How deep are dynamic scans executed?
- Intensity: How intense are the majority of the executed tasks?
- Consolidation: How complete is the process of handling findings?
Mohammed also walks through 11 tips for choosing and using security tools in CI/CD. For example, when in doubt, ask Developers/QA for help and make sure your tools do incremental/baseline scans.
He also recommends the OWASP DevSecOps Studio as a tool to learn and teach DevSecOps concepts. He walks through a demo and digs into others steps in the DevSecOps transformation. Watch Mohammed's full presentation here.Register today for the next All DayDevOps, November 6, 2019.
Published at DZone with permission of Derek Weeks , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.