Application Hacks vs. Software Supply Chain Hacks

In this episode, Matt explains how a modern Software Supply Chain Security platform prevents hacks that traditional app sec tools like SAST/DAST miss, such as malware insertion.

Keep learning
-On Demand Webinar: Why Traditional App Sec Tools Fail at Software Supply Chain Security
-Business Brief: SCA Tools and Software Supply Chain Security - Better Together
-Report: The State of Supply Chain Security

Episode Transcript

MATT ROSE: Welcome back to another episode of ReversingGlass. I'm Matt Rose, Field CISO at ReversingLabs and the host of this series. Today's episode is something that I've had a lot of questions on. There's a lot of discussion out there, but it's really about application security

hacks versus software supply chain hacks or AST hacks versus SSCS hacks. Why are they different? People are like I've spent all this money and this time in the effort to roll out a SAST solution or an SCA solution. What the heck is this new software supply chain security solution that everybody's talking about? And really want to level set some things that all of these solutions are important at finding specific lenses of risk, whether that's a SAST solution in the AST umbrella or a

 malware identification or a potential compromise of a secret in a software supply chain instance. So thinking about this, the biggest thing that I like to say is a hack is really going outside the bounds of the intended purpose of the application. It does what it's functionally supposed to do, but it does some other things too, some things that it's not intended to do.

And a lot of times these things are very hard to find based on very aggressive release cycles, very complex applications. So on the AST side, cuz it's on this side of the board, we're gonna talk about, one of the superhero if you will, type of vulnerabilities, which is SQL injection.

SQL injection has been around since I've been in the application security industry. And what SQL injection is a way for you to manipulate the call to a database to go outside of the scope of the data you're getting back. So from a SQL injection, it functionally works in this way.

If I wanted to log into an application and I wanted to say, hey, gimme all the records for customer 1234. Customer ID 1234, the application basically works, calls the database, brings back all the data, but if you were to manipulate this with a common type of attack where you put into the screen customer ID equals 1234 or one equals one or one

one always equals one. In theory it does, but one always equals one. So you're gonna get back to all the data for Customer ID 1234, and everybody else. So it functionally worked. It gave you back if you did it the correct way, the correct information for user ID or Customer ID 1234. But if you manipulate the sequel query without parameterized SQL and you're not doing proper validation checks, you could get back all the data.

So it did what it was supposed to do, but it went outside the bounds of the intended purpose of that query call and gave you back more information. Again, it functionally worked, but it did other things, unforeseen things or untested for things. That's the AST world. Very simplistic example of why a SQL injection is important in something that would be identified by a SAST solution.

On the software supply chain side of the house, you're not really looking for code level issues like SQL injection or cross-site scripting or those type of things, the OWASP top 10 type of issues. You're looking at potential of malware getting into your application or the compromise of the application in doing things that are outside of the scope of the intended functionality.

This is where I previously talked about in the episode about behaviors. What is the application doing? So again, going outside the bounds of the intended purpose. Malware does things like, open ports. It also, it could basically escalate privileges. I'll just use EP (escalate privileges).

So it's doing things that's architected and tested to do certain things, but the malware makes it do things above and beyond what it's supposed to do. So in simplistic terms, when you're thinking about hacks, it's all about making a piece of software or an application do things that it's not supposed to do.

That could be either through compromising coding practices, not proper validation of inputs from a query string or from a form input or in terms of software supply chain risk. The application could do things with compromise of secrets, of compromise of the build environment, the insertion of malware in these two areas to allow the application to do things that it's not intended to do.

So don't think that software supply chain security and application security are exactly the same thing. Software supply chain security is more of a discipline looking for a certain set of outside the bounds of intended purpose or intended activity at the package level. While the application security testing tools like SAST and SCA and API scanning are looking at proper configuration for potential compromise of those activities.

So that's the episode today. Just food for thought. I'd love to have this conversation cause everybody's, "ah, I'm already looking for software supply chain issues in with my SCA solution or my SAST solution. I already got those. I'm totally fine." They're not looking at the lens of malware behaviors, diffs, secrets compromise.

Think about that. Food for thought. I'm Matt Rose. This is ReversingGlass. Hope you enjoyed the episode.