Tips for boosting the “Sec” part of DevSecOps

The most significant barrier to achieving DevSecOps is the continued perception that “Sec” is not already a part of “Dev” and “Ops”, says James Arlen, CISO at cloud data platform provider Aiven. Also, the fact this needs to be explicitly called out is actually a barrier in itself.

“In my experience, this is due to the ‘I’m from Security and I’m here to save you’ mentality that continues to pervade the security industry, and the only way to overcome this is with a big bucket of humility,” he noted.

“Security has not actually spent the last 20 years doing a good job of ‘security things’ and we do not have a strong position to say that we have all of the answers. I know that it sounds relatively simplistic, but it really is a case of taking the path of the beginner’s mind and working with developers, operators, and DevOps staff to learn their perspective and then apply domain-specific security knowledge.”

Security needs humility

Arlen has spent most of its career in the information security industry and filled a variety of roles – from firewall operator to CISO – in small startups, large publicly traded companies, and even in the government sector.

He’s also one of the lead authors of the Cloud Security Alliance Guidance for Critical Areas of Focus in Cloud Computing and the associated Certificate of Cloud Security Knowledge.

On the DevOps side, he has experience as a system administrator and has spent years leading the SRE and Production Engineering teams for the hyperscale environment at cloud platform-as-a-service company Heroku (a subsidiary of Salesforce).

When he says that the best way to make security a cooperative function within other business processes is to stop treating security as a special snowflake set of requirements “that can only be brought down to the peasants from the palace,” I can’t help but laugh, but he insists that he has seen many organizations experience negative outcomes due to the pompous attitude of their security staff.

“Be humble, work with other stakeholders, and remember that security is a priority, but not always THE priority,” he advised.

Getting developers on board with DevSecOps

Here’s another of Arlen’s tips for pushing developers to prioritize security: stop talking about security!

“If there’s a thing that, as a security person, you’d call a ‘vulnerability,’ keep that word to yourself and instead speak the language of the developers: it’s a defect,” he pointed out.

“Developers are already incentivized to manage defects in code. Allow those existing prioritization and incentivization tools to do their job and you’ll gain the security-positive outcomes that you’re looking for.”

All in all, he says that the primary method for improving the security outcomes of development is both easy and complex.

“Organizations need to stop treating security as some kind of special thing. We used to talk about how security was a non-functional requirement. Turns out that this was a wrong assumption, because security is very much a function of modern software. This means it needs to be included as you would any other requirement and let the normal methods of development defect management take over and do what they already do,” he noted.

“There will be some uplift requirements to ensure your development staff understands how to write tests that validate security posture (i.e., a set of tests that exercise your user input validation module), but this is generally not a significant problem as long as you’ve built in the time to do this kind of work by including the security requirements in that set of epics and stories that fit within the team’s sprint budget.”

Finally, he points out that the most essential thing for achieving DevSecOps is “positive programmatic control,” where everything is automated and everything runs because it must.

“Humans should interact with a DevSecOps environment only through adjusting the programming of the control and orchestration systems, rather than by ‘fixing’ any particular system. Supporting this will require both ephemeral and immutable (or serverless) systems and the tacit acknowledgement that any computer which has had an interactive session (command line) with a human is ‘dirty’ and must be replaced as quickly as possible.”