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

Transcript

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.

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

Watch this episode here

Chapters

Transcript

Catch This Episode

Host Commentary

Show Notes

👤 Guest

More from Ship It Weekly

EKS Rollbacks, GitHub Actions Supply Chain Attacks, AI Agentjacking, CloudWatch Log Alarms, and Why Safety Nets Don’t Replace Ownership

CISA’s GitHub Leak, AI Root Cause Analysis, Copilot Agents, Claude Code in CI/CD, and Kubernetes Seccomp Risk

Ship It Conversations: Gareth Kersey on IaCConf 2026, AI, and Corey Quinn’s Terraform Keynote

GitHub RCE, AI Agent Prompt Injection, and the New Reality: Your Developer Toolchain Is Production Now

Get the next episode in your inbox