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
Field CISO at ReversingLabs. Matt Rose has an extensive background in application security, object-oriented programming, multi-tier architecture design and implementation, and internet/intranet development. His areas of expertise include Application Security, SAST, DAST, IAST, SCA, DevSecOps, and Threat Modeling. Matt is an accomplished public speaker and has been quoted in 50+ AST industry media publications.



