Mobile apps now drive the majority of digital commerce and financial transactions, yet security teams continue to treat them as an afterthought. Once an app ships to a user’s device, it exists outside the traditional security perimeter. Attackers take advantage of this structure by reverse-engineering apps to expose API endpoints and embedded secrets, repackaging legitimate apps with malware to steal credentials, and using dynamic instrumentation tools to manipulate app behavior at runtime without triggering a single server-side alert. Meanwhile, developers ship mobile updates weekly or nightly, and security tooling that slows the pipeline down simply doesn’t get adopted.
In this episode, Ryan Lloyd, Chief Product Officer at Guardsquare, explains how the platform combines code obfuscation, runtime integrity checks, and real-time threat monitoring to secure mobile apps at the binary level, integrated directly into the CI/CD pipeline. Joining him are TC Niedzialkowski, Head of IT & Security at Opendoor, and Montez Fitzpatrick, CISO at Navvis.
Want to know:
- Why does organizational apathy around mobile app security persist even as mobile becomes the primary customer channel?
- What’s the difference between app integrity and code integrity, and why does it matter for defending against repackaging attacks?
- How does obfuscation function as a real security control rather than just security through obscurity?
- How does Guardsquare fit into the CI/CD pipeline, and what does the actual build overhead look like for development teams?
- What API and webhook capabilities exist for routing threat monitoring data into your existing security stack?
- How does Guardsquare’s mobile app attestation model bind server-side APIs to verified legitimate app instances — and why does that matter for stopping bots and credential theft?
Check out the episode for the answers you need.
Join the conversation on LinkedIn.
Huge thanks to our sponsor, Guardsquare
Full Transcript
[Music]
[Voiceover] Connecting security solutions with security leaders, Security You Should Know starts now.
[Music]
[Rich Stroffolino] Welcome to Security You Should Know. I’m your host, Rich Stroffolino. Today, we’re going to be talking with Guardsquare and what they’re doing in mobile app security. Now, the problem that they’re addressing is kind of foundational here. It’s that there’s kind of just organizational apathy around mobile app security. Trying to get some answers to why that is the case, we have TC Niedzialkowski, head of IT and security over at Opendoor, and Montez Fitzpatrick, the CISO at Navvis, helping us out here today. Thrilled to have them on the show. So, TC, I’m going to start with you. Why are we still struggling with that organizational apathy here?
[TC Niedzialkowski] Yeah, I think the challenge is, like, it’s very important as the organization to protect our users’ data, to protect our infrastructure, to protect our applications, our APIs, basically the doors and windows people use to get into our organization, but what’s the residual on the device? What is the risk of this application on the user’s device? Which is locked, it has all the Apple protections or Android protections or not, right? Butwhat’s the risk in terms of the posture of that device in the user’s hands?
[Rich Stroffolino] That certainly will resonate with some of our listeners. Montez, I’m going to ask you the same question. Is that what you’re seeing with this kind of organizational apathy? Why are you thinking this is the case?
[Montez Fitzpatrick] Well, at first, I did care, but TC has convinced me to not care anymore.
[Rich Stroffolino] [Laughter]
[Montez Fitzpatrick] And so, that’s really where we are. And so, no, TC makes some great points there. And honestly, I think it’s sort of an out-of-sight, out-of-mind kind of situation with the mobile devices.
[Rich Stroffolino] All right. Well, today we’re going to be talking with Ryan Lloyd, the chief product officer over at Guardsquare, and kind of maybe unpacking this a little bit for us here. So, to start out, Ryan, we need to answer three essential questions. That’s how we start every episode of Security You Should Know. I need you to help me explain the value of your solution to my CEO. What does your solution do? What does it not do? And what is the pricing model? Can you help us out here?
[Ryan Lloyd] Yeah, sure thing. So, first thing, in terms of explaining the problem to the CEO, think about mobile apps and in an e-commerce sense, it drives 70% of e-commerce traffic. Over half of banking and financial transactions occur on the mobile device. So, these apps are powering our digital lives, and the question isif your primary digital channel for interacting with your customers flows through the mobile app, how do you ensure that it remains secure and doesn’t put your brand at risk? In terms of what we do and what we don’t do, our primary focus is on mobile app security. So, helping app developers, app publishers ensure the security of their apps before they release them.
What we don’t do is focus on device security, right? So, mobile device security is more about ensuring high-profile targets and users aren’t susceptible to zero-day attacks and things of that nature. That’s more in the realm of Apple and Google and their shared responsibility. And then from a pricing model perspective, we provide a platform of security capabilities. They’re priced as an annual subscription on a per-application basis, and the price itself scales based on the popularity of the app. So, small startups pay a smaller price. Large, scaled organizations pay a higher price point for access to those capabilities.
[Rich Stroffolino] All right, I’m liking a lot of what I am hearing, but devil is always in the details. We need to get some answers to some more questions, I feel like. Montez, help us out here. Let’s get it started here. What other questions do you have for Ryan and for Guardsquare?
[Montez Fitzpatrick] Rich, believe it or not, in my youth, I used to play around with some portable executables for the fun times back in the day.
[Rich Stroffolino] [Gasp] For the lulls?
[Montez Fitzpatrick] For the lulls, that’s right, absolutely. And when I did a bit of cursory research about Guardsquare, and it’s definitely a space that is ripe for needing help, it sort of reads to me kind of like a binary packer. I know that’s an oversimplification there, Ryan, but is that kind of maybe part of the offering?
[Ryan Lloyd] Yeah, there’s really three components to our platform. So, there’s mobile app protection, protecting those binaries from reverse engineering and tampering, mobile app security testing to scan and analyze your app to find vulnerabilities or weaknesses, and then real-time threat monitoring, so you can collect threat data and signals from the users actually using your app on real devices once it’s released.
[Montez Fitzpatrick] That’s great. So, this is always kind of like a lead-in question for me. So, does your solution give the developers an opportunity or the ability to tune how the app is unpacked? And really, what I really want to know is can the developers dolikeunsafe operations, likefor instance, save data outside of the container?
[Ryan Lloyd] Good question. So, the main capabilities of our protection solutions is obfuscation and then runtime checks or signals that we instrument into the application to detect unsafe scenarios or conditions that might be relevant for an app developer or publisher. So, the code obfuscation is something that the developer has control over to identify the security-sensitive components of their application and to apply multiple layers of code obfuscation to protect that sensitive IP to make sure they’re not leaking API endpoints they’re calling in to protect different secrets or intellectual property, maybe machine learning models that are stored locally inside their app, different assets, resources, things of that nature. So, the developer has a lot of controls to configure the features that are relevant to their threat model for their app to build into those security protections.
[Rich Stroffolino] All right, TC, I’m going to let you jump in here. You don’t have to hearken back to your youth for your question, but you will get bonus points if you do. What other questions do you have for Guardsquare?
[TC Niedzialkowski] Yeah, so I mean, when I’m looking at the product offerings, it’s really interesting to me this combination of both the RASP, Runtime Application Security Protection, and the mobile app protection obfuscation. And so, I think maybe there’s almost two lanes in which to answer this question that’s really critical to me. So, from my perspective, if it’s not easy, it’s not going to happen. If it’s not completely automated and AI native, it’s not going to happen, especially at the speed of development teams today. So, for both pieces, RASP and implementing these actual mobile app obfuscation, whatever testing, are you able to access those services through a CLI, through an API, through an MCP? And are you able to have agents like a cloud code completely complete the run in terms of implementing this, passing the checks, validating the checks, getting it through the latest update? And what’s the overhead to developers? I guess this is more focused on the CI build pipeline. Like what type of overhead do you typically see instrumenting this? Because I know previous RASP solutions, that’s where they would fail out a lot of the times.
[Ryan Lloyd] Yep, yep. So, we do provide a CLI, local CLI, for being able to process your application. You can think of our approach as a compiler-based technology. So, you build your app the way you normally would, an APK on Android or an IPA for iOS, and then you submit that through our CLI to our platform. And we’re going to post-process that application. So, we’re going to decompile it. We’re going to apply the levels of obfuscation. We’re going to inject these runtime checks into the code. Then we’re going to recompile it. And then your resulting app is a protected binary. So, in terms of overhead, it’s essentially a duplicate build.
So, you’re going to have a two-stage build process. The build to create your unprotected app, and then a parallel build, which is roughly equivalent in time to build the protected version of that application that has the security configurations baked into it. The main onboarding experience is in configuring and making the security choices of what you want to obfuscate and protect. And the main thing for developers to be aware of is to go through the process to profile their app so that we have good understanding of where it’s safe for us to obfuscate and where it’s safe for us to inject checks without impacting the performance of the application. Because when you’re modifying code, you don’t want to degrade the performance by instrumenting these checks in performance-sensitive areas or applying heavy obfuscation techniques to code that can’t handle that performance overhead.
[TC Niedzialkowski] Montez, I hope you don’t mind if I do a follow-up on this one.[Laughter] So, again, there’s two lanes. So, when it comes to that runtime protection and attack monitoring, threat monitoring, is there an API or MCP server for that? And what I mean isI don’t want anyone from my team to have to go and look, right? I want to be able to basically give an agent instructions and have them monitor the MCP and let me know when we need to dive in.
[Ryan Lloyd] Yeah, so the runtime protections are injected at build time. So, that’s really more of just a build step. And once you configure the checks that are important to you, it just can be configured as part of your CI pipeline to run the protection command and re-protect any new subsequent builds you have. And then from a monitoring standpoint, we offer a threat monitoring dashboard and service that alerts you to when these checks are actually triggered on end-user devices, and for that, we have a SIEM API and webhooks so that you can configure alerting or forwarding of those events to any downstream consumers where you want that threat data to be consumed.
[TC Niedzialkowski] Okay, so there’s no MCP, but there is an API. Is everything that’s available via the interface available via the API in terms of the data? Or is there some piece of information where I will have to log into the dashboard?
[Ryan Lloyd] No, I would say our API and the webhooks provide all of the threat event information that you would see in the UI.
[Montez Fitzpatrick] Yeah, TC, that was a great question. And maybe this one is not so great, but[Laughter] when we think about, when we say the whole word about security obfuscation, we’ve been drilled into us forever, right,that obfuscation is not necessarily security, and those don’t necessarily line up. And so, I want to ask you, so how do we justify it and say, “Yeah, no, this is actually a good methodology and a way of going,” in light of the fact that we could say that obfuscation is maybe potentially tantamount to having a fence, right? And so, fences make good neighbors, right? But if someone’s really aiming to break bad, it may not do much. So, help me, convince me about that.
[Ryan Lloyd] Yeah, it’s a great point. Security through obscurity has always been sort of the phrase that’s used.I think the thing to keep in mind here is that our goal here isn’t to leverage obfuscation to hide a really important secret or key that we’re trying to keep private forever. That’s not a good strategy. For us, obfuscation is an approach to make your app more resilient to reverse engineering and tampering. So, first of all, what’s required is you need to have many different layers of obfuscation working together to sufficiently increase the skillset required to analyze your application to make it resilient to attackers. So, yeah, the goal is not to Fort Knox your application. It’s really more just making it so difficult and time-consuming for someone to reverse engineer your application that it deters the activity.
[Montez Fitzpatrick] No, that’s fantastic. And would love to hear maybe a little more about the piece, and I forget how you put it, but essentially it talks about you hearken to like integrity there. And so, I think that’s one often misplaced part of the CIA triad that we maybe leave till later or really never, right, is maybe enforcing integrity. So, can you tell me how the product helps top off integrity on top of an application?
[Ryan Lloyd] Yeah, we think of integrity in sort of two aspects. There’s app integrity and code integrity, right? So, app integrity is, “Is the app I’m installing onto my device the same as the app that the developer built and developed?” So, for that, we use these certificate checks, which really ensures that the app itself hasn’t been modified since it was released. And this is really important because we’re seeing an increase in malware sort of phishing attacks where attackers are taking a popular branded app, decompiling it and reverse engineering it, instrumenting it with malware and information that can leak user credentials, repackaging it, and then using phishing campaigns to drive users to install those malicious versions of those applications. So, certificate and app integrity checks are a way to prevent those repackaging-based attacks and phishing campaigns. And then code integrity is more about ensuring that there isn’t someone able to dynamically modify the behavior of the application at runtime. And so, you think about the mobile app and the device itself might be secure, but the person using the device may not be secure, right? So, attackers have access to the application. They can tamper with it. They can change its behavior using dynamic instrumentation tools like Frida.And so, code integrity checks are ways to ensure that the code running and executing is as it was intended to be.
[Rich Stroffolino] All right, we’ve got time for one more question from the panel.
[TC Niedzialkowski] Yeah, so I want to go back to the CI/CD pipeline question because it sounded like you talked about having essentially two parallel apps. And I’d love to know, and I’ll lead into the “why” here, but what proportion or what percentage of your customers run it on every PR build or every pull request build versus only release builds? And the reason is is that if you’re only running it on the release build, if it’s such a long parallel task to complete that work and have that release build ready, that means internally when you’re doing your testing, you’re not seeing how the RASP implementation affects the actual app behavior, right? So, if you’re not testing the app that’s going to be in customers’ hands, you’re not going to get the full feedback about the potential behavior, lags, lowness, inconsistency. So, I’d just love to know again, how do you see customers doing it? What’s the kind of overhead? Because I don’t want to sell a story and surprise our developers, and then it turns out this is actually the longest stick in the pile to integrate into the process.
[Ryan Lloyd] Yeah, yeah. I mean, the good news about mobile apps is that their build times tend to be much more reasonable than lots of other parts of the infrastructure and stack that you would build. So, usually we’re talking 5 minutes, 10 minutes max for build times of a mobile application. So, they are two planes that run in parallel. I would say the majority of our customers do run these protected build steps on the majority of their pull requests or at least on their nightly builds. The main reason for that is because a lot of times, they’re shipping app updates every night or every week. The frequency of release for mobile app updates is pretty quick. So, it’s not like they plan a release, and a lot of these are just, “Hey, we grabbed the latest-release candidate build that’s of good quality,” and run with that.
[Rich Stroffolino] All right, Ryan, lots of great information there. I love digging into all this. And as the host of Cybersecurity Headlines, the real-world implications of not having this are, Ryan, like you were talking about, it hits you in the face every single day in the headlines here. But Ryan, what’s one thing we didn’t ask about that we need to know about Guardsquare?
[Ryan Lloyd] Well, I think the one thing that’s unexplored that’s becoming more interesting for our customers is this intersection between mobile app security and API security. So, you can do a lot of work to protect your mobile app, but at the end of the day, if you have an API that’s accepting API requests, how do you ensure that it’s a legitimate mobile app that’s connecting and interacting with that API? So, that’s an area where we’ve made some investments last year in building an attestation model where you can actually bind the server-side APIs with validations and checks that confirm that it’s a legitimate mobile app accessing that API endpoint, and it’s a good way to reduce bot behavior and malicious scripts or repackaged apps from being able to even initiate an authentication flow or sensitive API transactions.
[Music]
[Rich Stroffolino] Well, that’s just about it for this episode of Security You Should Know. To learn more, head on over to guardsquare.com. And if you have any feedback about this show, send it to us, feedback@CISOseries.com. We’d love to hear from you. A huge thanks to TC and Montez for helping us learn more about Guardsquare. And thank you, Ryan, so much for your time and being game to answer all of these questions. And thank you for listening to Security You Should Know.
[Music]
[Voiceover] That wraps up another episode of Security You Should Know. If you like this program, please subscribe, tell your friends, and leave us a review. All companies showcased on this program are sponsors of CISO Series. If your company would like to be spotlighted and interviewed by our security leaders, go to our contact page on CISOseries.com or just email us at info@CISOseries.com. Thank you for listening to Security You Should Know, connecting security solutions with security leaders.
[Music]