Creating a Language for Security with Chef’s Adam Jacob

November 27, 2019 | in Case Studies
| By Hayley Denbraver

As 2019 draws to an end, we are going to be looking back on some great episodes of our podcast The Secure Developer. See the first post here and the second post here.

The Secure Developer podcast is part of our vendor neutral, security education focused community MyDevSecOps. The community, previously also known as The Secure Developer, meets virtually via our Slack group and virtual events, and in person at DevSecCon events around the world.


About our guest

Adam Jacob is the co-founder and CTO of Chef, formerly known as Opscode, where he wrote the open-source, automated applications project Habitat. Previously, Adam founded HJK Solutions, an automated infrastructure consultancy. He joined us on the Secure Developer podcast recently to discuss:

  • the world of DevOps
  • designing language around security
  • the benefits of a continuous system when monitoring for vulnerabilities
  • & more

Let’s dive into how the conversation played out.

DevOps: Is It About the Tools or the People?

The typical industry consensus is that DevOps is more about the people, but Adam makes the excellent point that it’s necessarily about both. Anyone can say, we want to have a good culture around DevOps. But at the end of the day, it’s just words. According to him, “Usually, it’s the technology that reinforces those cultural behaviors.”

That thought process can be applied to security, too. Anyone can say they want to operate more securely, but you must have the right combination of systems, teams, and technology in place or you won’t achieve your goals.

You need both the tools and the education for your people. If you have the tools but people don’t know how to use them, or they have no understanding of what they’re for, then you’ll never achieve your security goals.

Creating a Language Around Security

When discussing security, context is everything. Adam and his team addressed this at Chef by developing InSpec, which is essentially a language for letting team members describe security posture and code. Another challenge with security is that many aspects of it are “invisible,” meaning if you don’t have a way to talk about it or track it, then you won’t be successful.

Security should be baked into the process from day one. Being able to provide an ongoing report of vulnerabilities through tools such as InSpec has lasting benefits and results in quick and measurable change.

Finding a way for developers to talk about security in the language of code is invaluable because it allows for more people to participate in the security process. Additionally, you can have security people audit the code, as opposed to audit documentation, and then incorporate it all as a living piece of that deployment model. Adam believes this process (which also goes by the name SecDevOps) ends up ensuring a higher level of security.

Continuous Deployment vs. Continuous Delivery

High-level continuous deployment built into your whole infrastructure’s code allows you to achieve predictability. However, the whole notion of “continuous” is that you must continue to roll it out. In other words, you can pause, but you can never stop. Whereas, according to Adam, continuous delivery does allow time for breaks.

In continuous delivery, the idea is that you are shipping when it makes sense to ship and any time that the business requires shipping. This is a contrast to continuous deployment, where the idea is to ship every time you commit. Therefore, with continuous delivery, Adam believes there’s plenty of space to say that, “This project, in order to ship, requires a security review,” and that process can still be continuous. It’s a nuance, but one that may help a lot of teams re-frame the relationship between development and security in a positive way.

Adam also makes the point that one of the values of both continuous delivery and deployment, is that they enable teams to spot errors when they’re still small. That value proposition is pretty compelling in security. If you are looking for a security flaw, being able to only have to examine a range of whatever 100 lines of code need to change, versus the 100,000 or 100 million lines of code that exist, is very valuable.


MyDevSecOps is committed to bringing excellent speakers like Jeff McAffer to both our virtual sessions and our podcast, The Secure Developer. If you are interested in learning more about all aspects of security, please consider joining the community