Follow us


The Curious Incident of the Dogfood Pen Test

You’ve probably heard the expression “dogfooding” or to “eat your own dog […]

Anthi Gilligan Co-founder & CISO, Cork, Ireland

“INSECURE DESIGN” hits the charts at number 4!

“Shift-left” is a term we’ve all heard used ad infinitum over the […]

Ciaran O'Keeffe Co-founder & CEO, Cork, Ireland

The Curious Incident of the Dogfood Pen Test


You’ve probably heard the expression “dogfooding” or to “eat your own dog food”. It’s certainly a memorable phrase… although if you think about it literally, it doesn’t really make a whole load of sense. Just because your company makes dog food, that doesn’t mean you, a human (presumably), should eat it. After all, dog food is made specifically for canine consumption.

Perhaps the expression should be amended to “your dog eats your own dog food”… but that’s just not as catchy. And there’s another issue with the amended version: it depends on the dog. Your dog eating your dog food is not necessarily an indicator of said dog food’s quality. Your dog might just be one of those dogs that eats… well… anything. Don’t worry if they are though, I’m sure they’re still a very good boy or girl. 

Hmmm. As usual with one of my blogs, I appear to have gotten distracted. And as usual, dogs are to blame. Now, where was I? Ah yes… “dogfooding”. 

Despite what I just wrote, I do agree that the idea behind “dogfooding” is sound. Your product or service should be good enough that you’d be happy to use it yourself. Otherwise, how can you truly believe in it? And if you don’t believe in it, how can you expect your customers to?  Eating your own dog food is a good test of where your product really is, and early on here at Akeero, we decided to get out the can opener and chow down… 

Now I’m sure you know this already, but Akeero is a SaaS platform that allows users to securely design cloud-native applications and infrastructure. We currently support AWS – though support for Azure and GCP are both on our product roadmap so watch this space! – and Akeero itself is built on AWS. So, in order to eat our own dog food, we decided to design Akeero… using Akeero.  

“Wait… what?!? How does that work?” I hear you ask, scepticism clear in your voice. And I understand, because on the surface it sounds like some Inception-level shenanigans. Let me explain…

A lot of the power behind Akeero lies in our threat analysis engine, which looks at AWS architectures and quickly identifies all of the potential threats, then suggests best practice mitigations to be implemented during development. It’s like taking the knowledge of the most reliable, consistent and experienced Security Architect and cascading it throughout your organisation.

Although the product has come a long way since we ate our own dog food, the fundamentals of our threat analysis engine were in place even then. We didn’t have the awesome drawing canvas, or the ability to import existing architectures in a few clicks, or… well, pretty much any of the great features and integrations that we have now, but we had our engine

So we designed Akeero, and we ran our design through the engine. The engine told us what to do in order to secure Akeero as we built it, and we did everything it told us to. 

I’m the CISO at Akeero, but before that I have held lots of different roles within the world of InfoSec. I have a lot of experience in penetration testing – both as a tester and as a client. Full disclosure: I LOVE pen testing. I call it the “sexy” side of security (without any hint of irony). I’ve seen hundreds of pen tests in my time, some good, some bad, some horrifying. The one kind of pen test I have never, ever seen is a clean pen test. 

After we built Akeero, we had an independent information security consultancy come in and perform penetration testing on the platform. They spent their contracted week probing and prodding, looking for gaps and vulnerabilities to exploit. Then they asked for a second week. They wouldn’t charge us anything extra, they said, they just wanted more time.

The second week came and went. We asked them for their report. They were hesitant. Eventually they handed it over, almost apologetic.  Their report showed just three findings. They felt bad, like they had failed us. They felt even worse when we explained that two of their findings had already been fixed in our development environment, and they’d run their pen test on production. The third finding was informational only, meaning it had the lowest risk severity.

It wasn’t entirely pristine, but it was by far the cleanest pen test I’ve ever seen. It was also validation for what we had been working so hard to achieve. We’d tried our own dogfood, and you know what? It tasted great!

Akeero’s goal is to help every team shift security left within their SDLC. Identifying threats during the design phase and building securely is the ONLY way that security can scale alongside the rest of your growing business.

If you’ve any feedback on this blog, or want to learn more about Akeero, please reach out to me – I’d love to hear from you.

“INSECURE DESIGN” hits the charts at number 4!


“Shift-left” is a term we’ve all heard used ad infinitum over the past few years. However, this approach has – to date – rarely shifted far enough left to encompass secure design, which is something that has both baffled and frustrated me in equal measure. So I was heartened to see that the risk of Insecure Design has been included for the first time in the 2021 OWASP Top 10 – the organisation’s first update to their list in four years.

OWASP’s Top 10 has long been recognised as an invaluable resource for security and dev/engineering teams when it comes to securing products and services. It’s a vital indicator of trends and patterns in Application Security, and many organisations use it as a starting point for embedding robust, up-to-date security practices.

In fact, not only has Insecure Design been included this year, but it has debuted at number 4 on the list, which goes to show just how vital an activity it is when it comes to securing your organisational resources.

As a security architect, I have long advocated for secure design principles and threat modelling to be a standard part of every secure SDLC. You cannot truly say you have shifted left unless you have started considering your product’s security before you’ve actually started building the product.

The 2021 OWASP report says that “if we genuinely want to “move left” as an industry, we need more threat modeling, secure design patterns and principles, and reference architectures.” Music to my ears!

One of the biggest challenges with this approach lies with the eternal mismatch in numbers between security and engineering, which can lead to a lack of availability (and perceived lack of engagement) from the security team. Now, in my experience, they’re not actually disengaged – they just have too many engineers to support, and not enough time in their day!

Another challenge is the sheer manual effort required to do threat modelling and secure design – especially to do it consistently and at scale. Traditionally, this required gathering a bunch of busy people in a room together, over a number of different sessions, and spending time mapping out and diagramming As-Is and To-Be architectures on a whiteboard. Which – and I say this as a security architect – is rarely anyone’s favourite way to spend an afternoon. Let’s just say there’s nearly always something else that people find they could be doing instead.

I think it’s fair to say that many organisations don’t even bother trying, and the ones that try struggle to complete these tasks, tasks that should be considered essential – ARE essential – but get relegated to non-essential simply because… well, because they’re painful.

As a result, secure design and threat modelling are overlooked in favour of detective controls, which are like a ticking time-bomb. Such tools have their place, of course they do, but if they’re finding lots of things that need fixing, that can’t be good. All of those things are in production by now, after all. What if the next time one gets found, it gets found by an external bad actor, rather than by your own detective tool?

The inclusion of Insecure Design as a risk in the latest OWASP Top 10 is a clear signal to our industry that the importance of secure design practices is finally being recognised, and I see this as a really positive development. Of course, it’s not one that surprises me, as the benefits of secure design practices and threat modelling are immense. When done effectively, they can save an organisation vast amounts of time and money, and they don’t even have to be difficult to implement into your SDLC!

OWASP believe it’s worth doing – they’ve said as much – and deep down, you know it’s worth doing too. Don’t worry about the traditional pain – at Akeero, we believe our automated threat modelling tool can make most of that pain go away.

We’re here to help you take those initial steps in your Secure Design journey, or help you get back on track if you’ve started the journey previously, but somehow lost your way.

I’d love to spend some time explaining what we do at Akeero and how it can help your team, so please reach out to me if that’s something you might be interested in. Or reach out even just to share your thoughts on this blog, whether you agree or disagree! I love nothing more than a healthy debate!

Ready to jump onboard?

Akeero helps you design quickly and securely.