🎙️ New podcast: We're launching a Q&A-style talks with product management experts
Learn more
For cybersecurity vendors, pulling data from multiple sources and pushing it to another is a critical aspect of their offerings. Developing these integrations, however, is very resource-intensive, both in the development and maintenance phases. With that in mind, what options do cybersecurity vendors have for connecting their products to others quickly, securely, and with reasonable resource allocation?
In this interview, we leverage Tyler's in-depth research on integration and automation platforms suited for cybersecurity vendors. Our aim is to provide a comprehensive overview of the available solutions, how they are categorized, and how cybersecurity companies can benefit from them.
First off, I’d say my journey to becoming a product leader is still ongoing. I’ll let you know when I get there! But to start from the beginning, I began my career around 20 years ago in IT, tinkering with computers, and quickly found my way into the cybersecurity space.
I met someone in Vancouver who worked with a police gang task force, and they introduced me to the concept of forensics. That’s where my background in digital forensics began. I then had the opportunity to work at a company called Mandiant, focusing on incident response—essentially investigating companies that had been breached.
For years, I traveled around, grabbing my bag at five o'clock to fly out and help companies recover from breaches. It was a great experience, but it also made me realize there’s a real need in the product world to simplify that process.
My first step into the product space didn’t happen until I joined a company called Tanium, where I worked on their EDR (endpoint detection and response) and threat response products—essentially, endpoint software. Since then, my career has become much more product-focused, though still deeply rooted in cybersecurity.
About a year ago, I decided to leverage both my product and cybersecurity knowledge to solve more direct problems I’d seen friends and users face in the threat-hunting space. That’s what led me to start my business, Huntbase.
I wouldn’t say there’s a traditional route into product management or any role in the product space. My path probably wasn’t traditional, but I appreciate it for both its strengths and its challenges.
You mentioned a few acronyms, and I'll add another one: BPA, which stands for Business Process Automation software. This is something that the big four consultancies have been leveraging quite heavily.
When you say you need integrations in your product, you could go in many different directions—from open-source frameworks like Apache Camel, which have nothing to do with iPaaS, to a low-code, security-focused SOAR tool like Tines. There are countless options in between, especially for a security product vendor.
I’ve spent a lot of time in this area, and maybe it’s worth explaining why. The products I’ve been working on over the last several years rely heavily on integrations, especially in security. Security, from my perspective, is almost like a data science problem. You need to gather data from various tools and be able to interact with them.
Security, from my perspective, is almost like a data science problem. You need to gather data from various tools and be able to interact with them.
For example, if there's a security incident on a Windows device, I need an integration to pull that data or take action on the device. Similarly, if there’s an incident in your security incident management system (like a SIM), I need an integration to retrieve that information and potentially make changes based on it.
This need for integrations has existed whether I was building an XDR product or working on what I’m building today.
In the early days of my research, I explored various vendors. Initially, I looked into a product called Node-RED, a node-based solution developed by IBM. While not embeddable, it uses flow-based programming, which users find quite intuitive. I’ve used it for years, both for home automation and in enterprise contexts.
As I dug deeper, I started noticing how similar certain products were—like SOAR tools that are security-focused but functionally similar to other types of automation software. When I was at EclecticIQ, I needed a solution to quickly integrate with our product because developing and maintaining integrations is cumbersome, as you know.
That’s when I really started to see the vast array of products with different names and categories, all claiming to solve similar problems. For me, the solution was an embedded iPaaS because I needed to embed an automation builder and similar features. For others, it might be something entirely different.
Appmixer sits in that embedded iPaaS and general iPaaS space, and you could probably explain the distinctions better. But I also looked into integrations for data ingestion, which is slightly different. For example, when you need to pull data from multiple tools and send calls back out.
That’s how I came across products like WorkOS and Merge.dev. Over the years, I’ve also come across others like Leen, which is more security-focused. They’re creating standardized APIs that could be the future of integrations, not at the iPaaS level, but in terms of digesting industry-specific, normalized APIs to help with integrations and maintenance.
But again, these solutions may fall under the umbrella of "integration tools," even though they weren't what I was looking for. A lot of the process involved sorting through the noise. It actually took me a while to find the iPaaS acronym because it wasn’t in my original knowledge base, but I got there in the end. And over the years, I’ve kept a close eye on the space.
I’ve done a few product bake-offs, but before even getting to that point, it's important to understand what the user needs. Especially with an early-stage product, you have to identify what will have the most impact early on. From there, you can decide which products to explore or whether you should build the solution yourself. That "build vs. buy" conversation is critical.
I’ve seen the challenges that come with building and maintaining integrations, which we can touch on later. Essentially, we sat down and evaluated what we needed: first and foremost, the ability to integrate security products out of the box, ideally with some pre-built integrations. If not, we needed to easily build those integrations on the platform.
Our users, particularly in the security domain, are highly technical. So, we also needed to ensure that if we’re offering automation, we’re allowing users to manipulate and manage that automation themselves. We looked at how we could expose that functionality in the long term, as well as a few other security-focused features.
One thing that stood out during our evaluation was the concept of embeddability. Many integration systems or iPaaS solutions offer a basic level of embeddability—essentially an iframe where users are pivoted to another application to manage integrations. But our needs, and the needs I still have at Huntbase, go beyond that. We wanted the ability to truly embed the integration platform and access the integration context so we could leverage those integrations outside of the platform itself.
Only a select few solutions offer SDK-level or software-level integration. That quickly became one of our key requirements. Additionally, there’s always a concern in the security industry about using iframes. While I don’t always see it as a problem, there’s caution around potential vulnerabilities, like cross-site scripting, which raises further scrutiny. We wanted to avoid those risks.
There’s always a concern in the security industry about using iframes. While I don’t always see it as a problem, there’s caution around potential vulnerabilities, like cross-site scripting, which raises further scrutiny. We wanted to avoid those risks.
That’s where solutions like Appmixer came into the picture. With Appmixer, our engineering team could deeply embed the platform within the product, which isn't a bad thing—especially when you're building a highly integrated, rapid-deployment solution.
Before we even got to the bake-off process, we had to down-select from hundreds of different solutions—and we had to do it quickly, within a couple of days or a week. That allowed us to narrow down to a few vendors and really assess what they could offer.
A lot of these decisions ultimately went to the engineering team. While I’d like to think I’m fairly technical, much of this falls under the realm of design and engineering. Having an SDK offers more flexibility in terms of customization and design, which is important.
When it came to using iframes, we had concerns because we eventually wanted to expose features like the workflow builder to our users. The idea of having a large portion of our product rely on an iframe, essentially a window into another solution, raised questions. We wondered if there was a way to embed it directly within the application itself. That’s when, by chance, I discovered that Appmixer had an SDK, which helped steer the conversation with engineering in a different direction.
Having an SDK offers more flexibility in terms of customization and design, which is important.
I think this mindset may be more unique to security and how we approach potential vulnerabilities, but we were keen to avoid the iframe approach. I know there are security products out there that don’t see iframes as an issue, and in fact, some are starting to move away from it. But transitioning to an SDK approach, if you didn’t start with it, is a long journey.
On that note, though, I want to clarify something about iframes. It’s not that they’re inherently bad. In the security industry, where users are familiar with vulnerabilities, iframes are sometimes viewed as a potential risk. But the reality is, it’s just another risk to manage. If implemented well, the risk can be reduced to almost zero. So, it’s not that all iframes are bad; it’s just that they carry a bit of a stigma.
Over the years, I’ve approached these evaluations from a few different perspectives. For example, being at a larger company with a budget and the ability to build integrations in-house is quite different from being at a greenfield project within a business where there's at least some budget to bring in and evaluate solutions.
Then there's my current situation, where it's not just a time problem, but also a money problem. I need to figure out how to integrate with a select group of products quickly to bring my product to market.
Each of these scenarios presents its own challenges when deciding whether to build or buy integrations.
So, let me start with the scenario where you're at a smaller product company evaluating solutions. I think we took the right approach by focusing on what we could easily customize and what would allow us to add new integrations quickly. We wanted something that could be integrated into the product within a couple of sprints to get those initial integrations out the door, but also something with enough flexibility to give us a longer runway—say six months or more—so we could continue adding capabilities and new integrations over time.
Budget is always a concern, but it was less of a focus in that scenario than it is now, where there’s no budget at all. At the startup stage, it’s all about building quickly to get something into the hands of those first customers. But because I’m building a product that needs to integrate deeply with other solutions, I also need an integration platform I can trust and build on.
My evaluation process now is very different; I’ve been looking more at open-source solutions or building things myself for a small number of integrations. That’s purely a function of being in a bootstrapped, small business environment. Longer term, I definitely wouldn’t build the integrations myself.
From a startup perspective, it’s interesting how investors react when you mention integrations. They often ask, "Are you building those integrations yourself?" It makes some investors nervous when they hear that because building and maintaining integrations is no small task. It’s not just a matter of building one or two and being done. It’s a snowball effect, especially with larger enterprise customers, where you might have one customer who requires a specific version of an integration or application. The deployment and maintenance challenges can become significant.
What I find fascinating is how attuned investors are to this. When I first started talking to investors, I didn’t even consider that they would be so aware of the complexity of building and maintaining integrations. But they do raise it as a concern, and it's a risk some may not want to take on. It was an eye-opener to realize that people outside the product and engineering space are so cognizant of this challenge.
Investors often ask, "Are you building those integrations yourself?" It makes some of them nervous when they hear that because building and maintaining integrations is no small task.
Time is definitely a big challenge, especially when building a startup. Just finding the time to stop and actually build is tough. Coming from a product management mindset, you want to gather as much feedback as possible and push it off to development, but wearing both hats—taking feedback from users, developing the product, and selling it all at the same time—has been the biggest challenge for me.
I liked what Gabriel mentioned in the last session about Slack. Thankfully, my Slack is fairly quiet, but I can completely relate to his point from the perspective of being a product manager in a larger enterprise.
I think there are two key metrics here, although one is less measurable. The first is customer enjoyment. While it can be measured through things like Net Promoter Score, any time I hear a customer say, "I really enjoy using the product," it’s incredibly rewarding.
It doesn’t always have to be a direct compliment—it could be something more subtle—but it fills up this energy bank for me. It feels like we’ve hit the nail on the head. Now, that doesn’t necessarily mean they enjoyed it so much that they bought it, but there’s that sense of, "Okay, we got it right."
This is especially important when building security products. I know how stressful security environments can be, so when users say, "This is something I actually enjoy using," it’s a huge win.
Another key metric for me is how many customers are regularly speaking on your behalf. We used to do user conferences, and seeing how many customers were willing to go out and talk about the product to others was a big indicator. It’s probably connected to the first metric, but when customers are willing to promote your product—without any stake other than the fact that they use it—it’s a strong sign you’re doing something right.
I've seen a wide range of approaches to this. Right now, my process is very hands-on. I’m reaching out directly to my user base, attending technical conferences, and gathering as much feedback as possible. Since we’re in the early stages, it's essential to get that direct input—though, at this point, it's more from potential users than current ones.
With our design partners, we have regular weekly or biweekly catch-ups to discuss what’s working and what isn’t. Since the group is small, it’s easier to manage this process.
In contrast, when I worked at a larger organization with a bigger user base, we had more robust ways to gather feedback, whether through quarterly business reviews or face-to-face customer conversations.
For example, Tanium had a very structured process for collecting customer feedback. Anytime there was a sales conversation, a customer success meeting, or an interaction with a technical account manager, it was recorded, logged, and sent to our CRM. As product managers, we could access that data and analyze it. There was even someone dedicated to ensuring that these notes were properly collected from every business meeting.
In some organizations, I've seen effective use of feature flagging software like LaunchDarkly or Pendo, which feed data into a data lake. This allows for a more passive method of gathering user feedback by analyzing how users interact with the application. It’s great for spotting patterns—like identifying which parts of the product are heavily used or where users might be struggling—without needing to ask users directly.
Of course, interacting with users is the best part of product management, but users are busy. Their daily job isn’t necessarily to provide feedback, so passive feedback methods are valuable for minimizing disruption. Tools that offer click-through walkthroughs or feature flagging also provide important insights that help guide the product development process without requiring constant user interaction.
Looking at what's ahead, at least in the short term, does building make things better or worse? It's important not to underestimate the amount of work involved in building and, more specifically, maintaining integrations.
It’s becoming easier every day to build integrations—many products now have open API specs and are well-documented, which makes creating an integration at a specific point in time easier. That’s great, but the problem is that it’s a moving target. Products evolve, and the integration landscape constantly shifts. The question then becomes: are you going to end up dedicating more resources and potentially even building entire teams just to maintain those integrations? And just as important—can you be trusted to handle them securely?
This is particularly relevant for startups, where speed is often prioritized, especially when it comes to building integrations. But are those integrations being handled securely? Do they have the expertise to do so? That’s one of the benefits of buying an iPaaS solution—it allows you to offload some of that responsibility, including security, assuming you trust the iPaaS vendor. There’s a level of trust involved, of course.
It's important not to underestimate the amount of work involved in building and, more specifically, maintaining integrations.
Ultimately, the build versus buy decision is one you’ll constantly question and revisit. My general approach, though, is that if you have the budget and you’re committed to a long-term integration strategy, buying into an ecosystem isn’t a bad choice. It can help alleviate the complexities and ongoing maintenance involved with integrations.
Huntbase is a threat hunting and security operations tool. It allows security operators to interact with various business tools, infrastructure, and security systems while guiding them through threat response. From that short description, it’s clear how critical integrations are for us.
We need to be able to connect with security products like Splunk, Tanium, and others, but also with business tools like Salesforce, Figma, and Google Docs to pull in context or make changes. This quickly becomes an integrations challenge. We can’t maintain millions of integrations, so we’ve implemented a tiered approach.
Our tier one integrations are heavily customized and developed by us. Tier two leverages third-party services or libraries that we work with. Then we have tier three, which is more lightweight—just a few basic API calls to get data without ongoing maintenance.
So far, this approach has worked well for us, and I’d recommend it to other businesses as a way to manage the complexity of integrations. A lot of our business is built on integrations, but we also have strengths in the security and threat-hunting space. By partnering with integration platforms or leveraging third-party services, we can address security operations center (SOC) challenges in a unique way.
We explored Tyler's research on integration platforms for cybersecurity products and learned about the complexities of building and maintaining integrations, including a comparison of SDKs and iframes. Hopefully, this helps you better navigate the landscape of solutions and accelerate your integration delivery.
If embedded iPaaS seems like a good fit for your integration and automation needs, check out Appmixer. It's a next-generation integration platform that helps cybersecurity and other software companies deliver native integrations in days and adopt powerful no-code automation, allowing end users to build complex automations directly within the product.
You’ve just read an interview from our podcast, where we speak with product leaders who share their experiences. Follow us on Spotify or YouTube for more episodes.
.png)
.jpg)
.png){kind=logo}
