Developer buy-in is critical in implementing DevSecOps. Industry experts explain why it benefits developers and share deployment strategies.
Many software developers in government are driving successful Agile and DevOps initiatives. But in many cases, they and their organizations have left out an important part of the equation: security.
Experts from Microsoft say implementing a DevSecOps strategy in which security is integrated into every phase of the software development lifecycle requires a big culture change, but it’s in developers’ best interest to support it.
By baking in security from the start, developers build more secure and maintainable apps. It streamlines development and can speed product delivery. Testing security early and often — and automating it — also reduces the chances of security staff balking at approving applications at the end of the development pipeline.
“It’s an opportunity to involve the security team in the process sooner — it’s a collaboration. So, it’s not security saying, ‘No,’ to applications all the time because they don’t want to assume the risk,” says Jon Wall, Microsoft’s enterprise security executive.
Collaboration is key. To successfully deploy DevSecOps, developers must embrace collaboration, openness and transparency — the same mindset and principles they champion through their support of the open source community and DevOps practices, Microsoft experts say.
How DevSecOps Fosters Agility and Collaboration
DevOps, which expands on Agile development practices, breaks down the silos between developers and IT operations teams. Together, they build software faster through collaboration, automation and customer feedback. DevSecOps weaves security and security personnel into the mix.
“It’s establishing collaboration between security, development and operations teams from moment zero to the end,” says Harshal Dharia, Azure specialist at Microsoft.
To help change the culture and adopt DevSecOps, the entire team of developers, operations and security personnel must cultivate empathy and listen to each other and their customers and understand their perspectives, says Reuben Cleetus, Microsoft’s senior cloud solution architect.
That, in turn, fosters the collaboration necessary to implement DevSecOps and ensures that everyone on the development team shares ownership of the entire effort, he says.
Information security staff, for example, can talk with developers to better understand what they are trying to accomplish, and together, they figure out a way to develop an application secure enough to minimize risk to the organization, Wall says.
“It’s breaking down the silos and building a healthy, collaborative work atmosphere where it drives quality,” Cleetus notes.
DevSecOps also enables increased agility, Dharia says. Information security staff can educate developers on security best practices, which empowers developers to write code more securely.
And by automating security testing directly into the Continuous Development/Continuous Delivery (CI/CD) tool chain, developers can test their code every day, receive quick feedback on vulnerabilities and resolve those issues more quickly. The result is faster application development cycles and more secure apps for customers.
Open Source Tools Can Help Developers Adopt DevSecOps Practices
As public sector developers begin to pursue DevSecOps, they have many good open-source tools to choose from to bolster security in their software code.
They can choose from a variety of tools across the development pipeline, from the initial software planning and coding, building, testing and release phases to deploying, operating and monitoring an app, says Giulio Astori, Microsoft’s senior cloud solution architect.
From the left, there are also tools that allow you to conduct pre-checks to ensure developers don’t accidentally place sensitive data, such as keys, TLS certificates, database credentials, or access tokens into source code repositories, he says.
They can also take advantage of automated testing, such as static analysis security testing during development and dynamic analysis security testing before the app goes into production.
Furthermore, there are security tools for post-production, such as tools that automate compliance management and tools that monitor the health and availability of applications, Astori says.
“The list of open source security tools is big,” Cleetus says. The key is to build a continuous feedback loop, so the development team can continually make application improvements, he adds.
DevSecOps Best Practices for Developers
In the bigger picture, to deploy DevSecOps, developers must evolve their culture, choose the security tools they want to use and take a phased, incremental approach to implementation, Cleetus says.
Start with a small project — a basic automation process, such as an automated testing system, monitoring solution or a clear change approval process, he says.
“Start with that, build a healthy culture where you are collaborating with each other,” Cleetus says. “You may need to make a change because there is a bug in production. The team is empowered to make the change because they understand they are building something together. They have empathy with each other and the customer. Start with that. And then find the next grain of sand that is clogging your gears and focus on the automation of that.”
Dharia agrees, adding that organizations like Fannie Mae and Capital One successfully implemented Agile development, then DevOps and later DevSecOps because they took their time to do it over several years.
“They started small, and every year, they had a goal to continue to improve. It’s a journey. It’s not something you can do overnight.”
Be sure to check out other topics covered in this series:
- Rapid Deployment: Why DoD Is Ready for the DevSecOps Era
- Ways to Jump Cultural Hurdles to Realize Effective Government DevSecOps
- Shifting Left: How DevSecOps Strengthens Agency Security and Risk Management
- Breaking Down Silos: DevSecOps Makes Security Everyone’s Business
- Government Innovation, Readiness Will Require More than Just DevOps
This content is made possible by our sponsor Microsoft; it is not written by and does not necessarily reflect the views of GovExec’s editorial staff.