Achieving DevSecOps Success Depends More on Trust than Tooling

While government IT has made strides in adopting agile development principles in the pursuit of agency missions, the simultaneous adoption of DevSecOps hasn’t been as smooth. In fact, many CIOs have seen their IT functions weakened or incapacitated due to the inability of their internal teams to align.

This fragmentation has the potential to bring significant consequences. Agencies face a higher risk of IT project failure, risk to their mission and the unsavory prospect of wasting taxpayer money, which can undermine public confidence in government services.

Let’s explore what’s behind the cultural clash between the development, security and operations teams, and what can be done to bring them together to help them more effectively pursue their agencies’ missions.

A Three-Way Tug-of-War

For years, development, security and operations groups have operated in neatly defined silos—each performing specific duties, with clear lines of demarcation, isolation and responsibility. DevSecOps often turns this paradigm on its ear, blending organizational constructs, and at a minimum, requiring new levels of trust between the arms of the CIO’s organization.

This leads to development, security and operations groups believing they have diametrically opposed priorities and ways of working.

Development sees its role in missions as delivering new features and functionality in line with business objectives. Agile brings a new pace of change to these activities, with its mantra of continuous change, new requirements and fast implementation of user requirements. The “fail fast, fail often” mentality, aggressive deadlines and frequent deployment requirements can appear chaotic to operations.

In contrast, operations teams may find themselves in a constant state of fire-fighting, going from one outage or technology mishap to another. It’s not to say this is their preferred state of being—simply an outcome of years of technical debt, few modernization efforts and the nature of technology change. Accordingly, operations organizations may be loathed to introduce new changes into their environment, preferring to build and maintain the sanctity of the agency’s systems and environments. Operations team members routinely attempt to prevent chaos from settling in, since freneticism can disrupt or break stable, always-available environments. From the development team’s point of view, operations’ actions are stonewalling at best, hostile at worst.

Security teams, by default, are taught to trust no one. With chaos comes a level of risk that security teams are often unwilling to accept. As security managers are frequently looped out of both development and operational planning and decision making, they may view the activities of those teams with a healthy dose of skepticism.

Bridging the Cultural Divide (“Trust, but Verify”)

More than ever, agency IT departments want to be seen as an equal and trusted partner in the business, so it’s ironic that so little trust exists between their own team members. This fact is not lost on the lines of business and business partners for whom we are attempting to deliver new capabilities.

There are positive changes afoot, however. Development teams have quietly been adding technology to software development processes over the past few years to help contain chaos and limit its impact on operations. This is a distinct behavioral shift—a quest to automate as many development, test and QA processes as possible, to include deployment, code quality and even security scanning. These tools and methods lend themselves well to the concepts of transparency and communication—cornerstones of a culture built on trust.

Development teams would be well served to advertise the value of these new tools and methodologies, while making reporting and metrics available throughout the IT organization. They should make CI/CD development pipelines visible to the rest of IT in the form of a dashboard that can be used for feedback, discussion and planning. That way, other teams can see how quality measures such as stress and security testing and code scanning are contributing to the secure and stable application environments that operations and security want to see.

Better and Stronger Together

It’s worth remembering that no one wakes up in the morning wanting to cause problems for their colleagues. They’re simply trying to deliver on their view of furthering mission success. If they introduce change or act to protect something, they’re just doing what they think is right. What IT team members need is the bigger picture of how each team operates and how they collectively contribute to organizational success.

Trust is based on communication, so improving communications within IT must become a priority for agency CIOs, working together with the heads of the development, security, and operations teams.

If DevSecOps works as it’s designed to, it won’t just result in a higher IT project success rates, it will boost morale and help retain talent. Nurturing a supportive and rewarding IT culture is more vital than ever as greater numbers of engineers and technicians retire, and younger recruits tire of the political stress.

DevSecOps alignment can be a win-win for everyone and can help agencies achieve their mission objectives.

Adam Clater is chief architect of Red Hat's North American public sector business. He works with federal agencies, integrators and Red Hat partners and communities around the world to promote and define the use of enterprise open source solutions.