Follow us

“This is only for Dev…”

This is only for dev

Ladies and gentlemen: the story you are about to read is true. Only the names have been changed to protect the innocent.

A security architect sits at her desk, lost in thought.

“Excuse me, Tina? Do you have a minute?”

Tina looks up. It’s Quentin, one of the developers.

“Sure, Quentin. What’s up?”

Quentin pulls up a chair, and places his laptop on the desk in front of Tina.

“I just wanted to show this to you. It’s something we’ve been working on and this is how we are going to secure it.”

Quentin points to a diagram on the screen. Tina studies it for a few moments, and her face begins to contort in anguish.

“I know it’s a bit rough but don’t worry! This is only for Dev! It will never go into Production!” Quentin says, hurriedly.

Tina takes a deep breath. “Ok, no problem. I need time to review and understand the architecture. Can you set up some time for us to go through it next week?”

Fast forward to a week later. Tina sits alone in a meeting room. She glances at the clock again, sighs and gets up from her chair.

Tina walks across the office floor to Quentin’s desk. Now, she is the one interrupting his thoughts.

“Hi, Quentin. Did you forget about our meeting?”

He looks up, sees Tina. A sheepish expression flashes across his face.

“Oh yeah… sorry about that, Tina. It’s actually fine now though. We had to push the changes to Production for our next release. It’s ok, we got it signed off.”

Tina walks away. She’s not angry. This is not new to her. Tina has learned that things are rarely (if ever) done “only for Dev”.

This is what happens when developers are under pressure to release new features quickly, and security teams are stretched so thinly that their availability has a lead-time of a week or more.

As a result, priorities become forced to compete with one another. Despite everyones’ good intentions, agreed structures become stressed and can fracture. Organisations are faced with a choice between two evils: the costly, disappointing delay versus the speedy but risk-laden release.

I have been in Tina’s position many times. I don’t blame the Quentins of this world — they want to do the right thing, but routinely find themselves in an impossible situation.

If you could make one change to how the interaction between Tina and Quentin played out, what change would you make?

Would you ease some of the pressure on Quentin, allowing him to wait until the meeting with Tina before he released his changes into Production?

Or would you free up some of Tina’s time, so that Quentin didn’t have to wait a week to get her input?

I used to think those were the kind of things that needed to change, but then I started to think about it differently. I went right back to the start.

What if the sight of Quentin’s diagram hadn’t made Tina recoil in horror? What if Quentin had used a tool that allowed him to identify security controls easily and seamlessly at the very start of the design process? What if Tina had access to that same tool, allowing her to review multiple projects easily and efficiently?

Thinking about things in that way is how Akeero was born, and I believe that it delivers:

  • Secure and compliant infrastructure
  • Increased team and resource efficiency
  • Reduced security spend and effort
  • Increased speed to market for secure products and services

If you found yourself identifying with Tina or Quentin, or if the situation resonated with you from your own experiences in your organisation and you want to learn more about what Akeero can offer, please reach out to me. Or if you simply want to share your thoughts about this blog post, I’d be delighted to hear from you.

Akeero automates product security design and compliance for cloud-native environments, enabling teams to deliver secure apps and networks better, faster.

Ready to jump onboard?

Akeero helps you design quickly and securely.