In recent articles on the GovDevSecOpsHub, my associate, Rick Stewart, defined DevSecOps, and the need for a collaborative approach that includes all aspects of the development lifecycle, including security. DevSecOps is the result of several paradigm shifts from waterfall methodologies, to early Agile processes, to mature Agile which has led to DevOps, and now DevSecOps.
This journey has created methodologies to promote faster software development, with security embedded in the process. This move forward is made possible within an organization if they embrace two things – new technologies and cultural change.
In my next article on the GovDevSecOpsHub, I’ll provide an overview of five key new concepts that are making DevSecOps possible. But first, let’s talk about the cultural problems and requisite organizational changes that are necessary for a DevSecOps approach to be effective within a government agency.
Today’s DevSecOps teams need to take on a unified perspective, with collaboration and open communication being keys to this success. The input and involvement of each viewpoint within your teams from the beginning allows the project to focus on continuous improvement – improving the most important thing at any given time as determined by all stakeholders.
Team culture must promote the high value of each team member and see each as necessary for your own individual success, regardless of the skillset we each bring to the table. This collaborative approach amplifies feedback loops for continuous improvement to bring about the best possible value to the enterprise.
The free flow of information is imperative for meeting the goals of the overall mission. Governmental agencies can lead the way by finding ways to share information across multiple contracts throughout the bidding process.
With projects being ever more linked and dependent on the work of other contracted developers, a move toward a more transparent process would enable DevSecOps principals to deliver on the benefits of this methodology. No one would suggest this to be an easy endeavor to sort out. But, overcoming this challenge would be a major win for your teams, projects, and ultimately the end user.
The emphasis on security-related activities to DevOps places this responsibility into the hands of everyone. If any application fails security for the end user in any way, all teams will fail. Your teams need to learn to help each other out early in the process.
Move quick and fail fast
If you’re going to fail, fail fast. When an operations team identifies a potential server issue early in the development process, that’s a win. When your security minded teammates uncover a vulnerability while the project is being coded, your development teams deliver successful applications, and more quickly.
Ferreting out good solutions fast is the key. In the past, 80-85 percent of software sat on the shelf because the applications no longer met the goal when developed or failed to produce secure and usable services. Today, these projects should be terminated as early as is possible. This is only possible if teams are working collaboratively and there is a constant feedback loop.
When everyone sees security, operations, development and testing as shared responsibilities, the “art of the possible” becomes a reality. DevSecOps is the framework that produces adequate feedback and the transparency that our development cultures need to accomplish these great things.
Picking the right tools for the job is important, alongside creating the healthy cultural approach that I just discussed. Dictating a set of tools without considering culture can stymie adoption. They should be selected specifically for your organizational culture based on preference, workflow, and optimal collaboration.
DevSecOps is really like a Venn diagram requiring a convergence of people, processes, and technologies. The wrong choice of technology, or poor cultural dynamics, can create a negative impact. In DevSecOps, we need to be mindful of all three – people, processes, and technologies.
