From Water-Scrum-Fall to DevSecOps

As organizations abandon the waterfall method of software development for Agile, many are stuck in what Hasan Yasar terms Water-Scrum-Fall. That is, the organization has not effectively embraced Agile and DevOps principles and remains in silos with no links to business goals. Enter DevOps, an extension of Agile thinking. While Agile embraces constant change and embeds the customer into the process, DevOps embraces constant testing and delivery and embeds operations into the team to internalize expertise on deployment and maintenance.

This is how Hasan started his talk, Multi Security Checkpoints on DevOps Platform, at the All Day DevOps conference.

In his talk, Hasan lays out a plan to get organizations to DevSecOps. Really, DevOps is a risk mitigation strategy, built on situational awareness, automation, and repetition. But, security is where a lot of DevOps implementations fall down.  The goals for each organization should be:

• Protecting private user data
• Restricting access to data/systems
• Protecting company data/intellectual property
• Standards compliance
• Safeguarding disposition/transition

 But, how do organizations get there?

First, integration and communication. Every point of the product development lifecycle should be integrated and communicating, including among the tools. Once this is achieved, you can automate many, if not most, of the tasks. The automated steps are the ones that require less human actions/input to the software development process. This allows everyone to focus on innovation and better code and less on tasks that can be automated by autonomous systems. Also, tasks that can be automated are less susceptible to errors.

Of course, it is the team that ultimately designs, develops, and delivers the software. Your team consists of development, IT operations, quality assurance, and security. Each has its own skill set and focus, and the overlap is Secure DevOps.

The team is in place, processes are automated, and development has started. Development in this day-and-age has evolved tremendously from even just a few years ago. Previously, software was limited to size, function, and audience and the supply chain was practically non-existent. Your team built each component. Now, development has grown beyond the ability of an organization to develop outside of its core competencies. The supply chain now involves many sources for the code. It is more like plug-and-play, and this creates lots of vulnerabilities.

 Hasan notes the software supply chain risk factors:

• Supplier capability - Does the supplier follows practices that reduce supply chain risks?
• Product security - Is the delivered or updated product acceptably secure?
• Product distribution - Does the method of transmitting the product to the purchaser guard against tampering?
• Operational product control - Is the product used in a secure manner?

To reduce your supply chain risk, Hasan recommends:

• Ensure supplier security commitment
• Evaluate a product’s threat resistance
• Create a centralized private repository of vetted 3rd party components for all developers
• Establish good product distribution practices
• Minimize variation of components to make things easier

Finally, as you transition to DevSecOps, remember that security must be addressed without breaking the rapid delivery, continuous feedback model.

You can watch Hasan’s entire talk online here for more details and other tips.

If you missed any of the other 30-minute long presentations from All Day DevOps, they are easy to find and available free-of-charge here.  Finally, be sure to register you and the rest of your team for the 2017 All Day DevOps conference here.  This year’s event will offer 96 practitioner-led sessions (no vendor pitches allowed).  It’s all free and online October 24th.