A DevOps to DevSecOps transformation works best with a structured framework acting as governance. When you approach such a transformation, putting structure around it allows you and your teams to stop, ask questions, and iterate on potential changes to your existing DevOps processes.
Here’s a simple framework to help ensure an orderly DevOps to DevSecOps transformation:
1. Outreach and Education
A move from DevOps to DevSecOps is far from strictly a technological affair. Such a transformation will significantly impact your developers, sysadmins, project management, and stakeholders. DevOps to DevSecOps transformation touches other business units when it enables them to deliver on projects to their customers at a higher velocity and more securely. There may also be changes in how your other business groups interact with your development teams for new feature requirements and related matters.
Outreach and education with developers can take a couple of forms. First, you want to seek developer participation in your transformation. It’s time to create internal advocates and champions for DevSecOps. That’s a little easier to do if your organization is already a DevOps shop. However, you’re going to need to extend your outreach efforts to your security team as well. When you build advocates and champions for DevOps to DevSecOps, your development teams become self-policing towards fear, uncertainty, and doubt amongst your developers who aren’t ready about making a move to DevSecOps. You can only do so much to change developer attitudes if you’re not working with them daily and understand their pain points.
Sysadmin outreach plays out much the same way as developer outreach. Build allies. Work with them through any potential changes to their job duties, especially for bringing security checks and scans into their daily work.
There are also outreach and education considerations that may take you out of your IT department to educate the business about DevSecOps. A move to DevSecOps is going to affect the executive management team over the DevOps teams. You want to set expectations about the benefits of DevSecOps and automation.
Exiting the outreach and education phase means you’ve met with your developers, sysadmins, stakeholders, and management. You’ve also delivered DevSecOps training, whether in-house or through an outside provider, to help upskill your developers and sysadmins and teach them about the benefits of DevSecOps. During this phase, security training may also extend to secure coding and vendor training on the DevSecOps security tools you plan to implement.
This phase is also a good time to survey the market and seek potential vendors to help you integrate security. Visit their websites. Watch their online demos. Ask thoughtful questions about their products and services in such online DevSecOps communities such as DevOps Chat and The DevOps Institute. You should also seek solutions and insights from the open source community that may help you secure your DevSecOps delivery cycle.
If you work inside a large corporation or government agency, establishing a DevSecOps Center of Excellence (CoE) brings together the DevSecOps expertise from across your organization. It can channel them into helping solve some technology and cultural challenges your organization might face in your move to DevSecOps.
2. Implement Security across your Toolchains
Just like you’re giving your DevOps teams a choice in deciding upon their DevOps tools, the same should apply to the DevSecOps security. Whether you have teams choose open source or vendor-based DevSecOps solutions, the only caveat is that your organization’s requirements are met.
This phase may overlap with the Education and Outreach phase depending on your organization’s schedule and related factors.
While you’re building out your DevOps toolchains with additional security tools and features, it’s also a good time to audit the security of your DevSecOps toolchain itself. Remote DevOps teams and the growing prevalence of cloud-based DevOps tools comprising today’s toolchains making for attractive targets. Attackers are targeting toolchains with man-in-the-middle (MitM) attacks to compromise the development environment.
Exiting this phase means your new security measures are in place and generating your required reports. Depending on your organization’s maturity and situation, it may also mean improving the security of your access controls and endpoints against future attacks.
3. Pilot Project
There’s no better way to confirm that the tools and processes you’re putting in place for your DevOps teams to move to DevOps are working than a real-life pilot project. Pick a small internal project with an owner who’s keen to move to DevSecOps. Put your best people on the project and use it as a learning opportunity for your developers and sysadmins. It’s also an opportunity to educate your business stakeholders about the benefits and virtues of DevSecOps because you can show business value.
Exiting the pilot project stage can happen once the project is live and you’ve captured the lessons learned and rolled them back into your DevSecOps processes.
4. Full DevSecOps
Once you hit full DevSecOps, your job still isn’t done. When your organization hits this point, it’s time to take a continuous learning and collaborative approach to development and operations to speed up and secure your software delivery.
Don’t forget an ongoing feedback mechanism once your DevOps teams move into full-on DevSecOps. You want to take in developer and sysadmin feedback to apply lessons learned through a DevSecOps Center of Excellence (CoE) or another forum where your organization can intake the information without filtering through management, bureaucracy, or corporate politics.
DevSecOps isn’t meant to be a static state of being. You need to put your lessons learned into practice. You also need to offer ongoing training to your teams moving to DevSecOps.
Final Thoughts
Taking a systematic approach — such as an adoption framework — moving from DevOps to DevSecOps provides your teams and stakeholders with enough structure to transition their projects and job roles into this new way of developing software securely. This approach allows you to discuss your progress with your DevOps teams and their stakeholders at mutually agreed times during your transformation.
