Ship It Conversations: Guardsquare’s Joel DeStefano on Mobile App Security, Runtime Protection, App Hardening, and Why Scanning Isn’t Enough

Mobile app security is one of those areas where cloud and backend people can get a little too comfortable because in the backend, you control a lot. You control the runtime, you control the servers, you control the network, you control the policies. You can wrap the thing in IAM, logging, monitoring, deployment controls, runtime controls, and a whole pile of infrastructure that at least gives you a fighting chance. Mobile is different. With mobile, you ship the app and now it is out there. It is on someone else's device, in someone else's environment, maybe rooted, maybe jailbroken, maybe running next to malware, maybe sitting in the hands of someone trying to reverse engineer it, hook values, bypass checks. Scrape data, or figure out how your business logic talks to your backend. And that changes the trust model because scanning the app before release matters, but it does not answer the bigger question. What happens after the app leaves your build pipeline? That is really what this conversation is about. Not just mobile scanning, not just App Store approval, not just we don't store secrets in the app, so we're fine. More like, what does mobile app security actually mean? When the thing you shipped is now a public artifact that attackers can pull apart, instrument, modify, and abuse. I'm Brian Teller from Teller's Tech, and this is Ship It Weekly. Welcome back to Ship It Weekly, where I filter the noise and focus on what actually matters when you are the one running infrastructure and owning reliability. Most weeks, it's a quick news recap. In between those, I do conversation episodes with people who are building platforms, running infrastructure, securing applications, and thinking through where this industry is actually headed. Today is one of those conversations. I'm joined by Joel DeStefano from Guardsquare, where he is a product manager. We're talking about mobile app security, what it means beyond basic scanning, why mobile has a different trust model than backend or cloud systems, and how teams can improve posture without turning CI/CD into a nightmare. And I like this conversation because mobile security can be easy for infrastructure teams to underestimate. A lot of us are used to thinking in terms of backend controls, cloud permissions, network boundaries, deployment pipelines, runtime monitoring, secrets management, service to service auth, the usual stuff. But a mobile app is not just another backend service. Once it ships, you do not control the runtime in the same way. You do not control the device. You do not fully control what else is running on that device. And you definitely cannot assume that the OS the App Store or a pre-release scan is going to cover everything for you. You start with the obvious goal. Build the app. Scan the app. Avoid obvious vulnerabilities. Check dependencies. Fix bad TLS configuration. Do not ship secrets. Get through the App Store process. Then reality shows up. Attackers can decompile the app. They can inspect the business logic. They can look for sensitive workflows. They can run debuggers and instrumentation frameworks. They can hook values, bypass checks, abuse accessibility services, overlay screens, or try to convince your backend that a compromised app is still genuine. And somewhere in the middle of that, mobile security stops being just a pre-release checklist and starts becoming a layered strategy. In this conversation, Joel and I talk about why mobile is different from backend and cloud, what teams assume the OS is protecting them from, why scanning is necessary but not enough, and why there is no sensitive data in the app can be a dangerous oversimplification. We also get into the main layers of mobile app security, testing, hardening, runtime protection, and monitoring. That includes code hardening, obfuscation, runtime checks, detecting rooted or compromised environments watching for hooking frameworks and monitoring what is actually happening after the app is in the wild there is also a good thread in here around cicd because security that destroys the release process usually does not last so we talk about build overhead release gates what should block a release what should become tracked risk and how teams can add mobile protections without making every app release feel like a hostage negotiation. And toward the end, we talk about AI accelerating attackers, why fundamentals still matter, what a sane first step looks like for teams trying to improve mobile security, and why App Store approval should not be treated like a security strategy. So if you work around DevOps, SRE, platform engineering, AppSec, mobile engineering, CI/CD, or you support teams shipping mobile apps that connect to important backend systems, this one should be worth your time. All right, let's jump in. Today, I'm joined by Joel DeStefano from Guardsquare, where he's a product manager. We're talking about what mobile app security actually means beyond basic scanning, why it's different from backend and cloud security, and how teams can improve posture. Without turning CI/CD into a nightmare. Joel, thank you for joining me. Hey, Brian, thank you. I appreciate being invited onto the show. So I'm curious, why is mobile different from backend and cloud? What changes in the threat model? Fundamentally, it's a shift in the trust model because... On the backend and in cloud, you have relatively good controls over the runtime environment, the servers, the infrastructure, the policies that you put in place. If you look at a mobile application, you ship it. It's a public artifact at that point. You completely lose control over what's happening to that and how is it being used. So once it's out the door, if you don't have reasonable levels of protection into that application, it can be used to read. Attackers can reverse engineer that. You might be installed into an environment on a phone that has malware that is going to scrape that user's information. So there's risks when you ship a mobile application to go. I wouldn't say it goes beyond the backend. It basically essentially opens up a different paradigm of risk and a different trust model. So if you're like a DevOps or SRE person, what's the simplest way to think about it? So there's, I would. Think about it in terms of integrating security into your everyday life, into your build processes. And there's a couple of different facets to that. There's the scanning aspect, which you had mentioned. Scanning is something you would do before you release the application. That's sort of like your background to make sure that. I don't have any vulnerabilities. I understand my third party dependencies. My coding practices, like literally how I code something is not insecure and or improper. So I could maybe have TLS improperly implemented. Well, that's going out the door, right? So that's sort of the, we do this in -house, we do this before release. But then once you release those type of things, those are more point in time type of protections. Now you've done your due diligence on. Prior to release. When it goes out, you need to still be able to trust that the applications and the users that are connecting to your backend are using a genuine application. It hasn't been compromised. And the integrity of that app and the entire runtime execution is good. That's the only way you could actually sort of protect yourself. You need to be able to trust it. And that's sort of the gap and the challenge with a mobile app opposed to a backend or a cloud service is that. That visibility is lost. It's basically a public artifact at that point. And you really don't know. You don't control that environment. You don't know if it's going to a malware environment. You don't know if it's going to the hands of attackers. You don't know what they're doing with it. That's the real fundamental difference. I would call it a shift in trust. And it's essentially centered around the control. Is there common misconceptions that people have about mobile app security? Does it just kind of encompass what we just talked about or is there? There's a handful of misconceptions. One might be the actual scanning, like that scanning is enough. If I, you know, use proper coding practices and I check all my third-party libraries and there's no vulnerabilities there and I do a lot of dependency tracking, that you're done. Or if you do that in combination with an app store approval process that, okay, we're all set. We really shouldn't need to consider security at that point. That is a... A misconception because of what i just explained um oh yeah i wanted to bring up okay yeah and there's another misconception about what if there's any sensitive information in the actual application i have come across a lot of people who say well we don't have anything sensitive in our app we do all our protections on the backend with our APIs. And that may be true. They may not have a lot of sensitive information. And if they code it right, they don't have a lot of sensitive information. What they don't understand generally is that an attacker doesn't necessarily need to find the same things that you might be worried about or think are a concern. I would say almost any app that has business -critical workflows transactions, logins, dealing with money. I don't really care where the sensitive information is stored. Something can be learned from decompiling that application. And again, this goes back to that trust and that lack of visibility. You don't know what they're figuring out from that application. That's why you proactively harden that app with code hardening. And we call it obfuscation to basically scramble up names and things so that you can't reverse this and really kind of quickly figure out the business logic or what's going on with this application. In addition to that, there is a requirement to do runtime checks. And now those are basically checks that can be injected into that application that goes beyond just reverse engineering it. into detecting whether or not something about that environment or that runtime execution at that exact moment is not right. There are certain techniques, frameworks, and utilities that attackers will use to maybe change a value, maybe bypass something in the application, and those need to be picked up because those are not necessarily protected by code hardening. They help prevent that from happening because it's harder to figure out where I might want to go look, but... Those things can still be attached to the application. You could run it in a debugger, you could run instrumentation. And then once you start doing these things to say maybe hook a value, and what a hook a value basically means is that in simplest terms, if I'm depending on a particular variable to come back to allow myself access to do something, I could hook that variable and basically change the value. So if I can't get in with a false value, then maybe I'll hook it and I'll change it to true. So there are a lot of threats and risks that are in that mobile application beyond we have no sensitive keys in there or something like that. It's not just the PII from customers. It's not. It's not. I mean, there are probably apps out there that aren't worth protecting, but that's fine. They'll probably know. But I have heard that narrative, which is a big misconception from people. That work at places that i know for fact are dealing with logins transactions money so that is a dangerous misconception is there a different con security concern between android android ios windows and like what are those if there are I wouldn't say there are different concerns. The landscape, the ecosystem is a little bit different. The same type of attacks can be carried out on both platforms. The same risks are there. The ecosystem in Android is a little bit different because it's a little less controlled as far as the number of devices that are floating around in the world, the number of operating systems that are still in support. And it is an open source model, but it... That is a misconception as well. There's a misconception out there that because iOS is closed source and Android is open source that all the problems happen there. There's probably a degree of people, their impression of that being skewed by the fact once you get outside of like the United States and Europe, almost everybody's using Android phones and they're using older ones. So worldwide, the distribution, not everybody is walking around with $1,000. iPhone in some parts of the world. So essentially, same attacks. You can attack iOS in the same ways that you attack Android. The difference is that that ecosystem is a little bit different and there's many more devices out there that are Android. So what do you think teams assume the OS is protecting them from that maybe it isn't? Well, it's definitely not protecting them from somebody reverse engineering the application. or trying to figure out how they're going to bypass their certificate in that application, or it's not going to tell you that another app was downloaded that is malicious and it's going to have a screen overlay, or it's going to abuse accessibility services on your application. The operating system... Has implicit security, but it's a different focus. This is a different paradigm. It's not, it's concerned. It has some security measures for the actual device and the operating system itself, but it's not specifically concerned with the application or what else is running on there. It would be incorrect. Assumption that the operating system is going to keep me safe. It's like anything in security. You're making an incorrect assumption if you think anybody else is going to take care of your problems, essentially. It's not the App Stores in their approval process that's going to save you. It's not the operating system that's going to save you. It's not your scans that you run ahead of time to make sure that your dependencies have no vulnerabilities and you're coding well. The only thing that's going to really save you is to... Have a reasonable level of trust that that application that's connecting to your APIs is genuine and it's not compromised, meaning it hasn't been modified. It's not a fake app. That's the only way to have any level of comfort that you've done what you need to do from that angle. And it makes a lot of sense if you think about it. In this day and age, you would not ignore some part of your system. And these are, let's face it, those are mobile apps are not apps. They're payment platforms. They're banking platforms, they're medical device managers, they're retail, streaming, entertainment platforms, heavily monetized by these companies. I know it has outpaced the web as far as where people spend their time and handle workflows and transactions. So if you look at it from the business perspective, these are critical to these organizations, large and small, and those are critical workflows. And there is something to be learned from that application, even if it is not sensitive to data floating in it. Yeah, for sure. And so we kind of talked a little bit about scanning. Teams love to say that we scanned it or we do scan it. Why is that not enough for mobile? I think so. The way I kind of explained it a little bit earlier is that scanning is going to tell you something about how you might be coding that application or the way you're implementing certain inherent security measures like secure communications and TLS. If you scan the application, it might say, well, it's probably not a great idea to have this secret. Floating around in your application. So, okay, I'll take the secret out. Or my TLS is improperly configured, so it's actually not doing what it's supposed to do. Scanning can check for your vulnerabilities in third-party libraries. So you're doing your due diligence to, it's like kind of taking care of the basics, to be honest with you. And those things do not actively or explicitly protect that application from what an attacker is going to do to that application as far as decompile it. Start picking away at it. Figure out exactly where the sensitive parts, the sensitive workflows of that application engage with your backend, essentially. You have to do both, essentially. And that's where it comes back to, like, it's not a narrow scope. It's not as narrow a scope as just running a scanner. That's too narrow of a scope. And it's ignoring all the other implications and inherent behavior within an application. And it's not protecting you specifically. From what the attacker is going to do. The attackers now are much more organized and much more financially motivated than we saw even like 10 years ago. And just like everything else, they have at their disposal a large number of pretty advanced frameworks and tooling to actually help them do this faster. It's a bit of an arms race in that regard because we can't control. The things that are out there that they're going to be able to use, but all those things that are out there help them carry off these specific attacks and also speeds up their time so that they can sort of industrialize the entire thing. Whereas maybe 10 years ago, it would have been somebody taking a look at this manually, decompiling it and playing around and maybe spending a week, a week and a half trying to figure out what's going on. Now these advanced frameworks and utilities are out there that speed that up very quickly. I'm guessing AI is probably also impacted. Like the time for CVEs and impacts and security vulnerabilities? Have you noticed like an acceleration over the last like year or so? We, so there's undeniably a bit of a paradigm shift there in the sense that attackers are going to be looking and using AI assistance. And what that will do is essentially speed up the time it takes for them to figure out. The logic and figure out what they want to go after. We have not seen an increase in our customer base being attacked as a result because our fundamental principles that we have in place are actually the right ones from the beginning prior to the explosion in AI here. And it's going to be true really. In many different paradigms, but especially in the attacker and the defender space, the AI assistance is going to speed up the attacker. If the defender was not in the right place or not using the right approach to begin with, then they're going to be in a little bit more trouble than someone who has the right fundamental principles in place and multiple layers of... Reverse engineering static reverse engineering very resilient runtime checks and even a service to basically validate that your application that's connecting to your apis is a genuine non-compromised uncompromised app so yeah it changes the game a little bit but it does not fundamentally change it it gives them some tools it gives everybody some it gives everybody some tools so I was reading on Guardsquare. Can you like explain the layers to me? Kind of touched on a little bit. There's testing, hardening, runtime protection, and monitoring. How does that work as like one cohesive strategy? Yeah, so the testing is like the scanning aspect, which would look for the vulnerabilities, insecure practices, insecure coding practices, improper implementations. The hardening is our core product set, which is the decompiler-based or a compiler -based approach to adding protections. Into that application. So we'll take the output IPA or APK, depending upon the platform, decompile that, add the code hardening and obfuscation to basically make that decompiled code look like gibberish to somebody, and also inject what I was referring to as runtime checks. So, for example, is this device rooted or is someone attaching a hooking framework? Has somebody gotten around the actual certificate? Or is there malware on the device that's trying to abuse accessibility services or using overlay or a screen reader to scrape information? So that's the hardening aspect. And then the monitoring aspect is another important part of this broader picture, which is, I spoke about this earlier, where that whole trust model, that lack of visibility. Even if you are protected, you still want to monitor what's going on because things shift. You might see all of a sudden evidence of certain behavior in a certain part of the world. So maybe you want to pause for a second and be like, hmm, do we want to change our configuration, release a new application, maybe improve some of the protections here? Like what's going on? So it's not just, you can't just add your protections and just, I'm done. I'm good. You should probably. You should be monitoring that and essentially allow yourself the flexibility to change your posture as needed, essentially. So, OK, keeping the like CI/CD framing, we talked about the runtime protection, the obfuscation. Does that create any like or what is the build overhead from that? And does that slow builds down? How do you keep security checks from like killing the velocity of like normal app development? That's a good question. I mean, that's always a concern in any paradigm of security, no matter what it is, because. It doesn't come for free. Like you, if you're going to do it correctly, but there's always a line between protection and usability. You don't want to, you know, put a motor on your house and a drawbridge because you're going to end up leaving the drawbridge down because you really don't want to wait for all that time for it to go up. So yeah, there's always a trade -off there where you have to monitor and take care of the constraints. So you want to protect as much as you can without infringing upon your constraints. People might have constraints about the size of their application. They might have specific performance constraints. And these things will always sort of shine brighter than the protection because the fundamental job of all these teams is to release this application with features that drive business and bring in revenue and they can monetize their services. So there is a balancing act. It's a unavoidable balancing act. But if your vendor has the right tooling and options and features, it shouldn't be a pain that's not worth, you know, accepting or a penalty that's not worth accepting. Yeah, it's a fundamental part of adding protections. But if you go about those protections in the right way and use the right tooling and understand what you're trying to protect, it should be a minimal impact to your delivery process. So, okay, with that in mind, what would like a good or a sane gating strategy look like? Like what would block a release versus what becomes tracked risk for down the road? As far as testing the application is concerned? Yeah, or vulnerability tracking or whatever. Like how does that impact the CI/CD work? Depending upon the severity of the vulnerability or the insecure coding practices, it could be a high risk thing that should be mitigated immediately. But a lot of scanning tools will also surface maybe medium or low risk things that you can just kind of track and be like, okay, I'm going to put that on my wishlist. And next time around, you know, we're not going to block the release over this because it's not severe. It's not a high risk situation. And then the lower ones, you can basically make a list. That's what people do. And then sort of when they have time, pluck away at a few of those because those are not critical, critical risks. From the testing standpoint of a protected application, going back to The usability, it cannot impact the usability and whatever those constraints might be. So it has to be protected and then verified by the QA team that, okay, we're still within the constraints of acceptability. And then if it's not, maybe there's a change to the configuration or maybe you're being too aggressive. On certain aspects of the protection, in which case you can change your posture there and dial it down. If you don't have evidence of past attacks, you're not going into a high risk, a really high risk known malicious situation, maybe you could gamble a little bit and take a step back on doubling down on those protections for the sake of that usability. But there is a sweet spot, really. I mean, essentially, you know, you don't want to, I probably didn't give the best advice there. You really don't want to look at it that way. You want the sweet spot, which is. I'm reasonably well protected against all of these things with minimal to no impact in the usability. Certain things are acceptable as far as impact. Certain things are not. It's not acceptable to cause a stability issue, but it might be acceptable to lose a couple milliseconds on a particular transaction or some sort of a method or something for the sake of the assurance that it's now secured, right? So it's a bit of a trade-off there. What's important to you from a protection standpoint, and also what is important or critical on the constraint side. But those are essentially the only things that would really just like stop the release. Like I have high severity, critical things that need to be fixed. And that comes down to the policies, the internal policies, compliance policies, and governance of that organization, that they make a rule that, and they should make a rule that there's a high severity finding and scanning. It's a stop the press thing. And usually those things shouldn't be too difficult to fix. And then as far as protections, you know, it's just like any release cycle. You add it, even if it's not a protection, you still have to test your application. So when you integrate the protection into your CI/CD, it's not like you're going down a different path. You're essentially just running it through your system tests and your QA team with the protections. So if you're an engineering team and you're trying to improve mobile app security posture today, is there like a top three or top five things that you would start with? Yeah, I would say not to get overwhelmed. I would take a step back and start asking some really basic questions. What matters to us? How is this app interacting with our backend? How could this, what could possibly hurt us? Like start brainstorming around that and then consider a structured programmatic approach to layering in your security essentially so that it becomes part of your routine. Can't be an after the fact type of thing. You should be thinking about it up front, during, and obviously at release and after release. So it's a bit of a mindset. If you treat it as a checklist type of thing at the very tail end, that's where you usually get yourself maybe into some trouble because you either didn't protect it well enough or you did it in a way that... Might risk some of your constraints. So it's a mindset that security is top of mind across all facets all the time. And if it's part of your daily routine, just like exercising or something, if you make it a habit, you're going to do it all the time. If you're considering security as being important, as you should, it just becomes, it's an adoption and understanding that this is part of life. And it's the right way to go about it because you'd rather not be. In the news because someone made an example of your application or some of your users were victims of fraud or even your organization was part of some sort of criminal misuse situation, which does happen. Yeah. So kind of thinking of the inverse in that, is there anything that you would kind of throw out as security posture that maybe companies are doing that maybe they shouldn't be? It's kind of not effective, not really providing value from a security perspective. I mean, the worst thing they could possibly do is the scenario we were talking about earlier, which was basically just assuming that some level of scanning is enough and App Store acceptance is sufficient. As far as other things, I think people probably are not generally aware enough of the ways attackers go about reverse engineering applications. So it's hard for them. Maybe it's probably more a situation of... Misunderstanding or like not being knowledgeable enough. If you don't know about something, you have no idea the importance of code hardening or changing names, then you're probably not going to value it at all. So I don't know if that answers your question or not, but I would certainly, and there's plenty of information and knowledge out there. You can go to our website. There's organizations like OWASP that have lots of guidance around. What is needed to properly secure a mobile application. And I would recommend that highly because it's really like anything else. If you don't really know what you're doing or you don't really understand the fundamentals, like you're probably not going to be doing this or you're probably not going to pick the right vendor. You're probably not going to use that vendor the right way. Yeah, it's an education thing. Awesome. So where can people find more about you, about Guardsquare? So www.guardsquare .com, we have a wealth of knowledge on there, like resources and blogs. And they're not just, you know, for lack of a better word, marketing fluff. They're written by security research analysts that work for us. And they'll give you a broad and, if you want, a deep level understanding of the protections that are needed and the techniques that are attacks attackers are essentially using. We also have a security research center on the website. So there's a lot of research. There's a lot of resources and papers to get a basic knowledge and a good understanding of what you might need to do to properly secure your mobile application. Cool. Awesome. I'll put links up for Guardsquare's blog, OWASP, and some of the other things that we talked about in the show notes. Sure. Joel, thank you so much for coming on. Really appreciate it. Appreciate it, Brian. You're welcome. Thank you. All right. That was my conversation with Joel DeStefano from Guardsquare. My biggest takeaway from this one is that mobile security is really about the trust boundary moving. In backend and cloud systems, we spend a lot of time trying to control the environment. We harden infrastructure. We manage IAM. We monitor runtime behavior. We control deployments. We log everything we can. We build policies and guardrails and assume that if something weird happens, we at least have some visibility into the system. With mobile, that changes. You ship the app, and now the app is out in the world. And once it is out there, attackers can study it on their own time. They can decompile it. They can instrument it. They can run it in weird environments. They can try to bypass checks, hook values. Scrape information, or learn enough about the workflow to abuse the backend in ways the backend team may not have expected. That is the part I think is worth paying attention to. A lot of teams treat mobile security like a scanning problem. Run the scanner. Fix the dependencies. Fix the obvious insecure coding patterns. Make sure there are no secrets sitting in the app. Pass the App Store review. Ship it. And to be clear, that work matters. But it is not the whole story. Scanning tells you something useful before release. It helps you catch problems in code, dependencies, configuration, and implementation. But it does not protect the app once someone is actively trying to reverse engineer it or tamper with it in the wild. That is where the layered approach matters. Testing matters. Hardening matters. Runtime protection matters. Monitoring matters. And honestly, the monitoring part is easy to underappreciate. Because even if you do the right things before release, the threat landscape changes after release. Attackers change tactics. Activity spikes in certain regions. New tools get popular. Something starts showing up in the field that you did not plan for. If you are not watching that, you are basically guessing. I also liked Joel's point that we do not have sensitive data in the app is not the same as the app does not need protection. That is a trap. A mobile app does not need to contain a database full of customer PII to matter. If it handles login, payments, banking, medical workflows, retail transactions, subscriptions, account recovery, loyalty points, streaming access, or any business-critical path, then there is something useful for an attacker to learn. The sensitive thing may not be a secret string. It might be the workflow. It might be the trust relationship. It might be how the app talks to the backend. It might be the condition an attacker needs to bypass to make the backend believe something it should not believe. That is a different way of thinking about the app. Not just what data is stored here, more like what can someone learn from this app and how could they use that knowledge against the system? The CI/CD part matters too, because security teams can say protect everything all day long. But if the protection adds too much pain, slows builds too much, creates unstable releases or turns every app update into a fight, engineering teams will find a way around it. So the goal has to be sane integration. High severity findings should block. Critical issues should stop the release. But lower severity findings may become tracked risk. Runtime protections need to be tested like any other release change. Performance and stability constraints still matter. There is always a trade-off between protection and usability. That does not mean avoid security. It means design it like it has to live inside a real delivery process. Because it does. The other thing that stood out is the AI angle. AI may make attackers faster. It may help them understand logic faster. It may help them reverse engineer or reason about code faster. But Joel's point was that the fundamentals do not disappear. If you already have the right layers in place, AI does not completely rewrite the model. It increases speed. It gives attackers better tools. It raises the pressure. But the principles still matter. Know what matters in the app. Protect the app. Make reverse engineering harder. Add runtime checks. Validate that the app connecting to your backend is genuine. Monitor what is happening in the wild. And do not assume that the OS, the App Store, or one scan in the pipeline is going to save you. That is probably where I would land with this whole conversation. Mobile security is not magic. It is also not just scan it and ship it. It is a different trust model and teams need to treat it that way. I'll have links to Joel, Guardsquare, OWASP mobile resources, and anything else we mentioned in the show notes. If you enjoyed this conversation, follow or subscribe to Ship It Weekly wherever you listen to podcasts. It helps the show and it makes sure that you get both these conversation episodes and the weekly DevOps. SRE, Platform, Cloud, and Security News Recaps. You can also find the show notes and links over at shipitweekly.fm. Thanks for listening, and I'll see you later this week.