Follow us


What does it mean to be an outlier?

I started writing this post last week, from my hotel room in […]

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 […]

Anthi Gilligan Co-founder & CISO, Cork, Ireland

Akeero raises $1.2m to Identify Security Threats before Code is Written

Cork, Ireland, 16 July 2021 – Akeero, a cloud security platform, today […]

Stuart Cameron Co-founder & COO, Dublin, Ireland

Putting the Fun into SDLC Fundamentals

Ok, confession time. The blog title is misleading. Software Development Lifecycles aren’t […]

Anthi Gilligan Co-founder & CISO, Cork, Ireland

What does it mean to be an outlier?


I started writing this post last week, from my hotel room in London. Myself, Anthi and Stuart were in town for a very exciting reason, which is that… drum-roll please… Akeero has been invited to join the first ever cohort of Arc Europe, Sequoia’s seed-stage catalyst! 

Sequoia is a very well-known venture capital firm. I know this for a fact, because most of my friends and family know next to nothing about the VC world – no more than I did before Akeero – and yet lots of them have been contacting me since the news was announced to tell me that “even I’ve heard of Sequoia!”. So to have been chosen as one of only 17 companies overall to be asked to participate in Arc is genuinely thrilling, and I know the rest of the Akeero team feel the same. 

It’s also further validation that what we are doing at Akeero makes sense. We’re very lucky to have some amazing investors who have supported us since the beginning of our journey,  but whilst I’ve never doubted our vision, it’s not always easy to convince others that your vision is one that they should share. I believe that what we are doing will revolutionise secure design for companies, but I will also admit that in order to do so, some companies will need to come around to a new way of thinking about how they build security into their software development processes.

With Arc, Sequoia made it clear from the outset that they were looking for outliers. This got me thinking, what does this mean exactly? And what makes Akeero an outlier?

Outliers see things differently. They do things differently. They look at the way things have always been done and they say: we can do that better. We can do it faster. We can do it smarter. Not only that, outliers are truly transformative.

I believe that in order for security teams in every organisation to be able to scale – in order for them to be able to adapt to all of the challenges presented by modern engineering and the cloud – secure design needs to be embraced and embedded at the very start of the SDLC. I also believe that in order for this approach to truly add value, it needs to be automated as much as possible. Transforming organisational approaches to secure design is our mission at Akeero, and it’s what makes us an outlier.

Having said that, I don’t think that our viewpoint on security-by-design will be an outlier viewpoint forever. Soon the Akeero approach will be the approach that every smart company takes – there is simply no other way for security teams to scale and meet the demands of modern engineering teams.

I’d hoped to get this blog out last week (as I said at the start, I began writing it in London) but that plan soon fell by the wayside. Week one was fascinating and rewarding, but also quite busy, meaning all thoughts of blog posts had to be shelved for a few days. At time of writing I’m back in Ireland, and week two of the eight-week programme starts later today. If the first week is anything to go by, our leadership team will learn so much as part of Arc. If anyone has any questions about Akeero, or about my experience with Arc to-date, just reach out to me. We’re (wonderfully) busy right now, but I can always find some time to chat!

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.

Akeero raises $1.2m to Identify Security Threats before Code is Written

Akeero Team

Cork, Ireland, 16 July 2021 – Akeero, a cloud security platform, today announced that it has raised $1.2m in a pre-seed funding round led by Frontline Ventures. Truesight Ventures, Tiny VC, Capitoria and Oyster Capital Investments also participated in the round.

Founded in 2020, Akeero allows companies ship products quicker and more securely by taking a developer-led approach to security. An intuitive UI enables users to quickly model their infrastructure and provides immediate fixes which can be easily implemented. This ensures security is considered from the very start of the development process and saves valuable time and effort. Akeero aims to be as embedded in the software development lifecycle as GitHub.

To combat the increased level of threats experienced from the accelerating complexity of adopting a “cloud-first” strategy, Akeero is codifying the security architect’s knowledge and building a platform to allow the entire product team to become a stakeholder in the security lifecycle. Using an extensive library of threats and controls, the platform automates the identification and mitigation process in real-time to offload the time-consuming manual efforts experienced by a specialist security practitioner.

“In many organisations secure design practices are completed far too late in the development process, which leads to the costly retrospective addition of security controls. Our research shows that 86% of product development teams do not consider security in the design phase of their project. The need to embed secure design practices more efficiently and consistently will be a top priority for companies looking to innovate post-pandemic.” said Ciaran O’Keeffe, co-founder and CEO of Akeero.

“Cloud architectures rarely remain static and their flexibility is a huge advantage in so many ways. However, many organisations struggle to identify the security implications of continuous changes. We wanted to break this linear ‘only-done-once and quickly outdated’ approach to security design, and instead enable teams to have the most up-to-date and relevant security requirements for their environments,” continued O’Keeffe.

Speaking on the announcement Finn Murphy, Partner at Frontline Ventures said: “As cloud infrastructure becomes more complex, the world of threats that companies are exposed to is growing exponentially. There simply aren’t enough security architects in the world today to meet demand. Akeero will give every engineering team the ability to understand the threats they’re exposing themselves to and mitigate those threats through smart infrastructure design and monitoring.”

Akeero will use the additional capital to accelerate product development and market penetration and fund recruitment in engineering and operations, to ensure teams can deliver secure apps and networks better, faster.

About Akeero

Founded in 2020 by ex-Logitech and Forcepoint security architect Ciarán O’Keeffe, ex-Bank of Ireland, Logitech and Forcepoint security engineer Anthi Gilligan and ex-KPMG and Spanish Point Technologies finance and operations executive Stuart Cameron.

About Frontline Ventures

Frontline Ventures is the firm for globally ambitious B2B businesses on both sides of the Atlantic. Frontline Seed strengthens and speeds up ideas at inception across Europe. Frontline X is a growth-stage fund, for fast and frictionless US-Europe expansion.

Frontline Ventures has backed 70+ B2B entrepreneurs across Europe and the US and has had numerous successful exits. Today, Frontline Ventures has €250 million funds under management, with offices in London, Dublin and San Francisco.


Putting the Fun into SDLC Fundamentals


Ok, confession time. The blog title is misleading. Software Development Lifecycles aren’t exactly “fun”, and nothing I can write will change that! It is an interesting topic though: consider that you could ask 20 different DevSecOps engineers “how do you secure your SDLC?”, and the answers you get may outline 20 different ways of doing things… and what’s even more interesting is that all 20 may be correct and valid approaches. 

As with skinning cats, it’s the case that there’s more than one way to operate a secure SDLC, but in my experience, there are some fundamental building blocks that you need:

  • Cultural Awareness – the success of your SDLC may hinge on whether or not your organisation as a whole has bought into the importance of security
  • Secure Design – assuming you have that level of cultural buy-in, you need to embed security in your design from the outset.
  • Secure Coding – it stands to reason that your secure design needs to be securely coded for it to work as intended.
  • Robust Testing – less bugs at this stage usually means you’ve done a good job with the previous three – provided your security testing regime is comprehensive.
  • Effective Monitoring – things change so you always need to keep an eye out for anything that goes wrong, but again, if you’ve nailed the previous stuff, you shouldn’t see many problems here, and monitoring should give you peace of mind instead of cause for concern.

Obviously, these building blocks can and will contain many different facets depending on the nature of your organisation. For example, if I was to examine Testing in detail… well, that’s a whole series of blogs in itself, and I don’t want to get too bogged down with the relative merits of SCA, SAST and DAST, etc. I think it’s fair to say though that if you stick to the fundamental building blocks listed above, and do them all well, you’ll significantly reduce the likelihood of suffering a security incident.

Of course in the real world, I’ve found it can take years to get to the stage where you’re comfortable that all of these fundamentals are being covered adequately. Your available resources are finite – headcount, time, money – and this will invariably restrict the amount of work you can do, so you can end up playing security Whack-A-Mole unless you know what to focus on. In order to establish this, there are 3 key questions you need to ask:

1 – Where is our biggest risk? 

Knowing your organisation is vital to understanding which part of your Software Development Lifecycle is riskiest. Start at the beginning and evaluate how your team approaches each of the 5 building blocks in turn. Once you have identified where your weaknesses are, you can start to address them. For example, maybe you look at your development team and see a bunch of people who understand the importance of secure design and secure code. However, maybe they also use a large amount of open source libraries for their code, because… well, doesn’t everyone? Given the interdependencies that exist between libraries, this will inevitably lead to huge security vulnerabilities. You can’t change this fact, but acknowledging it is key, as you can then focus on managing these risks by using a Software Composition Analysis (SCA) tool. 

2 – Can we automate?

You can have your team do everything manually. It’ll take a lot of time though. And bear in mind you’ll need to account for the manual errors that they make. And unless your manual workers are clones (which would be weird), each of them will probably do things slightly differently. That’s why it makes sense to automate where you can – you’ll get faster, error-free and more consistent results. Look at your SDLC and examine what aspects of it can be automated. It’ll pay off in the long run.

3 – Can we shift left?

If your monitoring and testing is routinely showing up issues, you can spend lots of time and money fixing these issues. But this is a response to detective work, and leads to firefighting in perpetuity. There’s always a root cause and that root cause won’t be fixed unless you shift your focus left. The earlier you can embed security into your SDLC, the less remediation you’ll have to do. Whenever you’re looking at a problem, ask yourself if you could shift the problem left… get to it earlier and before long you’ll eradicate the root cause.

Akeero can’t make your organisation adopt a strong security culture, but the fact that you’re still reading this blog suggests that at least one person in your organisation does (ie you!). What Akeero can do, through our intuitive user interface and native integrations, is allow your organisation to shift way left and embrace automated Secure Design. You can identify security and compliance requirements for complex cloud architectures in minutes, with minimum impact to existing security and development toolsets and processes. 

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

Ready to jump onboard?

Akeero helps you design quickly and securely.