Back to all episodes
Ship It Conversations: Guardsquare’s Joel DeStefano on Mobile App Security, Runtime Protection, App Hardening, and Why Scanning Isn’t Enough
Explore topics
In this episode, Joel DeStefano from Guardsquare discusses mobile app security, emphasizing its unique challenges compared to backend and cloud systems.
Ship It Conversations: Guardsquare’s Joel DeStefano on Mobile App Security, Runtime Protection, App Hardening, and Why Scanning Isn’t Enough
Ship It Weekly
0:00
35:58
Transcript
0:00
Mobile app security is one of those areas where
0:03
cloud and backend people can get a little too
0:06
comfortable because in the backend, you control
0:09
a lot. You control the runtime, you control the
0:12
servers, you control the network, you control
0:15
the policies. You can wrap the thing in IAM,
0:18
logging, monitoring, deployment controls, runtime
0:22
controls, and a whole pile of infrastructure
0:24
that at least gives you a fighting chance. Mobile
0:27
is different. With mobile, you ship the app and
0:30
now it is out there. It is on someone else's
0:33
device, in someone else's environment, maybe
0:36
rooted, maybe jailbroken, maybe running next
0:39
to malware, maybe sitting in the hands of someone
0:42
trying to reverse engineer it, hook values, bypass
0:45
checks. Scrape data, or figure out how your business
0:49
logic talks to your backend. And that changes
0:52
the trust model because scanning the app before
0:55
release matters, but it does not answer the bigger
0:58
question. What happens after the app leaves your
1:01
build pipeline? That is really what this conversation
1:04
is about. Not just mobile scanning, not just
1:07
App Store approval, not just we don't store secrets
1:10
in the app, so we're fine. More like, what does
1:13
mobile app security actually mean? When the thing
1:16
you shipped is now a public artifact that attackers
1:20
can pull apart, instrument, modify, and abuse.
1:24
I'm Brian Teller from Teller's Tech, and this
1:26
is Ship It Weekly. Welcome back to Ship It Weekly,
1:46
where I filter the noise and focus on what actually
1:49
matters when you are the one running infrastructure
1:51
and owning reliability. Most weeks, it's a quick
1:55
news recap. In between those, I do conversation
1:58
episodes with people who are building platforms,
2:01
running infrastructure, securing applications,
2:04
and thinking through where this industry is actually
2:07
headed. Today is one of those conversations.
2:10
I'm joined by Joel DeStefano from Guardsquare,
2:13
where he is a product manager. We're talking
2:15
about mobile app security, what it means beyond
2:18
basic scanning, why mobile has a different trust
2:21
model than backend or cloud systems, and how
2:25
teams can improve posture without turning CI/CD
2:28
into a nightmare. And I like this conversation
2:31
because mobile security can be easy for infrastructure
2:35
teams to underestimate. A lot of us are used
2:38
to thinking in terms of backend controls, cloud
2:41
permissions, network boundaries, deployment pipelines,
2:45
runtime monitoring, secrets management, service
2:48
to service auth, the usual stuff. But a mobile
2:51
app is not just another backend service. Once
2:54
it ships, you do not control the runtime in the
2:57
same way. You do not control the device. You
3:00
do not fully control what else is running on
3:02
that device. And you definitely cannot assume
3:05
that the OS the App Store or a pre-release scan
3:09
is going to cover everything for you. You start
3:12
with the obvious goal. Build the app. Scan the
3:15
app. Avoid obvious vulnerabilities. Check dependencies.
3:19
Fix bad TLS configuration. Do not ship secrets.
3:23
Get through the App Store process. Then reality
3:26
shows up. Attackers can decompile the app. They
3:30
can inspect the business logic. They can look
3:32
for sensitive workflows. They can run debuggers
3:35
and instrumentation frameworks. They can hook
3:37
values, bypass checks, abuse accessibility services,
3:41
overlay screens, or try to convince your backend
3:45
that a compromised app is still genuine. And
3:48
somewhere in the middle of that, mobile security
3:51
stops being just a pre-release checklist and
3:54
starts becoming a layered strategy. In this conversation,
3:58
Joel and I talk about why mobile is different
4:00
from backend and cloud, what teams assume the
4:03
OS is protecting them from, why scanning is necessary
4:07
but not enough, and why there is no sensitive
4:10
data in the app can be a dangerous oversimplification.
4:14
We also get into the main layers of mobile app
4:17
security, testing, hardening, runtime protection,
4:21
and monitoring. That includes code hardening,
4:24
obfuscation, runtime checks, detecting rooted
4:27
or compromised environments watching for hooking
4:30
frameworks and monitoring what is actually happening
4:33
after the app is in the wild there is also a
4:37
good thread in here around cicd because security
4:40
that destroys the release process usually does
4:43
not last so we talk about build overhead release
4:47
gates what should block a release what should
4:50
become tracked risk and how teams can add mobile
4:53
protections without making every app release
4:56
feel like a hostage negotiation. And toward the
4:59
end, we talk about AI accelerating attackers,
5:03
why fundamentals still matter, what a sane first
5:06
step looks like for teams trying to improve mobile
5:10
security, and why App Store approval should not
5:13
be treated like a security strategy. So if you
5:16
work around DevOps, SRE, platform engineering,
5:20
AppSec, mobile engineering, CI/CD, or you support
5:24
teams shipping mobile apps that connect to important
5:27
backend systems, this one should be worth your
5:29
time. All right, let's jump in. Today, I'm joined
5:38
by Joel DeStefano from Guardsquare, where he's
5:41
a product manager. We're talking about what mobile
5:43
app security actually means beyond basic scanning,
5:46
why it's different from backend and cloud security,
5:49
and how teams can improve posture. Without turning
5:52
CI/CD into a nightmare. Joel, thank you for joining
5:56
me. Hey, Brian, thank you. I appreciate being
5:58
invited onto the show. So I'm curious, why is
6:01
mobile different from backend and cloud? What
6:04
changes in the threat model? Fundamentally, it's
6:06
a shift in the trust model because... On the
6:10
backend and in cloud, you have relatively good
6:12
controls over the runtime environment, the servers,
6:16
the infrastructure, the policies that you put
6:18
in place. If you look at a mobile application,
6:20
you ship it. It's a public artifact at that point.
6:23
You completely lose control over what's happening
6:26
to that and how is it being used. So once it's
6:29
out the door, if you don't have reasonable levels
6:32
of protection into that application, it can be
6:36
used to read. Attackers can reverse engineer
6:38
that. You might be installed into an environment
6:41
on a phone that has malware that is going to
6:43
scrape that user's information. So there's risks
6:46
when you ship a mobile application to go. I wouldn't
6:49
say it goes beyond the backend. It basically
6:52
essentially opens up a different paradigm of
6:55
risk and a different trust model. So if you're
6:58
like a DevOps or SRE person, what's the simplest
7:00
way to think about it? So there's, I would. Think
7:04
about it in terms of integrating security into
7:08
your everyday life, into your build processes.
7:10
And there's a couple of different facets to that.
7:13
There's the scanning aspect, which you had mentioned.
7:16
Scanning is something you would do before you
7:18
release the application. That's sort of like
7:20
your background to make sure that. I don't have
7:23
any vulnerabilities. I understand my third party
7:26
dependencies. My coding practices, like literally
7:29
how I code something is not insecure and or improper.
7:32
So I could maybe have TLS improperly implemented.
7:36
Well, that's going out the door, right? So that's
7:39
sort of the, we do this in -house, we do this
7:42
before release. But then once you release those
7:45
type of things, those are more point in time
7:48
type of protections. Now you've done your due
7:51
diligence on. Prior to release. When it goes
7:53
out, you need to still be able to trust that
7:56
the applications and the users that are connecting
7:58
to your backend are using a genuine application.
8:01
It hasn't been compromised. And the integrity
8:04
of that app and the entire runtime execution
8:06
is good. That's the only way you could actually
8:08
sort of protect yourself. You need to be able
8:11
to trust it. And that's sort of the gap and the
8:14
challenge with a mobile app opposed to a backend
8:18
or a cloud service is that. That visibility is
8:20
lost. It's basically a public artifact at that
8:25
point. And you really don't know. You don't control
8:27
that environment. You don't know if it's going
8:29
to a malware environment. You don't know if it's
8:31
going to the hands of attackers. You don't know
8:33
what they're doing with it. That's the real fundamental
8:36
difference. I would call it a shift in trust.
8:39
And it's essentially centered around the control.
8:42
Is there common misconceptions that people have
8:45
about mobile app security? Does it just kind
8:48
of encompass what we just talked about or is
8:50
there? There's a handful of misconceptions. One
8:52
might be the actual scanning, like that scanning
8:55
is enough. If I, you know, use proper coding
8:59
practices and I check all my third-party libraries
9:02
and there's no vulnerabilities there and I do
9:04
a lot of dependency tracking, that you're done.
9:07
Or if you do that in combination with an app
9:10
store approval process that, okay, we're all
9:12
set. We really shouldn't need to consider security
9:15
at that point. That is a... A misconception because
9:18
of what i just explained um oh yeah i wanted
9:22
to bring up okay yeah and there's another misconception
9:24
about what if there's any sensitive information
9:27
in the actual application i have come across
9:30
a lot of people who say well we don't have anything
9:32
sensitive in our app we do all our protections
9:34
on the backend with our APIs. And that may be
9:38
true. They may not have a lot of sensitive information.
9:40
And if they code it right, they don't have a
9:41
lot of sensitive information. What they don't
9:43
understand generally is that an attacker doesn't
9:47
necessarily need to find the same things that
9:50
you might be worried about or think are a concern.
9:53
I would say almost any app that has business
9:56
-critical workflows transactions, logins, dealing
10:00
with money. I don't really care where the sensitive
10:03
information is stored. Something can be learned
10:05
from decompiling that application. And again,
10:08
this goes back to that trust and that lack of
10:10
visibility. You don't know what they're figuring
10:13
out from that application. That's why you proactively
10:17
harden that app with code hardening. And we call
10:22
it obfuscation to basically scramble up names
10:24
and things so that you can't reverse this and
10:26
really kind of quickly figure out the business
10:28
logic or what's going on with this application.
10:30
In addition to that, there is a requirement to
10:34
do runtime checks. And now those are basically
10:37
checks that can be injected into that application
10:41
that goes beyond just reverse engineering it.
10:45
into detecting whether or not something about
10:47
that environment or that runtime execution at
10:49
that exact moment is not right. There are certain
10:52
techniques, frameworks, and utilities that attackers
10:54
will use to maybe change a value, maybe bypass
10:58
something in the application, and those need
11:00
to be picked up because those are not necessarily
11:02
protected by code hardening. They help prevent
11:08
that from happening because it's harder to figure
11:10
out where I might want to go look, but... Those
11:13
things can still be attached to the application.
11:16
You could run it in a debugger, you could run
11:18
instrumentation. And then once you start doing
11:21
these things to say maybe hook a value, and what
11:24
a hook a value basically means is that in simplest
11:27
terms, if I'm depending on a particular variable
11:30
to come back to allow myself access to do something,
11:32
I could hook that variable and basically change
11:35
the value. So if I can't get in with a false
11:39
value, then maybe I'll hook it and I'll change
11:42
it to true. So there are a lot of threats and
11:45
risks that are in that mobile application beyond
11:50
we have no sensitive keys in there or something
11:53
like that. It's not just the PII from customers.
11:57
It's not. It's not. I mean, there are probably
11:59
apps out there that aren't worth protecting,
12:01
but that's fine. They'll probably know. But I
12:03
have heard that narrative, which is a big misconception
12:07
from people. That work at places that i know
12:10
for fact are dealing with logins transactions
12:13
money so that is a dangerous misconception is
12:18
there a different con security concern between
12:20
android android ios windows and like what are
12:23
those if there are I wouldn't say there are different
12:26
concerns. The landscape, the ecosystem is a little
12:29
bit different. The same type of attacks can be
12:31
carried out on both platforms. The same risks
12:34
are there. The ecosystem in Android is a little
12:37
bit different because it's a little less controlled
12:40
as far as the number of devices that are floating
12:43
around in the world, the number of operating
12:45
systems that are still in support. And it is
12:47
an open source model, but it... That is a misconception
12:50
as well. There's a misconception out there that
12:53
because iOS is closed source and Android is open
12:56
source that all the problems happen there. There's
12:59
probably a degree of people, their impression
13:02
of that being skewed by the fact once you get
13:05
outside of like the United States and Europe,
13:07
almost everybody's using Android phones and they're
13:09
using older ones. So worldwide, the distribution,
13:14
not everybody is walking around with $1,000.
13:16
iPhone in some parts of the world. So essentially,
13:19
same attacks. You can attack iOS in the same
13:23
ways that you attack Android. The difference
13:25
is that that ecosystem is a little bit different
13:28
and there's many more devices out there that
13:30
are Android. So what do you think teams assume
13:33
the OS is protecting them from that maybe it
13:35
isn't? Well, it's definitely not protecting them
13:38
from somebody reverse engineering the application.
13:42
or trying to figure out how they're going to
13:44
bypass their certificate in that application,
13:46
or it's not going to tell you that another app
13:50
was downloaded that is malicious and it's going
13:53
to have a screen overlay, or it's going to abuse
13:55
accessibility services on your application. The
13:59
operating system... Has implicit security, but
14:03
it's a different focus. This is a different paradigm.
14:05
It's not, it's concerned. It has some security
14:08
measures for the actual device and the operating
14:10
system itself, but it's not specifically concerned
14:12
with the application or what else is running
14:15
on there. It would be incorrect. Assumption that
14:19
the operating system is going to keep me safe.
14:21
It's like anything in security. You're making
14:23
an incorrect assumption if you think anybody
14:25
else is going to take care of your problems,
14:28
essentially. It's not the App Stores in their
14:30
approval process that's going to save you. It's
14:34
not the operating system that's going to save
14:36
you. It's not your scans that you run ahead of
14:39
time to make sure that your dependencies have
14:41
no vulnerabilities and you're coding well. The
14:43
only thing that's going to really save you is
14:45
to... Have a reasonable level of trust that that
14:48
application that's connecting to your APIs is
14:51
genuine and it's not compromised, meaning it
14:54
hasn't been modified. It's not a fake app. That's
14:57
the only way to have any level of comfort that
15:00
you've done what you need to do from that angle.
15:03
And it makes a lot of sense if you think about
15:04
it. In this day and age, you would not ignore
15:08
some part of your system. And these are, let's
15:11
face it, those are mobile apps are not apps.
15:14
They're payment platforms. They're banking platforms,
15:17
they're medical device managers, they're retail,
15:20
streaming, entertainment platforms, heavily monetized
15:25
by these companies. I know it has outpaced
15:29
the web as far as where people spend their time
15:33
and handle workflows and transactions. So if
15:36
you look at it from the business perspective,
15:38
these are critical to these organizations, large
15:41
and small, and those are critical workflows.
15:43
And there is something to be learned from that
15:45
application, even if it is not sensitive to data
15:48
floating in it. Yeah, for sure. And so we kind
15:51
of talked a little bit about scanning. Teams
15:53
love to say that we scanned it or we do scan
15:55
it. Why is that not enough for mobile? I think
15:57
so. The way I kind of explained it a little bit
16:00
earlier is that scanning is going to tell you
16:02
something about how you might be coding that
16:05
application or the way you're implementing certain
16:08
inherent security measures like secure communications
16:12
and TLS. If you scan the application, it might
16:15
say, well, it's probably not a great idea to
16:17
have this secret. Floating around in your application.
16:21
So, okay, I'll take the secret out. Or my TLS
16:24
is improperly configured, so it's actually not
16:26
doing what it's supposed to do. Scanning can
16:28
check for your vulnerabilities in third-party
16:30
libraries. So you're doing your due diligence
16:33
to, it's like kind of taking care of the basics,
16:36
to be honest with you. And those things do not
16:39
actively or explicitly protect that application
16:43
from what an attacker is going to do to that
16:45
application as far as decompile it. Start picking
16:48
away at it. Figure out exactly where the sensitive
16:51
parts, the sensitive workflows of that application
16:53
engage with your backend, essentially. You have
16:56
to do both, essentially. And that's where it
16:59
comes back to, like, it's not a narrow scope.
17:02
It's not as narrow a scope as just running a
17:06
scanner. That's too narrow of a scope. And it's
17:08
ignoring all the other implications and inherent
17:11
behavior within an application. And it's not
17:14
protecting you specifically. From what the attacker
17:17
is going to do. The attackers now are much more
17:19
organized and much more financially motivated
17:23
than we saw even like 10 years ago. And just
17:26
like everything else, they have at their disposal
17:28
a large number of pretty advanced frameworks
17:32
and tooling to actually help them do this faster.
17:36
It's a bit of an arms race in that regard because
17:39
we can't control. The things that are out there
17:42
that they're going to be able to use, but all
17:44
those things that are out there help them carry
17:46
off these specific attacks and also speeds up
17:49
their time so that they can sort of industrialize
17:52
the entire thing. Whereas maybe 10 years ago,
17:54
it would have been somebody taking a look at
17:56
this manually, decompiling it and playing around
17:59
and maybe spending a week, a week and a half
18:01
trying to figure out what's going on. Now these
18:03
advanced frameworks and utilities are out there
18:05
that speed that up very quickly. I'm guessing
18:08
AI is probably also impacted. Like the time for
18:11
CVEs and impacts and security vulnerabilities?
18:14
Have you noticed like an acceleration over the
18:16
last like year or so? We, so there's undeniably
18:20
a bit of a paradigm shift there in the sense
18:23
that attackers are going to be looking and using
18:25
AI assistance. And what that will do is essentially
18:28
speed up the time it takes for them to figure
18:30
out. The logic and figure out what they want
18:32
to go after. We have not seen an increase in our
18:36
customer base being attacked as a result because
18:38
our fundamental principles that we have in place
18:41
are actually the right ones from the beginning
18:43
prior to the explosion in AI here. And it's going
18:47
to be true really. In many different paradigms,
18:52
but especially in the attacker and the defender
18:54
space, the AI assistance is going to speed up
18:56
the attacker. If the defender was not in the
19:00
right place or not using the right approach to
19:02
begin with, then they're going to be in a little
19:05
bit more trouble than someone who has the right
19:08
fundamental principles in place and multiple
19:10
layers of... Reverse engineering static reverse
19:13
engineering very resilient runtime checks and
19:16
even a service to basically validate that your
19:19
application that's connecting to your apis is
19:22
a genuine non-compromised uncompromised app
19:25
so yeah it changes the game a little bit but
19:28
it does not fundamentally change it it gives
19:32
them some tools it gives everybody some it gives
19:34
everybody some tools so I was reading on
19:38
Guardsquare. Can you like explain the layers
19:40
to me? Kind of touched on a little bit. There's
19:42
testing, hardening, runtime protection, and monitoring.
19:45
How does that work as like one cohesive strategy?
19:48
Yeah, so the testing is like the scanning aspect,
19:51
which would look for the vulnerabilities, insecure
19:53
practices, insecure coding practices, improper
19:56
implementations. The hardening is our core product
19:58
set, which is the decompiler-based or a compiler
20:03
-based approach to adding protections. Into that
20:06
application. So we'll take the output IPA or
20:10
APK, depending upon the platform, decompile that,
20:13
add the code hardening and obfuscation to basically
20:17
make that decompiled code look like gibberish
20:20
to somebody, and also inject what I was referring
20:24
to as runtime checks. So, for example, is this
20:28
device rooted or is someone attaching a hooking
20:31
framework? Has somebody gotten around the actual
20:33
certificate? Or is there malware on the device
20:38
that's trying to abuse accessibility services
20:40
or using overlay or a screen reader to scrape
20:44
information? So that's the hardening aspect.
20:46
And then the monitoring aspect is another important
20:49
part of this broader picture, which is, I spoke
20:52
about this earlier, where that whole trust model,
20:55
that lack of visibility. Even if you are protected,
20:57
you still want to monitor what's going on because
20:59
things shift. You might see all of a sudden evidence
21:02
of certain behavior in a certain part of the
21:05
world. So maybe you want to pause for a second
21:08
and be like, hmm, do we want to change our configuration,
21:11
release a new application, maybe improve some
21:15
of the protections here? Like what's going on?
21:17
So it's not just, you can't just add your protections
21:19
and just, I'm done. I'm good. You should probably.
21:22
You should be monitoring that and essentially
21:25
allow yourself the flexibility to change your
21:27
posture as needed, essentially. So, OK, keeping
21:30
the like CI/CD framing, we talked about the runtime
21:33
protection, the obfuscation. Does that create
21:36
any like or what is the build overhead from that?
21:39
And does that slow builds down? How do you keep
21:41
security checks from like killing the velocity
21:43
of like normal app development? That's a good
21:45
question. I mean, that's always a concern in
21:48
any paradigm of security, no matter what it is,
21:50
because. It doesn't come for free. Like you,
21:53
if you're going to do it correctly, but there's
21:55
always a line between protection and usability.
21:57
You don't want to, you know, put a motor on your
21:59
house and a drawbridge because you're going to
22:01
end up leaving the drawbridge down because you
22:04
really don't want to wait for all that time for
22:07
it to go up. So yeah, there's always a trade
22:09
-off there where you have to monitor and take
22:11
care of the constraints. So you want to protect
22:14
as much as you can without infringing upon your
22:16
constraints. People might have constraints about
22:18
the size of their application. They might have
22:20
specific performance constraints. And these things
22:23
will always sort of shine brighter than the protection
22:27
because the fundamental job of all these teams
22:31
is to release this application with features
22:34
that drive business and bring in revenue and
22:35
they can monetize their services. So there is
22:38
a balancing act. It's a unavoidable balancing
22:40
act. But if your vendor has the right tooling
22:44
and options and features, it shouldn't be a pain
22:48
that's not worth, you know, accepting or a penalty
22:51
that's not worth accepting. Yeah, it's a fundamental
22:55
part of adding protections. But if you go about
22:58
those protections in the right way and use the
23:00
right tooling and understand what you're trying
23:02
to protect, it should be a minimal impact to
23:05
your delivery process. So, okay, with that in
23:08
mind, what would like a good or a sane gating
23:11
strategy look like? Like what would block a release
23:13
versus what becomes tracked risk for down the
23:16
road? As far as testing the application is concerned?
23:19
Yeah, or vulnerability tracking or whatever.
23:22
Like how does that impact the CI/CD work? Depending
23:26
upon the severity of the vulnerability or the
23:28
insecure coding practices, it could be a high
23:32
risk thing that should be mitigated immediately.
23:35
But a lot of scanning tools will also surface
23:38
maybe medium or low risk things that you can
23:41
just kind of track and be like, okay, I'm going
23:42
to put that on my wishlist. And next time around,
23:45
you know, we're not going to block the release
23:46
over this because it's not severe. It's not a
23:48
high risk situation. And then the lower ones,
23:50
you can basically make a list. That's what people
23:53
do. And then sort of when they have time, pluck
23:55
away at a few of those because those are not
23:57
critical, critical risks. From the testing standpoint
24:01
of a protected application, going back to The
24:04
usability, it cannot impact the usability and
24:07
whatever those constraints might be. So it has
24:09
to be protected and then verified by the QA team
24:13
that, okay, we're still within the constraints
24:15
of acceptability. And then if it's not, maybe
24:18
there's a change to the configuration or maybe
24:20
you're being too aggressive. On certain aspects
24:22
of the protection, in which case you can change
24:25
your posture there and dial it down. If you don't
24:27
have evidence of past attacks, you're not going
24:29
into a high risk, a really high risk known malicious
24:32
situation, maybe you could gamble a little bit
24:35
and take a step back on doubling down on those
24:38
protections for the sake of that usability. But
24:41
there is a sweet spot, really. I mean, essentially,
24:44
you know, you don't want to, I probably didn't
24:45
give the best advice there. You really don't
24:47
want to look at it that way. You want the sweet
24:49
spot, which is. I'm reasonably well protected
24:52
against all of these things with minimal to no
24:55
impact in the usability. Certain things are acceptable
24:58
as far as impact. Certain things are not. It's
25:02
not acceptable to cause a stability issue, but
25:04
it might be acceptable to lose a couple milliseconds
25:07
on a particular transaction or some sort of a
25:11
method or something for the sake of the assurance
25:14
that it's now secured, right? So it's a bit of
25:17
a trade-off there. What's important to you from
25:20
a protection standpoint, and also what is important
25:24
or critical on the constraint side. But those
25:27
are essentially the only things that would really
25:28
just like stop the release. Like I have high
25:30
severity, critical things that need to be fixed.
25:33
And that comes down to the policies, the internal
25:35
policies, compliance policies, and governance
25:37
of that organization, that they make a rule that,
25:40
and they should make a rule that there's a high
25:42
severity finding and scanning. It's a stop the
25:44
press thing. And usually those things shouldn't
25:47
be too difficult to fix. And then as far as protections,
25:51
you know, it's just like any release cycle. You
25:54
add it, even if it's not a protection, you still
25:56
have to test your application. So when you integrate
25:59
the protection into your CI/CD, it's not like
26:02
you're going down a different path. You're essentially
26:03
just running it through your system tests and
26:06
your QA team with the protections. So if you're
26:09
an engineering team and you're trying to improve
26:11
mobile app security posture today, is there like
26:13
a top three or top five things that you would start
26:16
with? Yeah, I would say not to get overwhelmed.
26:19
I would take a step back and start asking
26:22
some really basic questions. What matters to
26:24
us? How is this app interacting with our backend?
26:27
How could this, what could possibly hurt us?
26:29
Like start brainstorming around that and then
26:31
consider a structured programmatic approach to
26:35
layering in your security essentially so that
26:38
it becomes part of your routine. Can't be an
26:42
after the fact type of thing. You should be thinking
26:44
about it up front, during, and obviously at release
26:48
and after release. So it's a bit of a mindset.
26:52
If you treat it as a checklist type of thing
26:55
at the very tail end, that's where you usually
26:58
get yourself maybe into some trouble because
27:00
you either didn't protect it well enough or you
27:03
did it in a way that... Might risk some of your
27:06
constraints. So it's a mindset that security
27:09
is top of mind across all facets all the time.
27:12
And if it's part of your daily routine, just
27:15
like exercising or something, if you make it
27:17
a habit, you're going to do it all the time.
27:19
If you're considering security as being important,
27:22
as you should, it just becomes, it's an adoption
27:25
and understanding that this is part of life.
27:27
And it's the right way to go about it because
27:29
you'd rather not be. In the news because someone
27:33
made an example of your application or some of
27:35
your users were victims of fraud or even your
27:38
organization was part of some sort of criminal
27:41
misuse situation, which does happen. Yeah. So
27:44
kind of thinking of the inverse in that, is there
27:47
anything that you would kind of throw out as
27:49
security posture that maybe companies are doing
27:52
that maybe they shouldn't be? It's kind of not
27:54
effective, not really providing value from a
27:56
security perspective. I mean, the worst thing
27:59
they could possibly do is the scenario we were
28:01
talking about earlier, which was basically just
28:03
assuming that some level of scanning is enough
28:06
and App Store acceptance is sufficient. As far
28:10
as other things, I think people probably are
28:13
not generally aware enough of the ways attackers
28:17
go about reverse engineering applications. So
28:19
it's hard for them. Maybe it's probably more
28:21
a situation of... Misunderstanding or like not
28:24
being knowledgeable enough. If you don't know
28:26
about something, you have no idea the importance
28:29
of code hardening or changing names, then you're
28:33
probably not going to value it at all. So I don't
28:36
know if that answers your question or not, but
28:37
I would certainly, and there's plenty of information
28:40
and knowledge out there. You can go to our website.
28:43
There's organizations like OWASP that have lots
28:47
of guidance around. What is needed to properly
28:50
secure a mobile application. And I would recommend
28:54
that highly because it's really like anything
28:56
else. If you don't really know what you're doing
28:59
or you don't really understand the fundamentals,
29:02
like you're probably not going to be doing this
29:03
or you're probably not going to pick the right
29:04
vendor. You're probably not going to use that
29:06
vendor the right way. Yeah, it's an education
29:08
thing. Awesome. So where can people find more
29:12
about you, about Guardsquare? So www.guardsquare
29:17
.com, we have a wealth of knowledge on there,
29:19
like resources and blogs. And they're not just,
29:22
you know, for lack of a better word, marketing
29:24
fluff. They're written by security research analysts
29:27
that work for us. And they'll give you a broad
29:30
and, if you want, a deep level understanding
29:33
of the protections that are needed and the techniques
29:37
that are attacks attackers are essentially using.
29:40
We also have a security research center on the
29:43
website. So there's a lot of research. There's
29:44
a lot of resources and papers to get a basic
29:47
knowledge and a good understanding of what you
29:50
might need to do to properly secure your mobile
29:52
application. Cool. Awesome. I'll put links up
29:55
for Guardsquare's blog, OWASP, and some of the
29:58
other things that we talked about in the show
30:00
notes. Sure. Joel, thank you so much for coming
30:02
on. Really appreciate it. Appreciate it, Brian.
30:04
You're welcome. Thank you. All right. That was
30:06
my conversation with Joel DeStefano from Guardsquare.
30:09
My biggest takeaway from this one is that mobile
30:12
security is really about the trust boundary moving.
30:15
In backend and cloud systems, we spend a lot
30:18
of time trying to control the environment. We
30:20
harden infrastructure. We manage IAM. We monitor
30:24
runtime behavior. We control deployments. We
30:28
log everything we can. We build policies and
30:31
guardrails and assume that if something weird
30:33
happens, we at least have some visibility into
30:36
the system. With mobile, that changes. You ship
30:39
the app, and now the app is out in the world.
30:42
And once it is out there, attackers can study
30:45
it on their own time. They can decompile it.
30:48
They can instrument it. They can run it in weird
30:51
environments. They can try to bypass checks,
30:54
hook values. Scrape information, or learn enough
30:58
about the workflow to abuse the backend in ways
31:01
the backend team may not have expected. That
31:04
is the part I think is worth paying attention
31:07
to. A lot of teams treat mobile security like
31:10
a scanning problem. Run the scanner. Fix the
31:13
dependencies. Fix the obvious insecure coding
31:15
patterns. Make sure there are no secrets sitting
31:18
in the app. Pass the App Store review. Ship it.
31:22
And to be clear, that work matters. But it is
31:25
not the whole story. Scanning tells you something
31:27
useful before release. It helps you catch problems
31:30
in code, dependencies, configuration, and implementation.
31:35
But it does not protect the app once someone
31:38
is actively trying to reverse engineer it or
31:40
tamper with it in the wild. That is where the
31:43
layered approach matters. Testing matters. Hardening
31:46
matters. Runtime protection matters. Monitoring
31:50
matters. And honestly, the monitoring part is
31:53
easy to underappreciate. Because even if you
31:56
do the right things before release, the threat
31:59
landscape changes after release. Attackers change
32:02
tactics. Activity spikes in certain regions.
32:05
New tools get popular. Something starts showing
32:08
up in the field that you did not plan for. If
32:11
you are not watching that, you are basically
32:13
guessing. I also liked Joel's point that we do
32:17
not have sensitive data in the app is not the
32:19
same as the app does not need protection. That
32:22
is a trap. A mobile app does not need to contain
32:25
a database full of customer PII to matter. If
32:29
it handles login, payments, banking, medical
32:33
workflows, retail transactions, subscriptions,
32:37
account recovery, loyalty points, streaming access,
32:41
or any business-critical path, then there is
32:44
something useful for an attacker to learn. The
32:47
sensitive thing may not be a secret string. It
32:50
might be the workflow. It might be the trust
32:53
relationship. It might be how the app talks to
32:56
the backend. It might be the condition an attacker
32:59
needs to bypass to make the backend believe something
33:02
it should not believe. That is a different way
33:05
of thinking about the app. Not just what data
33:08
is stored here, more like what can someone learn
33:11
from this app and how could they use that knowledge
33:14
against the system? The CI/CD part matters too,
33:18
because security teams can say protect everything
33:21
all day long. But if the protection adds too
33:24
much pain, slows builds too much, creates unstable
33:28
releases or turns every app update into a fight,
33:32
engineering teams will find a way around it.
33:35
So the goal has to be sane integration. High
33:39
severity findings should block. Critical issues
33:42
should stop the release. But lower severity findings
33:46
may become tracked risk. Runtime protections
33:49
need to be tested like any other release change.
33:53
Performance and stability constraints still matter.
33:56
There is always a trade-off between protection
33:59
and usability. That does not mean avoid security.
34:02
It means design it like it has to live inside
34:05
a real delivery process. Because it does. The
34:09
other thing that stood out is the AI angle. AI
34:12
may make attackers faster. It may help them understand
34:15
logic faster. It may help them reverse engineer
34:18
or reason about code faster. But Joel's point
34:21
was that the fundamentals do not disappear. If
34:24
you already have the right layers in place, AI
34:27
does not completely rewrite the model. It increases
34:30
speed. It gives attackers better tools. It raises
34:34
the pressure. But the principles still matter.
34:37
Know what matters in the app. Protect the app.
34:40
Make reverse engineering harder. Add runtime
34:43
checks. Validate that the app connecting to your
34:46
backend is genuine. Monitor what is happening
34:49
in the wild. And do not assume that the OS, the
34:53
App Store, or one scan in the pipeline is going
34:56
to save you. That is probably where I would land
34:59
with this whole conversation. Mobile security
35:01
is not magic. It is also not just scan it and
35:05
ship it. It is a different trust model and teams
35:08
need to treat it that way. I'll have links to
35:11
Joel, Guardsquare, OWASP mobile resources, and
35:15
anything else we mentioned in the show notes.
35:17
If you enjoyed this conversation, follow or subscribe
35:20
to Ship It Weekly wherever you listen to podcasts.
35:24
It helps the show and it makes sure that you
35:26
get both these conversation episodes and the
35:29
weekly DevOps. SRE, Platform, Cloud, and Security
35:33
News Recaps. You can also find the show notes
35:36
and links over at shipitweekly.fm. Thanks for
35:39
listening, and I'll see you later this week.
Ship It Conversations: Guardsquare’s Joel DeStefano on Mobile…
0:00 / 35:58
🎧 Listen & Subscribe
Catch This Episode
Listen on your favorite podcast platform
💬 Commentary
Host Commentary
📝 Notes
Show Notes
This is a guest conversation episode of Ship It Weekly, separate from the weekly news recaps.
In this Ship It: Conversations episode, I talk with Joel DeStefano from Guardsquare about mobile app security, why it is different from backend and cloud security, and why scanning alone is not enough once an app is shipped into the real world.
We talk about the shift in trust model that happens with mobile apps. In backend and cloud systems, teams usually have more control over the runtime, infrastructure, policies, and monitoring. With mobile, the app becomes a public artifact running on someone else’s device, in an environment you do not fully control.
The bigger theme here is that mobile security is not just “scan it before release.” Scanning matters, but teams also need to think about app hardening, obfuscation, runtime protection, monitoring, and whether the app connecting back to their APIs is genuine and uncompromised.
Highlights
• Why mobile changes the trust model compared to backend and cloud systems
• What DevOps, SRE, and platform teams should understand about mobile app risk
• Why scanning is useful, but not enough by itself
• The danger of assuming app store approval means an app is secure
• Why “we do not store sensitive data in the app” can be a misleading security argument
• How attackers can reverse engineer apps, inspect workflows, and learn how the app talks to backend APIs
• What code hardening and obfuscation actually help protect against
• Why runtime checks matter for rooted devices, compromised environments, debuggers, hooking frameworks, overlays, and accessibility abuse
• The difference between Android and iOS security assumptions
• Why the OS is not responsible for protecting your app’s business logic
• How mobile security should fit into CI/CD without destroying release velocity
• What should block a release versus what should become tracked risk
• Why testing, hardening, runtime protection, and monitoring should work together as one strategy
• How AI may speed up attackers without fundamentally changing the need for strong security fundamentals
• Joel’s advice for improving mobile security posture: start with the app’s critical workflows, backend interactions, and real business risk
Joel / Guardsquare links
• Guardsquare: https://hubs.ly/Q04fJgkJ0
• Guardsquare Blog: https://www.guardsquare.com/blog
OWASP mobile security links
• OWASP Mobile Application Security: https://owasp.org/www-project-mobile-app-security/
• OWASP MASVS: https://mas.owasp.org/MASVS/
Our links
More episodes + show notes + links: https://shipitweekly.fm
On Call Brief: https://oncallbrief.com
👤 Guest
Guardsquare’s Joel DeStefano
📍 Made in Greencastle, Pennsylvania
More from Ship It Weekly
All episodes →
Ship It Conversations: Meta’s Francois Richard on AI Incident Response, SLOs, and Reliability at Scale
In this episode, Francois Richard from Meta discusses the evolving landscape of reliability at scale, particularly with AI's impact on production risks. He emphasizes the importance of recovery practices alongside prevention, and how SLOs should reflect a commitment to users.
Coinbase Outage, Meta AI Account Recovery, AWS AgentCore Code Injection, Apigee Tenant Isolation, and the Glue That Breaks Production
This episode of Ship It Weekly discusses critical infrastructure failures and their implications. Brian analyzes Coinbase's outage due to an AWS cooling failure, Meta's AI-driven account recovery issues, and vulnerabilities in AWS AgentCore and Google Apigee.
Kiro CLI Approval Bypass, Amazon Braket Pickle Risk, AWS Org Logging, KEDA Upgrades, and Automation’s Hidden Boundaries
This episode of Ship It Weekly explores automation's hidden boundaries, focusing on Kiro CLI's CVE-2026-9255 approval bypass and Amazon Braket's Python pickle risk.
GitHub Supply Chain Attacks, Railway’s GCP Outage, Discord’s Voice Failure, AWS Retry Changes, and Trusted Tool Risk
This episode of Ship It Weekly discusses the growing risks of trusted tools in production, highlighted by a GitHub supply chain attack involving a compromised VS Code extension.
For this Conversations episode, the part that stuck with me is how easy it is for backend and cloud people to bring the wrong mental model to mobile security.
In backend systems, we are used to control.
We control the runtime. We control the infrastructure. We control IAM. We control the network path. We control the deployment process. We control observability, logging, and a lot of the runtime environment around the application.
Mobile changes that.
You ship the app and now it is out there.
It is running on someone else’s device, in someone else’s environment, with software you do not control, under conditions you may never see directly. Maybe the device is rooted. Maybe it is jailbroken. Maybe there is malware nearby. Maybe someone is decompiling the app, running instrumentation, hooking values, bypassing checks, or trying to understand enough of the workflow to abuse the backend.
That is the trust shift Joel DeStefano kept coming back to in this conversation.
Mobile app security is not just “did we scan the app before release?”
Scanning matters. Dependency checks matter. TLS configuration matters. Not shipping secrets in the app matters. All of that is table stakes.
But it is point-in-time assurance.
It tells you something before release.
It does not tell you what happens after the app leaves the pipeline.
That is where I think a lot of teams get too comfortable. They assume the App Store review process is handling more than it is. They assume the OS is protecting the application logic. They assume that because the backend stores the sensitive data, the mobile app itself is not an interesting target.
That last one is probably the most dangerous assumption.
The sensitive thing is not always a secret string sitting in the app.
Sometimes the sensitive thing is the workflow.
How does the app authenticate? How does it talk to the backend? What does the backend trust? What values does the app send? What checks happen locally? What behavior changes when a condition flips from false to true?
If an attacker can learn the business logic, they may not need a database dump from the app. They may only need enough understanding to abuse the system around it.
That is especially true for apps tied to money, login, account recovery, medical workflows, retail transactions, subscriptions, loyalty points, streaming access, or anything else that represents real business value.
So the better question is not just, “Do we have secrets in the app?”
The better question is, “What can someone learn from this app, and how could they use that against us?”
That is a much more useful way to think about mobile security.
I also liked how Joel framed the layered approach.
Testing matters.
Hardening matters.
Runtime protection matters.
Monitoring matters.
Those are not interchangeable pieces. They solve different parts of the problem.
Testing and scanning help catch issues before release. Hardening and obfuscation make reverse engineering harder. Runtime checks help detect suspicious environments, debuggers, hooking frameworks, rooted devices, overlays, accessibility abuse, and other signs that something about the app execution is not right. Monitoring helps teams understand what is actually happening after the app is in the wild.
That monitoring piece is important because the threat landscape does not freeze when you ship.
Attackers change tools. Tactics change. Activity spikes in different regions. A new framework gets popular. A workflow starts being abused in a way nobody expected.
If you are not watching, you are guessing.
That does not mean every app needs the same level of protection. A tiny internal utility is not the same as a banking app, a healthcare app, or a payment flow. But a lot more apps are business-critical than people admit.
Mobile apps are not just “apps” anymore.
They are storefronts. Payment platforms. Account portals. Medical device managers. Subscription systems. Streaming platforms. Banking experiences. Identity and recovery paths.
If that is where users spend time and money, attackers will spend time there too.
The CI/CD part of this conversation is also worth paying attention to.
Security that destroys the release process usually does not last.
That is true in cloud. It is true in platform engineering. It is true in mobile too.
If the security tooling slows everything down, breaks builds constantly, creates stability issues, or forces teams into a painful release process, engineering teams will eventually route around it. Maybe not officially. Maybe not loudly. But they will find a way to keep shipping.
So the goal has to be security that lives inside the real delivery process.
High-severity findings should block. Critical issues should stop the release. But lower-severity issues may become tracked risk. Runtime protections still need QA. Performance constraints still matter. Stability matters. App size can matter. A few milliseconds might be acceptable. A crash is not.
That is the tradeoff.
Not “security versus shipping.”
More like, “how do we make security part of shipping without pretending delivery constraints do not exist?”
That is a healthier conversation for DevOps, SRE, platform, AppSec, and mobile teams to have together.
I also thought the AI angle was interesting because it fits the broader theme we keep seeing across security.
AI may make attackers faster.
It may help them understand app logic faster. It may help them reason about code faster. It may help them reverse engineer faster. It may compress the time between “I have this app” and “I understand where to poke.”
But Joel’s point was that the fundamentals do not disappear.
If you already have the right model, AI increases pressure.
If you do not have the right model, AI makes the gap more painful.
That seems broadly true across security right now. AI is not replacing the need for good fundamentals. It is raising the cost of not having them.
For mobile, those fundamentals look like understanding the trust model, protecting the app, making reverse engineering harder, adding runtime checks, validating that the app connecting to your backend is genuine, and monitoring what is happening in the field.
The biggest mistake is assuming someone else has solved the problem for you.
The App Store will not save you.
The OS will not save your business logic.
A scanner will not protect runtime behavior.
And “we do not store sensitive data in the app” does not mean the app has nothing valuable to reveal.
That is probably my main takeaway from this episode.
Mobile app security is not magic, but it is different.
It is a different trust boundary. It is a different runtime model. It is a different visibility problem. And it needs to be treated as part of the system, not as a separate thing that gets checked at the end.
Because once the app is shipped, the question is not just whether you built it safely.
The question is whether you can still trust what is connecting back.