Development Secrets....Shhhh It's a Secret
In this episode of ReversingGlass, Matt stresses the importance of not only finding secrets in software, but also identifying them so that development teams can efficiently mitigate potentially threatening secrets leaks.
Learn More
- ReversingGlass: What the heck are secrets?
- Learn more: Secrets Exposed: The why, the how – and what to do about – secrets security in software
- Analysis: The CircleCI secrets hack was a red flag
Episode Transcript
Learn More
- Glossary: What is Binary Analysis?
- Blog: Developers behaving badly: Why holistic AppSec is key
- Blog: The Power of Complex Binary Analysis
- Webinar: Static Analysis vs Static Binary Analysis
Episode Transcript
MATT ROSE: Hi, everyone. Welcome back to another episode of ReversingGlass. I'm Matt Rose, Field CISO at ReversingLabs and your host for these sessions, but you probably already figured that out. So today's episode, we're going to talk about binary analysis for SSCS. I've had a lot of conversations and questions around binary analysis for software supply chain, not really following how is that a benefit? We're going to start off with kind of a silly analogy here. So how many people are familiar, and I'm a terrible artist, with the Russian Matryoshka dolls, the stacking dolls that fit inside each other. So we have number one doll and then number two doll fits in, and this one's sad.
And then number three doll that's boring. And then number four doll, which is upset. They look like, I don't know the munchkins or something like that from - remember the old grimace or the munchkins from McDonald's. But this is the concept. There's a doll inside a doll.
And what this equals is, from concept, your software package. That thing that you're trying to develop. Either you're outsourcing or you're developing in house. The way in software to break apart the Matryoshka dolls like you would as a kid taking things apart, is to use binary analysis to take this package and break it up into a bunch of little packages.
So thinking about this, there are things in there, a software package is this compiled thing that you deploy to your cloud, your data center, your container, whatever that is. But binary analysis in itself is basically like taking a sledgehammer to the package and breaking it up into those parts. That way you can actually break down and see the source code, the open source packages, any dependencies, everything that you're deploying is in there.
So a lot of times people talk to me about software composition analysis and other AST tools. Those are looking at one of the dolls, one of the pieces inside the bigger doll, or the top doll, if you will. It's basically providing you a risk of lens of one thing, in one, two, three, or four, but it's not providing you all of it at one time.
From a supply chain risk, you have to understand the culmination of all your work. What have you been doing? Many developers are outsourced, or open source projects are all going in to create this and then deploy it. But supply chain risk is, okay, what is in there? Has it been compromised? Has it been tampered with?
Are there secrets that are potentially compromised? Has something been inserted at the code repo or at the build level? These are all common things you have to think about, and the only way you're getting that complete risk lens of software supply chain is through binary analysis. Yes, those other solutions like SCA and SAST and DAST and all the other ones that are scanning different parts or different states of an application or a piece of software are important because there are specific lenses of risk it's looking for, like OWASP Top 10 issues, SQL injection, cross site scripting, API abuse, those type of things. The only way to find the, as I've said before, the how malware, or how supply chain attacks are actually executed, and what is the supply chain itself, which is malware, that is through binary analysis. And the best way to do that is take that proverbial sledgehammer to your package and break it into a million pieces so you can see everything that's in there.
I'm Matt Rose. Hopefully that was interesting. Have a great day everybody. And thanks for watching.
: Hi everyone, welcome back to another episode of ReversingGlass. I'm Matt Rose, Field CISO at ReversingLabs, and today's episode, if you haven't guessed by the top, is Shhh... it's a Secret. And what do I mean by that? It seems like everybody is talking about secrets these days. Hey, you gotta look for secrets in your application.
Hard coded passwords, all these type of things, because an application that's not self contained. It needs data, it needs functionality, and that's all interconnected with a secret. And I was thinking about secrets, and this thing popped in my head, how I like to do these type of things.
Everybody has a secret, and I want to ask people, how did we not figure out as a society, as a comic book fan, that Clark Kent was actually Superman? Look, am I a superhero? Now I took off my glasses. Oh, look, I'm no longer a superhero. Same thing with secrets. Are these secrets superheroes in your code?
And do they access interesting information, functionality, PII data, financial data, trade secrets? So let's just leave Mr. Clark Kent up there, also his alter ego of Superman, and thinking about secrets and how you should address secrets using different technologies. Because again, everybody's talking about them.
Number one is, what the heck does this secret do? The first thing you have to look at is, what is it doing? What is it accessing? Is it a secret for a database connection? Is it a secret to pull code from a code repo like GitHub? Is it something for your cloud service provider? What type of secret it is?
And secondly, if you're just reporting all these secrets, the last thing any development team or application security team really wants is a new list of risk. Like I scan my application, I do a little manual 'Sherlock Homing' of the application to find all these secrets. Are they important?
Are they dummy secrets? Are they canary secrets? Are they just in there for some sort of testing phase, but they don't actually access that information? So thinking about secrets. Okay, not just creating a list with a scanning technology or a manual process, but seeing if that secret actually works and is it important to me? Is Clark Kent important to me or is Superman more important to me... thinking about it that way.
ReversingLabs has this new approach, so we identify what the secret is, what type of secret, and then, guess what, we test it out. So if you get that secret, you can actually see if it does access specific information. What does it access? Because developers just don't want another list of things they have to look at.
Here's 10,000 secrets or even 100 secrets that you now have to vet out. Let a technology platform do that for you and vet whether, hey, I even care about this secret, is it accessing something interesting or is it actually useful? Maybe that secret has been changed somewhere else and it's hard coded in your code or some part of your application in terms of the infrastructure, but maybe it's been changed somewhere else.
And now that's a dead secret. So not only do we have to identify what secrets are and how they actually work, but are they actually working to connect to some sort of sensitive information. Do a little homework, do a little research on secrets of all the application security technologies that are out there.
How are they taking not just identification of secrets, but making it much more high fidelity in terms of information for the development staff? And again, it still bugs me that no one in the world or all the movies could just figure out that Superman and Clark Kent were the same just because he took off his glasses.
Hope you enjoyed the food for thought. I'm Matt Rose, Field CISO at ReversingLabs. And this is another episode of ReversingGlass. Take care, everyone.
