SecDevOps: Can there be happiness in security work?


February 19, 2015 | DevOps | Dustin Collins


Stress and burnout are a very real concern in the InfoSec community. We talk about it at conferences, on podcasts, on Twitter, and on our blogs. There are even support groups and projects dedicated to the burnout in the security industry. I won’t go into the many studies and statistics on the issue, they are readily available elsewhere. Rather, I’d like to talk about this problem as it relates to the SecDevOps movement, where we have security teams engaged with dev and ops teams, in some cases as an embedded asset on a cross-functional team.

Metrics matter, data-driven decisions are a key part of the DevOps movement, the M in CAMS. For a couple years now I’ve been collecting a ‘happiness’ data point during our sprint retrospectives. 1-5, how happy were you with how the past sprint has gone, how happy are you working here? This is a subjective and emotional metric, not tied to units of work produced or business goals. The team is cross-functional with sec/dev/ops all working together and the team score is an average of everyone’s individual score. Here’s the graph from 2014, sprints were 1 week long:

Pretty content, for the most part. There were two factors that made the team report as less happy: lots of security work in the sprint and unclear business requirements. The latter can have many causes: unclear market, poor communication, and so on. Let’s focus on the former – why does increased security work in a sprint make a team unhappy?

#1: Low incentives and rewards

Security is seen as a cost center in many organizations, something you have to write a check for to avoid a potential disaster. Often, security is built into a product just before launch. Deadlines are looming, corners are cut and it is hard to be certain when enough is enough. Security is seen as a liability, not a feature, and stakeholders are not invested in the progress of the work being done.

Let’s compare the reactions of stakeholders during end-of-sprint demos.

A new product feature

A new security feature


Security work is not usually visual; running through a series of CLI commands during a demo is not likely to inspire. I’m not saying we have to have a GUI for everything. But security work must be a first-class citizen. We have to reframe the conversation if we want others to participate.

#2: Security slows down development

There is a line between being thoughtful about security and being a drag on velocity. Without cross-functional collaboration this line is easy to cross without knowing it. As Ops is coming to be seen as a service by providing platforms and reliability, Security should also be viewed as a service. If developers are being blocked by waiting on credentials, if ops are being blocked by waiting on security topology changes – this is a broken service. Tools like conjur can help. Ultimately, though, our security processes need to be regularly evaluated by all teams affected by them. Not giving dev and ops a voice leads to them being less invested. Less investment means a broken process that is worked around.

#3. The blame culture

Someone hacked into our Postgres, who let this happen? Someone rotated an API key and our services went down, who is to blame? The root cause of security problems is too often seen a person and not a process. It is easier to point out the troublemaker than take a good look at our security process and see what went wrong. A dev puts the PostgreSQL password into their source code because no one has yet figured out how to run tests with credentials in CI. Ops doesn’t lock down the RabbitMQ management console because they’ve been waiting on passwords to be made available to them all sprint. These types of problems are the symptoms of broken processes. The results of a postmortem should be action items to improve how we work together, not a demotion or public shaming of an individual. Accountability is necessary but we do ourselves a disservice by focusing more on blaming than improving.

Taking the time to address these issues is more important when transitioning to SecDevOps, not less. Security, development and operations share pain points. The cultural and organizational issues that security has been struggling with are now out in the open and impacting other teams that they work with more closely. Working together to improve communication and workflows is key to the success to SecDevOps. Let’s put a priority on happiness.


Share This