Introduction
Hello, and welcome to this SPK and Associates vlog. My name is Michael Roberts. I’m the Vice President of Sales and Marketing here at SPK and Associates.
Today’s vlog is about how organizations are trying to accelerate software delivery, and security teams are really trying to keep up. They’re under a lot of pressure to keep up.
But too often in DevSecOps, that still relies on a flood of alerts that create a lot of additional noise. Are they really action-oriented alerts? That leaves engineering teams feeling overwhelmed, and risks are usually unresolved.
So in today’s vlog, I’m joined by Hannah Foxwell, co-founder of BIMP.AI. Hannah, please introduce yourself.
Hannah Foxwell’s Background
Thank you for having me, Michael. It’s great to be here.
My name is Hannah. In previous roles, I’ve been Platform Engineering Director at VMware Tanzu. I’ve been a Product Director for a cybersecurity product called Snyk Container. Right now, I’m working at the intersection of AI-native software delivery, cybersecurity, and platform engineering.
Why AI Matters in Software Delivery
Hannah, you have to be here because everybody’s talking AI. So, we have to make sure that we get included, right?
Let’s make sure that all your listeners get FOMO because that’s the overwhelming emotion right now. It feels like everyone’s doing AI apart from you.
Right, but it has to be contextual. I think that’s really where this conversation will get a little bit different because AI in creation of software and really where it’s intended to be is making software developers’ lives easier.
I want to get into this, but there are a couple things that we’re going to talk about.
We’re going to talk about how organizations are trying to move from that more reactive security alerting model to more automated and integrated actions in their environments. You have some ideas around that, and I want to talk about that concept of golden images and embedded security as well.
Moving From Security Alerts to Automated Action
So Hannah, first, many security tools are really overwhelming these teams with alerts, but they don’t actually solve the problem.
You created BIMP. So what inspired your approach with BIMP to connect security risks directly to automated action, and how did that change the way engineering teams are going to operate?
Well, I’ll tell my own little story of how I became interested in security and the needs of security users as well.
Specifically, the outcome is improved security, but to get there, security teams quite often have this enormous challenge in front of them.
With a lot of organizations, and I was exactly the same, security felt like it was this source of friction. They were the people who always said no. They slowed us down.
It was only when I started working at Snyk, where the security users were the folks I was interviewing and trying to figure out ways to help, that I really got to understand and have more of a deep empathy for the security team.
Quite often, a security team is massively outnumbered by everyone else in the organization. You have hundreds, sometimes thousands more developers in your organization than you have dedicated security folks.
They suffer from challenges in visibility and challenges in actionability.
To be quite honest, we haven’t done security teams any favors by building the security tool stack separate from our platforms because what you end up with is this disconnected reality.
I call it the bad news dashboard. The bad news dashboard is full of vulnerabilities, and the security team is ultimately accountable for all of this risk without being the owners of the fix or the actionability.
One thing that I’ve come to really, truly believe is that most security fixes are easy if you know who to talk to and what to do.
In large organizations, that’s a human problem. We don’t solve that human problem by creating a spreadsheet and mapping repos to people and accountability.
We solve that human problem by automating away the communication silo.
We go, “Okay, here’s a vulnerability, and here’s a known fix,” and we automate that process so that, as a developer, security just happens. For the security team, they have that assurance that the fix just happens.
There are all sorts of domains in which you can apply that logic, but the one we apply it to is the software supply chain around container base images.
A container base image can contain tens or hundreds of packages, and any one of those packages can become vulnerable at any moment in time.
But by knowing that your base image is from a trusted provider, that it’s continuously rebuilt from source, and that it’s being cascaded to all of your development teams automatically, that gives you a level of assurance on a huge proportion of your software supply chain.
So that’s where we started with BIMP.
BIMP stands for Base Image Management Platform. One, I like saying the word, but also, two, it does what it says on the tin.
Instead of going and reviewing all of the vulnerabilities in your base images, let’s just automate that software supply chain. Let’s do continuous remediation.
Developers aren’t hassled about things that they have no control over, and security teams have assurance that every base image is conforming to their organization’s policy, and every CVE that pops up in a base image will be fixed.
The Role of Base Images and Golden Images
I love the concept, especially the name. I do love the name.
But I love the concept of keeping that image protected for both the purpose of taking things off the plate of the developer and taking things off the plate of security too, right? It connects all things and all worlds.
We often hear at SPK about using the term golden images, the good things that come in.
This is a little bit different when you’re talking about BIMP in comparison to a golden template for certain things. It’s still kind of the same, but it’s very different there.
That concept of an image having all those things built in ensures that security is tied into the workflow too. That’s usually how we’re always trying to add it.
But yours is different, and I love this.
So why is that becoming a really critical focus for large enterprises, as you mentioned, and how does BIMP help organizations operationalize that at scale as things grow?
Why Base Image Security Matters at Scale
A few years ago, what was the norm was that developers would build a new application. They wanted to containerize it. They built out their Dockerfile, and they grabbed a base image that worked for them, probably pulled it down from Docker Hub.
The teams that were doing well would then keep that base image refreshed. The teams that were doing not so well would not touch that base image ever again.
Over time, the security of that image would degrade. New CVEs are found, and they’re not remediated.
What I’m seeing now is a recognition of that large software surface area that base images contain and the large blast radius that an insecure base image can have.
Because if you’re building all of your applications off an insecure base image, that’s not just one app that’s vulnerable. That’s all of your applications that are vulnerable.
What I see large organizations and regulated industries especially doing is moving to more slimmed-down, sometimes zero-CVE base images.
In order to do that, they’re essentially delegating that responsibility to a third party. They’re going to ChainGuard, or they’re going to Minimus. Docker has zero-CVE base images. Red Hat does.
But in order to get to that point, there’s a migration that needs to take place.
We need to go and find all of those repos that haven’t been maintained very well, and we need to go and correct them.
We need to go, “Okay, that was the old way we did things. We recognize that that’s not sustainable or secure. This is the new way. We’ve got our chosen base image catalog. We want to cascade that out to everyone.”
Because a zero-CVE base image today isn’t zero-CVE tomorrow. More vulnerabilities are always being found, and actually, that’s another pressure point on security teams right now.
LLMs are really good at finding vulnerabilities, and so the amount of CVEs that are being discovered is massively accelerating right now. At this moment in time, we can’t keep up with the amount of new CVEs that we’re discovering.
So you have to have that automated remediation.
It’s not just a migration. It’s not just, “Okay, bad base image to good base image.” It’s the continual update and maintenance of that supply chain as well that you need to think about.
Automation has to be the answer.
If you’re operating at any kind of scale where you’ve got maybe a thousand or more repos, that’s not a manual job for you. It has to be automated to give you that assurance that it’s happening continuously.
Preparing for a World Where Every Day Feels Like a Zero Day
Yeah. It’s getting an infinite checklist created, essentially, for security teams.
Exactly.
I was at KubeCon a couple of weeks ago, and we did a panel on practical preparation for the next zero day.
One of the questions I asked my panelists was, “What if every day was a zero day?”
Actually, what they said was, “It’s not far from the truth right now.”
It’s not far from the truth. You do have to design your processes and practices as though every day was another supply chain attack because that’s becoming the new normal.
If you use that as a thought experiment and say, “What do we need to put in place? What automation do we need so that this becomes business-as-usual remediation and not an incident and not a crisis to manage?” then you do things very differently.
Reinventing the Software Development Process
Yeah. I would hope the listeners are catching this because this is completely reinventing the way that we build software.
It’s not the legacy way anymore because, with AI, security can’t just be tagged on. It needs to be baked in.
I feel like we’ve said this for 30 years now, right?
I know. I know.
It can’t be the last thing, right?
I’ll keep saying it till the day I die probably.
But I do think that AI creates pressure, and it creates some problems that are new to us.
The time to exploit a CVE is basically zero now because LLMs and agentic coding tools are really good at that.
Basically, you can assume that pretty much every repo is vulnerable because an LLM will go and figure out, in a way that a human could never do, what those exotic vulnerabilities are. A human doesn’t have time to do that and doesn’t care.
You have to imagine these tools are available to us as security folks to give us more intelligence about the posture of our application. They’re also available to bad actors and hackers, and that’s what we’re defending against.
So we’re at this really difficult moment in time where this pressure is happening.
Even though a lot of organizations have gone for a long time saying, “We should really do that. We should really sort that out. That’s a bit of a risk over there,” it’s no longer a theoretical risk.
It’s a very, very real problem that they’re going to be managing if they don’t.
Yeah. As I say, for $20 and an internet connection, you can wreak some havoc.
And it’s happening.
It’s happening. Yeah.
How AI Is Influencing BIMP’s Development
Okay. So we’ve talked about this whole reinvention of that software development process in a more AI-driven world because obviously, there are bad guys that are doing the same thing.
How has that influenced what you’re building at BIMP and how you’re building it?
One of the reasons that this year I felt like I wanted to pivot my career was because previously, I’ve been doing advisory for startups, and that was great fun because I got this really broad perspective on what was going on in the AI and security space.
This year, I wanted to build something because it was starting to become really apparent that building is so easy now.
Building is so easy now.
I understood that, and I was like, “Well, I want to build something that’s in my domain. I want to build something that helps the world become more secure and use my knowledge of platform engineering to help with that.”
That’s how BIMP was born.
It’s a problem that I know and understand very deeply. I couldn’t see that anyone else had solved the problem in the way that I would solve the problem.
Then the experiment became, “How lean can we be with the AI tools that we have at our disposal?”
We are currently a two-person company. We have a product. The product works. We are now thinking about how we use AI to scale go-to-market, adoption, and things like customer success.
When you have AI agents at your disposal, how much impact can a small company have?
That’s something that really excites me because I don’t want to sit on the sidelines and talk about what an AI-native company might look like and theorize about it.
I want to be at the heart of it. I want to be experimenting with what works and what doesn’t.
So that’s what happened this year. I was like, “Right now is the moment. We’re going to try and do this.”
That’s been a huge source of learning because I do believe that a lot of the practices and processes that we would have considered best practices and widely adopted things, like scrum and agile, backlog management, and ticketing systems, are very, very rapidly becoming completely redundant.
It would take me longer to write a story than it would be to build the feature.
That is a very, very new feeling for a lot of people. It’s incredibly fun.
But what we did is we literally threw out the rule book and said, “Well, what works for us? What allows us to keep building and keep that flow of building going?”
Not just building the tool itself, building the product itself, but building the tools we need to build the company.
How can we do that in a really AI-native way?
That’s the experiment we’re running at the moment, and it’s teaching me a lot about what the future might look like.
I am excited about the opportunity for more high-impact small companies to come to market.
I think that’s got to be the way we do things in the future.
The two-pizza team is just too big for a lot of problem spaces and a lot of products.
High-Impact Small Teams
I love the “two people can change the world” kind of mentality.
Oh, yeah. From our tiny little village in Yorkshire, there are sheep and lambs outside my house.
Can we really do a kitchen-table startup? I think we can.
I think even in that scenario, there are more resources available now than ever before for that type of situation, right?
You don’t need, as you said, ticketing systems and all those things necessarily nowadays to be able to impact a marketplace.
Phenomenal story, and thank you, Hannah, for spending time and sharing a little bit about your story, your background, and how we’re trying to reinvent that software lifecycle.
Thank you for your time.
Thank you for having me. It’s been fun.
Closing Thoughts
I don’t know that we have clarity on everything in AI and DevOps, but I think for sure we’ve talked about better ways to do things, which is not adding more alerts to the security group and creating security as an embedded part of that software delivery system.
For organizations looking to modernize their DevSecOps strategy, whether it’s integrating security into your pipelines, leveraging AI, or building scalable, repeatable workflows, our team at SPK actually does those things.
So, if you enjoyed this conversation, be sure to like the video, subscribe to the SPK and Associates YouTube channel, and follow us for more content on DevOps, AI, and engineering best practices.
Thanks for watching, and we’ll see you next time.
Thank you.
