Mobile apps have become a primary interface for critical services, including banking, payments, and healthcare. Unlike web applications, much of the logic and intellectual property in a mobile app lives directly on the user's device, which is an environment the developer doesn't control. That makes mobile apps uniquely exposed to reverse engineering, runtime manipulation, and fraud. As more critical functionality shifts to mobile, the need to harden apps against sophisticated attackers continues to grow.
Guard Square builds tools to protect and test mobile applications against both static and dynamic threats. Its platform has features including layered code obfuscation, runtime application self-protection, mobile specific security testing, threat monitoring, and API attestation. Ryan Lloyd is the Chief Product Officer at Guard Square. In this episode, he joins Gregorvan to discuss why mobile security differs from desktop and web security, however, reverse engineering tools have evolved, the role of compiler-based obfuscation and runtime protections, common mobile app vulnerabilities, and how LLMs are reshaping the attacker landscape.
Gregorvan is a security-focused technologist, having previously been a CTO across cybersecurity, cyber insurance, and general software engineering companies. He is based in Singapore and can be found via his profile at van.hk or on LinkedIn. Hello, and welcome to Software Engineering Daily. My guest today is Ryan Lloyd.
Hi there, great to be here. Yeah, great to have you here, Ryan. So, you're the Chief Product Officer of Guard Square. We're going to be hearing all about Guard Square through the episode and everything, and what about app security, and not a topic that we've covered in much depth before, so this is going to be an interesting one.
But as we like to do on SE Daily, just what was your path to Guard Square, I guess, and becoming the CPO at Guard Square? Yeah, so for 20, 25 years now, I've been working for a series of companies that provide software developer tools. So in early 2000, I started with a company that built version control and issue tracking software, predating Git and Jira and those kinds of things, and then eventually moved into a company called SmartBear, where we focused on software test automation and quality assurance tools. And then more recently, I spent a bit of time at a company called Veracode, which was my first foray into the world of security and application security specifically, which has a lot of similarities to automated testing, scanning apps to find vulnerabilities is not that different than testing apps to find bugs and defects.
And then the last five years, I've been here at Guard Square. So throughout my journey, I've been focused on product management and really on tools for developers, and then more recently around security. And now here at Guard Square, it's all about mobile app security, so an even more narrow and specialized space within security, but all about focusing on our customers who are app developers and supporting them in how they secure their mobile applications. So then I guess Guard Square as a company was the origin story there.
Yeah, it's an interesting one. So the original founder of the company started an open source project called ProGuard, and that open source project was initially focused on optimizing and shrinking Java applications, just making it smaller and more efficient, things like that. And eventually it became a really popular tool for Android developers to shrink and optimize Android apps. So it became so popular, it became bundled into the Google developer toolkit as a default.
And the interesting thing was in shrinking and optimizing applications, it would decompile the binary, and then it would apply these transformations to the code to shorten all the names and references to illegible names that just took up less characters. And if you do this enough times through a whole binary, eventually you shrink it down much smaller, and then we did some optimization passes to make the apps start up faster. So that was kind of the way the company got started. And then what we noticed is some people were starting to use this tool ProGuard because of this feature of renaming all the names for security purposes.
They thought, well, if it makes the code less legible, that's a security benefit. And once we started recognizing that this was a recurring and common pattern, we decided to pull on that thread further, and we created a parallel tool called DEXGuard, which applied this and many other concepts to obfuscate and secure mobile application code. And that all took place around 2014 when the company was formalized and incorporated and moved out of just being an open source tool to a formal company. And since then we've just done a journey to add more capabilities and tools and sophisticated functionality to help companies that are trying to secure mobile apps.
Yeah. I mean, we're also going to get into the kind of the technicals of what the product does, and I guess how it does as well. But maybe just to set the scene, like what's the typical size of company or any names of obvious customers, I guess, just sort of what's the kind of scale here of how it's been used? Yeah.
So we have around 1,000 paying customers, and they're protecting apps across a range of industries. So around 40% of our customers are in the finance vertical, right? So mobile banking applications, FinTech, card payment, SDKs, and software, crypto apps, things of that nature. That's around 40% of our customers.
And then we have a long tail of customers across quite a wide variety of industries. I mean, you think of mobile apps these days, and they do just about everything. So we've got customers that have mobile games that they try and protect from cheating. We've got streaming media platforms that are trying to make sure that the digital rights kind of protections they have built into the application are secure and can't be bypassed for content to be stolen and infringed upon.
Healthcare has been a big developing area for us recently as well. So a lot of apps where there's a mobile app that is a companion to a physical medical device. Think about diabetes and insulin care, things like that. Yeah.
So we're going to get into like what this is effectively. And also to kind of clarify, because we're going to be talking a lot about just simply mobile application. Are we also talking about iPads as well, for example? Yeah.
So when we talk about mobile, we talk about Android and iOS. So that includes different form factors, also the TV elements of those platforms. Yeah. So that leads into, I guess, literally one of my first questions when I was thinking about this was, well, how did this differ from desktop effectively?
We've had desktop binaries since not the dawn of time, but the dawn of consumer computing. And when they come to mobile across these form factors, they've just talked about like, these are just binaries, right? But there's way more to it than that. And I think that's kind of where it would be interesting to start, like, what really sets apart the mobile landscape from this perspective?
What are the things that guards are going to need to be looking at? Yeah. So mobile apps are fundamentally reverse engineering. And tampering them is not much different than the practices and patterns that apply on desktop applications.
I think the biggest fundamental difference is the purpose and the value of mobile apps is fundamentally different, right? Like you've never installed a banking app on a desktop computer. Sure, you've accessed it maybe through a web browser, but all of the IP and the logic lives on a server that's well protected and secured. But a banking app for mobile, a lot of that IP and logic is built into an app that's on the end user's device, where they can tamper with the environment, tamper with the code, and manipulate its behaviors.
And that extends beyond banking, of course. But I think the value and the stakes are just much higher with mobile apps. The biggest parallel we've seen with desktop apps is maybe our gaming customers. Anti-cheating and cheating protections have been something that they've invested heavily on on the desktop side, and similar on the mobile side.
And maybe some paid enterprise software apps, where piracy and things are concerned would have parallels between desktop and mobile. But there are a lot of consumer apps on mobile that never really existed in the desktop world. So it brings into focus the different security considerations and attack paradigms. And like a desktop, the thing with mobile is what makes it different than a web application is the end user has so much control over the hardware, the device, and lots of tools at their disposal to manipulate and modify and tamper with it.
And thinking about, as you were talking about, how users use their mobile devices, and it's very common these days for BYOD bring your own device to a company. So a company is having to, there are also many ways to protect against this. But ultimately, a user is running apps on a device that is also running work apps and email and all that kind of stuff. Yeah, and there's two kind of paradigms to mobile security.
There's mobile device security and there's mobile app security. So definitely enterprises care about device security and making sure that any business corporate data that ends up on a phone is well controlled and secured. And actually that's a somewhat easy problem to solve because your company can force different tools and policies onto your device as a exchange for giving you access to corporate data on that device. But mobile apps for consumers is a different paradigm because a bank that builds a mobile banking application can't force their customers to install MDM tools and set policies on their devices.
They kind of have to take the device as it is and make a trust-based evaluation of whether that device is suitable to access their banking services. So I think in the B2C consumer model, there's a lot more trust that has to be placed in the end user and a lot more security checks than to be put in place to ensure that things are secure. And then if we just look at a slight difference perhaps between the mobile app landscape and desktop app binaries, whichever you'd like to call them, the reverse engineering tool maturity in mobile apps seems quite mature. And it feels like there's more going on in that space with people that like to decompile and understand mobile apps.
I mean, I'm guessing some of that is around the distribution. The distribution is very easy to go to an app store or pretty much as we refer to where most mobile apps you'll get a through an app store because of how they are distributed. So you can go and find the app of whichever company incredibly easily, which is quite different to desktop where a lot of apps are just kind of randomly hosted get a binary download or something, which you can see. So there's clearly a lot of interest around decompiling.
And as you've called out these apps link to big companies, as you said, like a bank. It produces a website, which is a whole bunch of technology, but an app is a total package there. So yeah, is that something you've seen as well and how it has evolved, I guess? Yeah, there's definitely a lot of tools, a whole democratization of reverse engineering knowledge that's gone on in the last 10 years.
And every year it just gets more intense. And I think it's not so much that desktop and mobile are different from a technology standpoint. I think there's a simpler explanation, which is people with bad intentions or attackers, however you want to characterize them, they go where the value is, where the money is. And mobile apps just represent such an attractive target that it has spurned a whole, like any good internet effort, a community, right?
A community of tools and knowledge and expertise that's been widely distributed. And up until the last year or two, it required people to write blogs and share knowledge and go to conferences and do demos to get that knowledge distributed. Now with LLMs and whatnot, that knowledge is even more accessible. People can just type in a question and get some pretty detailed guidance on which tools to use and how to approach some of these problems.
So that's accelerating it even more, I'd say, in the last year or two. And then what is the threat landscape then in terms of what is somebody likely to be able to turn up on a mobile app if they do compile it or so on? What are the kind of things that as we're trying to be protected against here? Yeah, yeah, it's a good question.
There's quite a wide range of different threats that can exist. The most basic threat can be just intellectual property in the application that's important. So that could be proprietary algorithms or ways of doing something that are unique and you don't want competitors to know or understand about that. If you've got any models that you've trained for different AI use cases, we've seen customers that are concerned about those models being manipulated or extracted and maybe used by competitors or new entrants in their market.
So IP protection is one category of use case for protecting a mobile app. We've also had some high profile consumer companies that build consumer technology with a heavy mobile component to it, concerned about new features they're building and protecting their app from competitors or tech journalists from reverse engineering to see what their roadmap is. They'll silently build out these critical features for something that's in their roadmap a year out or longer and they don't want people to know about it. So that's kind of another variation of IP protection.
So that's one sort of category. In the financial services industry, the biggest risk there is fundamentally fraud and it comes in different forms. One is around account opening fraud. It's always the world shifted from requiring everyone to show up at a banking branch with their passport to verify their identity.
A lot of that's been digitized now. You can open up a bank account digitally. There's authentication flows to verify your face and to make sure that you're a real live person and to match your identity. It turns out money laundering really wants to manipulate those mechanisms to be able to open fraudulent accounts so they can launder money.
So we see that kind of use case a lot. And then phishing based fraud has been really targeting mobile banking and payment apps a lot in recent years. So this is a case where somebody reverse engineering a banking app will download the official app from the app store. They will tamper with it to introduce malware or just code and logic to steal credentials and information from that user.
And then they'll use that fraudulent app and efficient campaign. They'll trick users into saying, hey, there's a new update of your bank app available. Click here to download it. Users get tricked into downloading it.
And now they go to login and they're passing their credentials on to an attacker sitting at the other end just waiting to log into their account and perform some fraud. So yeah, financial services, it's really all about variations of fraud. Gaming we touched on, it's about cheating. So people looking to gain an advantage in multiplayer games especially or games that have rewards or monetary components to them.
And then healthcare is an interesting one. The medical device space. What we see most often is two aspects. One, there's just a concern around privacy and data and making sure that the entire path of how data is collected from the app transmitted to servers is as secure as possible to prevent data leakage and breaches of personal information.
And then also there's just sort of an academic security component in medical devices as well. If you recall maybe 10 years ago, there were some high profile talks at events like Black Hat where they're talking about how you can remotely control a pacemaker or an insulin pump. And these things practically speaking probably don't represent a very real threat for the majority of people. So you'd think they're kind of low risk.
But they are headline grabbing and no company really wants their brand to be affiliated with that kind of academic security research. So part of protecting your app is also just a defensive measure at mitigating some of the brand risk that can come of them. Yeah. And we're going to get into sort of how this all works in a second.
I think just one more thing, which is interesting to touch on is, well, it's interesting to some people who are quite boring, but it is part of life as a business compliance and just that compliance is only getting increasingly more stringent. How does that factor into if you're a company distributing a mobile app? Like what kind of compliance are you, I guess, at let's say a bank level, like what you expected to be showing and doing? Yeah.
So in some instances, there's very targeted and specific regulations or certifications that are required for certain types of applications. So most notably, you'll find anything that deals with payments. They're the whole consortium, the payment card industry, PCI, that has layers of standards and certifications that are required for different payment types and channels. So one thing you'll notice if you go into a lot of shops, retail environments today, restaurants, they've all got mobile phones or tablets where you can tap your card against to pay.
Well, underpinning those mobile devices is an app and SDKs for processing payments. And so there's a whole compliance theme around how do we protect that payment information on what is essentially a shop owner's personal device in many cases. So those are very precise. They lay out very specific requirements that need to be met around mobile app and SDK security.
It's the most specific in what steps you need to take banking apps. Generally are less specific. They definitely have security frameworks, but they don't tend to be very mobile specific. In some regions of the world where there's a high risk of malware, they've started to introduce specific regional regulations around what steps banks need to take to protect mobile app users from phishing campaigns and app-based malware.
But beyond that, a lot of it's just general regulations, things like GDPR, ISO, NIST, HIPAA controls, where they don't really specify the mobile app requirements or controls that are necessary. They just say you need to make sure personal data is secured, sensitive data is secured, and it's up to the mobile app development team and their security team to really figure out what does that mean. So there's a bit of a gap, I would say, in terms of industry standards around this topic. And one project that's been really trying to push to address some of that is the OAS working group that's focused on what's called the mobile app security project.
So they have a verification standard and a testing guide that details what that group believes are some of the important security considerations from a mobile app. So, Garchware has been working closely with that group to help build out those requirements and provide testing guidelines and test automation scripts to help fill some of those requirements. Nice. So I think, yeah, let's get into what is actually happening.
I mean, we're talking about both the open source and the pay total product, like how they intersect or where would you like to start? Well, there's not much to say there because I think the open source product was built for a very specific purpose of optimization and shrinking. And only by coincidence did it address to some degree the security use cases. So we think mostly about the commercial tools around mobile app security and first of all mobile app securities abroad umbrella.
But within that, the area where we really started from was mobile app protection. And so protection for us means protecting the application from reverse engineering and tampering. And there's two primary axes for reverse engineering application. We call static techniques and attacks and then dynamic techniques and attacks and there's different capabilities and protection features that are necessary for each of those.
So maybe if we just start with the static side first. So static analysis of a binary is all about you download the binary and you can use any number of decompiling tools that turn machine code back into readable, interpretable, human readable code that you can understand the logic, the behaviors and spot, IP or secrets or information that can be useful knowledge to an attacker. And the primary mechanism for defending against that is code obfuscation. So obfuscating is all about taking that code and manipulating it in different ways to make it so that it's not readable so that when it's decompiled, it's very difficult for someone to understand.
And that's not to say that it's irreversible, but the complexity becomes so high with good quality obfuscation that the time it would take someone to really make sense of the code is often no longer kind of worthy the effort and time that they would spend. Yeah, I mean to some developers, this is sort of similar but different to, you know, like minification effectively where minification being that it's obviously very clear how to effectively its obfuscation but also compressing. But it's also great known and clear how to deal with skates and inflate it back up. In this case, the whole idea is that let's say you had decompiled this app as you call it.
There is no real way to de-obfuscate the code at the end of that you can see what's running there. Yeah, and the main way we achieve that is through a lot of different layers of obfuscation techniques. Right, so the simplest example is the name obfuscation that I mentioned earlier, which is kind of rooted in the open source tool, just simply renaming class names, method names, and all the different objects you see in the application with short non-district names. And when we process an application to do that renaming, we generate a mapping file.
And as long as you keep that mapping file internal to your organization, anyone without that mapping file would have a hard time putting the puzzle pieces back together. So name obfuscation is the most foundational and basic obfuscation feature that's needed. But then there's different layers to add on top of that. You can encrypt classes and then you hide the encryption code in different pieces throughout the application so that you can't read the class implementations, string encryption, similarly for protecting high value or important strings in the application.
And then you get into the more advanced and sophisticated techniques like control flow obfuscation. So here you're actually remapping the flow of the application to make it very difficult to understand the logic and how the code's flowing at runtime. And then virtualization, you can virtualize code, which again makes it very difficult and provides a whole layer of interaction that just makes it very difficult to observe or analyze the application. So those are all examples of some of the features that we use as techniques to defend against static attacks and techniques.
Yeah, and it's maybe just worth touching on for a second. I guess everything you've just described there, these are all layers as opposed to a developer might have come across one of these and has potentially implemented one of these to some extent. But my understanding is it's the ex-carbonate. We're talking about Android and IXGAR when it comes to iOS.
It's the layering that kind of adds this like defense and dev approach. Is that right? Yeah, exactly right. We always call it mutually reinforcing layers of classes encrypted, if the things within it are renamed.
If the control flow has been changed, like all those things work together to just raise the bar of the complexity of being able to analyze that code. And that's the key difference between ProGuard and our open source approaches. A lot of companies initially thought, hey, well let's use ProGuard, it has name obfuscation. Great, now our code's safe.
But a lot of times when you're analyzing an application, you don't necessarily need the real names of a class or a method to understand the behavior and what's going on. I mean, if you're familiar enough with code, you can kind of put two and two together. Sometimes there's decompiling tools that will conveniently, based on the logic contained within a class, it will assign a name of meaningful value and then find all the other things with that same name and rename them for you. So there's a lot of convenience mechanisms if you rely solely on name obfuscation as the primary technique.
So yeah, the layers are super important to work together to really provide strong defense. Yeah, and when that last one, LMs, I'm sure, are very, very good at that as well. The obfuscation deriving meaning from it. I'm sure.
So yeah, layering is very important. This, I guess, could be the approach of, I'll just say, DEX Guard for now and we're going to talk about the fact there's both DEX Guard and I X Guard. But it's a compiler-based approach, which is different to wrapper-based. And I think that's maybe some developers already understand or have encountered wrapper-based approaches.
Yeah, could you maybe just speak to, like, why did I guess you guys go down the compiler-based approach and how does that kind of differ? Yeah, so we talked about static attacks. The other side of that coin is the dynamic attacks. So things like people rooting devices and using hooking tools like Frita and others to manipulate at runtime.
What's going on with the application or inspecting things in memory or at certain key break points within an application? So the other key defense strategy is runtime application, self-protection, or RASP for short, which is just a key detection feature where you inject these checks that are just making sure the environment and everything around the device is safe and not tampered with. So checking the environment integrity, checking that there isn't a debugger attached or these different debugging and hooking tools operating on the code. So, yeah, static protections, dynamic protections, those are two key foundational principles for us.
And then the way we apply those protections is through this compiler approach that you mentioned. And the key difference there is, you know, there's a few open source tools out there, SDKs, you can download to implement some of these detections or some of these obfuscation techniques. But oftentimes these are SDKs or we call wrappers where they take the application binary and they just encapsulate it with a layer of encryption. And at startup, it then decrypts the application and the application runs as normal.
And in that startup or wrapper phase is where all the security logic lives to hide the encryption that's used and whatnot. But the challenge with this wrapper-based approach is that there's just one layer of defense. And if you figure out how that encryption mechanism or decryption mechanisms working, it's very easy to undo that security function and then what you're left with inside is the complete transparent and original binary that can be tampered with or inspected. So when we got into this market, our experience with ProGuard, it was already doing a lot of code transformation and decompiling and compiling.
So we had this sort of advantage to be able to apply that on the security front. And the benefit is we're dec compiling the app, we're obfuscating it throughout. And then we're implementing these code injections that we do for these raw features, these detections. And we're spraying them throughout the application in diverse ways and in many different locations.
And then we recompile the app and sign it or the user signs it with their original signing keys before publishing. And that leads to a very difficult to reverse and break security model because there isn't just one layer for you to attack and break apart. If you find one detection and you were to somehow intercept that, well, there's many more laying around. It's kind of like landmines or trip wires in effect.
And the reality being able to catch all of them and spend all that time to remove them since they've been woven throughout the code, the complexity is just so much higher. So the time it takes for an attacker to figure all this out and find all these places and then break across all these different obfuscation layers. It's just an insurmountable challenge. And Venetian State really wanted to break protection on an application that's secured in this way.
It's definitely possible with enough time and resources. But for the majority of attackers, they just don't have the time and resources to be able to put towards breaking that kind of defense strategy. Yeah. And I guess extra level here is SDK hardening effectively.
So SDK developers shipping code runs inside other people's apps. How does or doesn't this work with a solution like DEXGuard? Because you're having to then also consider, I guess, any security that's been working just on the app your app level as well. Yeah.
So we've been securing both apps and SDKs for many years now. So some of our financial services customers are building payment SDKs that are baked into a lot of other different applications. So all the techniques we've talked about here, code obfuscation and RASP techniques, they can equally be applied to a library or an SDK that you're developing. You know, again, we're just compiling and decompiling.
Now, there's certain features that look different in SDK than in an app. You know, things like tampering and reciting. You know, when you publish an app, it has a signature and that signature can be checked and validated to make sure it hasn't been tampered with. And SDK is going to be included in an app.
So there'll be different parameters in context. So there's different features for security between SDKs and apps, but fundamentally the model of applying these different layers of techniques and defenses can be applied to both. And, you know, the biggest thing we do occasionally see is that if we've protected an SDK, sometimes that detection mechanism that's baked into that SDK can trigger if the app that consumes it was protected using other tools that are using techniques that conflict. With that SDK protection.
So that's something that occasionally will come across where there's configuration changes that need to be made to ensure compatibility in those cases. So kind of moving, I guess, on from the implementation of this, if we actually look at security testing, I assume that guard square also does security testing as part of whether it's through the tools themselves or potentially as a service, but you must have seen a lot in this face. So yeah, what are we talking about when, like, an unsecured app, what some of the kind of most, I guess, common or most crazy things you've seen come out before that hardening processes has taken place? Yeah, so we used to focus exclusively on mobile app protection and applying protection to apps.
But around four years ago, we invested in building out some product capabilities around mobile app security testing. And the reason for that is our goal is to help developers secure apps. And you can have an app that's well protected, but still have inherent vulnerabilities within it. One doesn't necessarily address the other.
So we wanted to provide security testing as a capability. And the main reason, because there's been a lot of security testing tools on the market for years. I mentioned companies I was with in the past. So you've got, like, var code and check marks and all these companies that do security analysis of code.
But a lot of them kind of operate at the language level and weren't really specialized in the kinds of vulnerabilities and risks that exist in mobile apps. So we saw a bit of a gap there. Just security checks that really weren't relevant or an existence from mobile app developers. So that was kind of the decision for us to build this tool, this capability.
So when we launched it, we tried to get as many apps scanned as we could to really pressure test the findings and optimize that over time. And in that process, yeah, we found some interesting things. I'd say there's three kinds of vulnerabilities that we most commonly see. The first one is just hard coded keys.
So it turns out that despite all the technology that's available to try and prevent this, people still make mistakes and hard code security keys inside their application code. And don't do much to protect or mitigate that. Old habits die hard. Yeah, exactly.
So we did an analysis of a little over 5,000 banking apps for Android. And we found 164 hard coded keys that were contained across those applications. And these are keys for things like AWS, infrastructure, different security, and points that they have in their application. Tokens that are used as part of their authentication flows.
Things that just with an attacker coming across them, they can take advantage of infrastructure or authentication bugs to exploit an application. So hard coded keys is still a big one that we see. Insecure communication is another. So here, I think everybody knows that they should be using TLS and securing the communications between their mobile app and their backend APIs.
But it turns out that there's a lot of mistakes that can be made in the implementation of TLS and to do it correctly, verifying the certificates. And so there's just a lot of unique vulnerabilities, a whole class of them that can exist in an application. And if you get something wrong, then the app is subject to man in the middle of tax where somebody on the same network can intercept and interfere with the data that's being shared. And then the third case that I think is really interesting that we've seen, we used to just do static analysis of application code to find these kinds of vulnerabilities.
And then we realized actually if we interactively evaluate the application during runtime to find other classes of vulnerabilities or concerns an app developer might have. And one of the interesting use cases we had for this was identifying third party libraries and which endpoints they're communicating with. Because app developers, you build up this mobile app, you rely very heavily on third party libraries and frameworks to do all sorts of things. If you want to implement advertising in your app, you rely on these ad libraries.
You want to capture some user behavior analytics, you rely on these libraries, crash reporting, other libraries. So there's a huge supply chain of third party dependencies. And it turns out not all of them are doing the right things. So our interactive analysis feature allows you to identify all the endpoints your apps communicating with so you can review them and determine, you know, are these expected or these trusted doors or something going on.
Leaking data for my application that I wasn't expecting or I don't want to exist. So some good privacy checks there that developers can implement. Yeah, from where I said I'm not working on mobile app specifically, but I'm definitely seeing from a security perspective, I guess what's termed as egress restrictions being really looked at a lot more closely now. So if developers are able to use a tool, not always is it kosher that they're able to call it exaltory the data off to an endpoint that they would like.
So that's definitely seeing if you want to call a trend, a trend being that there's just we've seen kind of the bad cases now of where data can leave a platform. Kind of unchecked and where it heads off to. So that makes a lot of sense. And just kind of I guess going back to also in as of current and past life having to submit apps through these web apps, for example, but we have apps through security screening checks.
And the thing that always frustrated me was, okay, you get a bunch of usually hopefully minor or medium requests on what's going on. But if the services provide remediation steps are incredibly basic, it doesn't really apply to the code that you've written and you have to go and do a whole bunch of figuring out like, what do they actually mean when they want us to tighten this bit up or, you know, whereas if you have this like integrated solution, which sounds like you guys do, then you're able to look at the findings. But at the end of the day, the product is right there to then tie up all these pieces. Yeah.
Yeah. That's right. So for us, we always offered these discrete tools for protection and for testing and thread monitoring and such. But in the last year, we brought them all together into this platform.
And the main reason there was just to make all these tools really accessible. So if you're going to recompile your rapid build time to apply these security protections, well, you might as well submit it for an analysis and get a scan back at the same time to identify any regressions or vulnerabilities that have been introduced. And our focus on findings with our security testing has always been to be very precise and to err on the side of actionable versus noisy. You know, a lot of the code based static analysis tools.
Yeah. You said they'll uncover thousands of findings, but many of them are meaningless. And when you go and triage them, well, in this context, that's okay. So we try and eliminate that by being very reserved, I guess, in what we flag is a vulnerability and making sure that each of them are accompanied with directing you where in the code.
This vulnerability exists and recommendations on what steps you need to take to resolve it. And I believe there is another piece to the suite, threadcast. So it's like real time thread monitoring. Like, how does that fit into all this?
Yeah. So I mentioned, you know, we've been in this mobile app protection business for some time now. And one of the questions our customers kind of always wrestled with was, okay, my apps protected, but like, do I really need the protection? Is anything nefarious actually been going on that really matters?
And it's kind of like equivalent to, you know, you think you secure a building or a house, you know, you lock the doors. And, you know, you don't know if anybody was trying to pick the lock or if anybody's been prowling around. So threat monitoring for us was kind of like the equivalent of installing doorbell cameras or outdoor cameras to supplement the locks. It gives you visibility into attempts to target or manipulate your application and just a lot more rich analytics on the threat model.
So rather than just protect it, ship it and hope it's secure, you kind of have some verification of how well secured is it and collecting data that can be really helpful to correlate with other data points in case of some form of security event. So for us, threat cast was a way to introduce that visibility for once you've released your app to get that feedback loop on what threats occur, who's using the app, where in the world on which devices, which code functions that they've been attempting to hook, and it can help you get a really clear picture of maybe victims of phishing and fraud that are trying to use your app, as well as kind of following the chain back to where the reverse engineering started in that phishing campaign and who created a tampered version of your app to begin with. So it's a lot of threat intelligence information that can be really useful for companies. I'm just curious, is this from an implementation?
I don't know if you've heard of Canary, Canary is this service that drops these little files into your Google Drive or something, you know, and you call them. Yeah. I think it's Canary. I think it's called.
There we go. Is it kind of the same idea that developer trips over or something like, oh, I'm trying to hook this function and in doing so, they basically trip something? Is that kind of how it operates? Yeah, very similar.
So those dynamic detections that I talked about that we spray and inject. Yeah, there are all these little trip wires that are constantly checking the state of the environment, the state of the memory, whether debuggers are attached and if code's been manipulated at all and just detecting the different reverse engineering tools that exist. And it's those trip wires that are sending signals along with other sort of basic data that's collected to put into this threat intelligence database. Nice.
Yeah. I think it's always love that technique. It's like, feels so simple, but it's so effective. And if we just also look at attestation, so I mean, we've covered this in the past on a seat daily, again, more from attestation of packages that end up in, you know, like, in open source, like, that end up in larger applications.
You know, do you know who actually has provided this code? Like, is this the actual actual open source package from the actual maintainers, you know, which is becoming so important these days? And again, I believe there's like some aspect of that in the guard square approach. Yeah.
So last year we implemented an attestation capability and the primary purpose of this is so that you can verify on your backend APIs that the person or device calling into that API is a valid and trustworthy device. So what we heard about is just examples where people have an API endpoint for, let's say, authentication, and they would get these credential staffing attacks that are targeting their authentication endpoints. And those credential staffing attacks are just scripts and things that are just calling into their API. So attestation gives us a way to, in the mobile app, request a encrypted token from guard square that's signed using a private public key pair that our customer provides.
So we'll take their public key that they've shared with us to sign this token, send it back to the mobile app based on the threat data we've collected that asserts whether that device is trusted and meets certain policies and such. And then that token from their mobile app can be attached to any API request that they make. And then they'll use our server side SDK along with their private key of this key pair to decrypt that token and inspect whether it was a passing or failing result. And so if a bot or script tries to contact that API endpoint, it won't have a token.
So it'll just fail and they can reject all that bot activity. If it's an attacker trying to replay a token, you know, there's a validity period and such. And if it's somebody using a device that's been tampered with or an app that's been tampered with, the token that we've provided will be a failing result. So it just kind of closes the loop and allows you to not just secure your mobile app, but also secure your API endpoints and make sure only your mobile traffic that's vetted and trusted can communicate with those APIs.
Yeah, very nice. I guess looking at sort of guard square total, I mean, these days at least just from where I said, like looking at a bunch of security companies, the research piece is like one of almost the most important in terms of visibility and that trust piece of believing that there are people that really understand what's going on out there. And obviously it's great if you're able to come up with research that no one else has on a certain vulnerability or so and so forth. But yeah, like how does guard square approach that piece and is that like a dedicated team or do you kind of share around or like how does that work?
Yeah, so we have a security research team and they kind of serve a few different roles for us. One is anytime we're developing new security features or mechanisms in our products, they're the first people to try and break it and do it through its paces to make sure that it really meets our bar for a security feature. So there's sort of an internal kind of pen testing angle to building the software that we build and we just hire these experts in our security research team that know how to attack things, break things and find weaknesses. So that's one purpose of that team.
But the other is to sit on Telegram channels and go over the internet finding new GitHub repositories that are popping up that have all the latest developments in reverse engineering tools and technology because these things don't stand still. So we're moving fast and the value of our security protections relies on kind of staying ahead of or near proximity to the development of all those tools and techniques for attacking the labs. Yeah, we had someone on from Waze, which is cloud security. And yeah, I was asking them like, where do you go these days to find any of this stuff and sort of used to be kind of actually be too safe, for example, like we actually have quite a lot and it's just being pushed further and further away from the fringes and you've got to go find your discord channels and your telegrams and all that kind of stuff.
Yeah. Yeah, exactly right. Occasionally when we do this kind of research will come across something novel or interesting that we do want to share. So, you know, we'll write blogs and technical articles that describe how these things work and steps you can take to mitigate it.
One of the things we have is our security research center on our website where sometimes we'll just describe different coach snippets and examples of how you can mitigate some of these risks. So even if you're not someone who's looking to leverage our technology or tools, you know, we can find some knowledge and resources out there for folks that are trying to do it themselves. Yeah. I'm looking ahead.
We touched on that. I think towards the beginning actually, you know, just like how LMS are probably upending the space a bit. What are you guys looking at when you sort of think, well, over the next one, two, three years, like, where is this going? I mean, I'm curious because, you know, from a pure app perspective, yeah, mostly apps I use daily are quite functional apps.
You know, finance is a huge one now. Like I have a whole folder of finance, you know, I've got eight different finance apps or some description, like LinkedIn institutions, you know, not just like charting something. It's like, for whatever reason I didn't have lots of, maybe because I lived in different countries, you end up like bank accounts or something to that effect. So I feel like what I do on my smartphone, my iPad, these days, it's very functional and it's very important.
Less of, I guess from year, but less of the gaming and those kind of thing. But where are you guys going to look in when we're in the cross the next few years? Well, I think the whole reason I came to guardsware and joined the company was that I saw a pretty long runway of growth ahead for the company. For two reasons.
One, mobile apps are just becoming so pervasive and important. And I think that trends, you know, every year, there's just more important things I do on my phone than I did the previous year. So that's one sort of dynamic. And then the second is security aspect.
I think our biggest observation around mobile app security is that it hasn't really reached its pivotal moment. It's CNN moment. There hasn't been a lot of coverage on mobile app security, high profile issues. You'll see things in the public like, oh, there's a data breach where there's a security event.
But rarely does it get down to the detail of, oh, well, the mobile app was a real risk or concern in this. So I think we're still in the early days of that sort of forming. And right now it's the attackers and these communities that are building up the knowledge and such. So for us, the future is just about creating awareness and just trying to stay ahead of how these attack techniques develop so that we try and reduce as much risk as possible in lockstep with the sophistication of mobile apps.
And LOMs definitely are a vector that we've got to be aware of because it democratizes a lot of the attacker knowledge. I don't think the LOMs are going to invent any new novel way to perform reverse engineering or an attack, but it makes it more accessible to more people. So you end up with more attackers than you did before and more people trying to maliciously target apps for all sorts of reasons. So I can do a count takeovers so I can steal the loyalty or reward points from name any app that has loyalty or reward points these days.
So a lot of different motivations. And that's kind of how we see the next few years is just trying to keep pace with that. We call it the cat and mouse game constantly trying to unearth these things. I guess one industry if you like that we haven't maybe touched on, but could be interesting is mobility and the day vehicles have apps loaded into them.
It doesn't now. So yeah, I imagine that's an area that maybe is on the radar or are already supplying to mobility or yeah. Yeah. When we say we support Android, Android kind of can be used in a lot of different operating modes, not just a phone per se.
So we definitely have some examples in the automotive and logistics space that are like that. Yeah. So I guess a developer today listening is something that now understands why they need to secure their apps betterly than never as they say. But where to go to kind of get up and running I guess where's the best place.
Yeah. So there's a few different things that I could suggest. I mentioned earlier the O-WAS working group around mobile app security. That's a good place to start because they have a whole verification standard.
It talks about the different levels of security depending on the sophistication of your app and the use case. And then they've got categories of concern, things like privacy, communications, storage, etc. So it's a good way to get a broad understanding of security disciplines and considerations for mobile apps. We put out a new blog post every single week on our website, got to our website.
Some of them very technical, talking about different attack techniques and things we've uncovered in our security research. And sometimes just high level information around compliance and things that appeal more to the security teams. And then we have our security research center. So if there's a specific threat that you're concerned about, it's a good place to check to see if we've got any documentation on it and specifically around the topics of malware, for example, or creating a device binding between your mobile app and your server backend.
So get articles on topics like that. So those are the resources I'd start with and get smart about it. And then if you're serious about looking for security protection, feel free to reach out to us. Yeah.
Well, thanks so much for coming on. I mean, I think even though I work, especially used to work very much in security and I set across a bunch of things now, but I've definitely learned something today. I really appreciate it all the kind of in and outs of how our apps I'm using, how they can all be infiltrated, so to speak. So yeah, really interesting.
And I'm sure all of the audience have learned something new today as well. So thanks for coming on and I'm sure we'll catch up again in the future. All right. Pleasure.
Thanks for having me.