In this special edition episode of ConversingLabs, host Paul Roberts interviews ReversingLabs Director of Product Management Charlie Jones on the sidelines of the RSA Conference 2023 in San Francisco. Charlie speaks with Paul about his RSAC track session: The Rise of Malware Within the Software Supply Chain.

EPISODE TRANSCRIPT

PAUL ROBERTS
Hey, welcome back to another episode of Conversing Labs. I'm Paul Roberts, the cyber content lead at Reversing Labs and your host. And we're here today to talk with one of our own here at Reversing Labs.
Charlie Jones, who's talking at the RSA Security Conference in San Francisco about supply chain security. And Charlie, welcome to ConversingLabs.

CHARLIE JONES
Thanks for having me, Paul. Excited to be back.

PAUL ROBERTS
We're really excited to have you. I think this is what the second time we've had you on

CHARLIE JONES
The second time, yes. I'm officially a recurring guest.

PAUL ROBERTS
You are a recurring guest and we're, glad to have you back. So Charlie, before we get started talking about your presentation at rsa tell the audiences a little bit about yourself.

CHARLIE JONES
Yeah, sure. My name's Charlie Jones. I'm a director of product Management here at Reversing Labs. I'm specifically responsible for overseeing our software supply chain security product, which is great cause that's the exact subject matter we'll be talking about today. And then I'm, talking about it at R S A as well.

PAUL ROBERTS
For folks who maybe are attending the show just tell them, so you're speaking Thursday. Just talk about like the topic of your presentation and how the idea behind this came about.

CHARLIE JONES
Yeah, sure. I'm speaking in the hackers and threats technical track. So broadly covering software supply chain security, like I said before. We'll talk about the threat landscape, how that's surrounding the software. Supply chain and how it's evolving will cover different attack vectors and techniques that are being used to target it.
And we'll draw on a few kind of recent breaches to bring this to life. To answer your question, that's really what is, drawing the inspiration behind the speech is the, constant evolving. Landscape and how it's impacting a lot of our customers. We'll talk about some current approaches to managing software supply chain risks that are being used in the industry today, and how they tend to be a bit behind the times and, not in touch with the reality of today's threat landscape.
And then some actionable takeaways that attendees and security practitioners can apply in their own businesses.

PAUL ROBERTS
Supply chain security is a really big topic at this year's. R S A, not a new topic necessarily, but I think one that's really gaining a lot of traction within the information security industry. One of the challenges around supply chain security is really around where the responsibility lies.
And I think this is something that we're hearing a lot about from the federal government, the administration now putting more of the onus on. Software manufacturers. Just talk a little bit about that question of where the responsibility for securing software supply chain really lies.

CHARLIE JONES
Yeah, it's a good question. And the software supply chain, I guess first I'll predicate with is incredibly complex. There are a ton of stakeholders that make it up from end to end, from the creation, the packaging, the delivery, the consumption. In the most basic terms, I like to break it down between publishers of software, people that.
Manufacture published software for use, and then people that consume software, so procure software, whether it be commercial to shelf or open source software. The short answer for who's responsible across those two parties is both of them. Like you said, there's been a lot of recent kind of legislative movements, whether it be the White House National Cybersecurity Strategy or the recent, the most recent, I think it was this week or last week secure by design default principles that were published by cisa that are, like you said, making an active push to shift liability and responsibility to the publishers of software.
That being said, in my personal opinion, when a business makes a conscious strategic decision to outsource any business function such as software development, they are still ultimately responsible for the risk. That comes along with that, whether they manage it directly or not. Cyber risk is not something you can outsource.
You can certainly mitigate it through some technology, through some controls. You can transfer aspects of it through things like cyber insurance, but you cannot outsource it because, If a consumer of software gets breached because of a supply chain attack, all of a sudden they have upset customers, maybe regulators breathing down their neck.
It's not enough at this point to point a finger and claim that, look, it's out of our remit. So I think the key takeaway here is both parties, publishers, and consumers need to find a way of. Discharging their responsibilities improving to legislators and regulators, that they're doing some level of due diligence and testing over the software that they're publishing and consuming.
And during my session, we actually talk about a few ways you can do that. Things like using technology like static binary analysis. And both parties can actually do this because you don't actually need access to the source code. You can do it just using the, software binary that you're publishing or deploying.

PAUL ROBERTS
I think everybody thinks about incidents like solar winds. We're gonna talk about that in a second. Where malicious actors believed to be Russian state actors actually infiltrated the development organization, modified the application code itself.
But one of the points that you're making in your talk is that software supply chain risk is actually much broader than that. That actually compromises can happen at any point along a fairly long development, deployment chain.
Just talk about some of the different iterations of software, supply chain risk and software supply chain.

CHARLIE JONES
Yeah I, think that's a really fundamental understanding that the broader industry is still getting their hands on, that it isn't just one type of threats that you need to. Software supply chain attacks don't occur in a vacuum. It's not one type of vector that's being taken advantage of. And I really like personally to use.
The SLSA does a really good job. It's managed by OPENSSF. It's been used by Google for years. But what I like about SLSA is they have this kind of threat model to help demonstrate the breadth of attack techniques that are at the fingertips of malicious actors to use. And you have everything from right, the simple vulnerability in a commonly leveraged open source component or dependency like Log4Shell, the vulnerability that's used in Log4j. You also have things like unintentionally exposed secrets, which provide an initial point of entry into a network. So that's exactly what happened in the CodeCov attack, for example, where on authentication key was left in a Docker image unintentionally.
Then you have things that, specific attacks that are targeting the open source ecosystem. Things like dependency, confusion, attacks. Malicious actors are essentially creating malicious packages that are masquerading as legitimate ones by misspelling them slightly or changing the version number of the most recent version that's out.
And then you have. Everything on the other end of the spectrum, which is those very sophisticated attacks like you talked about, like SolarWinds, where they're not taking advantage of anything we talked about already. It's not taking advantage of known CBEs, it's not using known malware. It's very novel and obfuscated or o hidden using obfuscation techniques.
But instead they're focusing on compromising things like the build infrastructure in inserting malware before digital signatures actually occur. The impact of all this is malicious actors have options and they're using different techniques that are applied at different stages, the software development life cycle.
So when we're trying to prevent these attacks, there's no single bullet that's gonna stop you. Companies really need a robust program that can detect against this litany of attacks that could occur. Otherwise, they're gonna leave themselves open to risk.

PAUL ROBERTS
That said, at a lot of the focus and conversations about software supply chain security is often around vulnerabilities and preventing vulnerabilities in code or secure development lifecycle stuff.
Obviously for good reason. We don't want software to get out there that has exploitable vulnerabilities in it. But that kind of in some ways overlooks a lot of the risks that's in the, that's just inherent in the way softwares developed these days.
Could just talk a little bit about what we're missing in focusing so intently on finding and patching vulnerabilities?

CHARLIE JONES
Yeah, I, we've definitely found that there's certainly a disconnect between this, like you said, hyperfocus that exists on the detection, the response, the mitigation of vulnerabilities in software. With the actual threats that we see being taken advantage of and specifically targeted in the threat landscape.
In reality, we're seeing different attack types, a lot of the ones that we talked about before, the taking advantage of known secrets or known sensitive information that can u be used to further attack paths, tampering with software and digital signatures. Compromising build environments and so on.
All those attack types we talked about before. I, think the key takeaway here is focusing on vulnerabilities, simply in itself, isn't enough. And it actually tends to not be that effective. There was this really interesting research study that Ponemon Institute put out. It was around essentially the state of vulnerability management in DevSecOps, and what they found was that 50% of vulnerabilities never actually make it out of the backlog in the first place.
So drowning yourself in vulnerability detection won't actually end up solving your problems. I think the key action that people need to take away from either my session or just more generally is that we need to reallocate some of the efforts and resources to focus on maybe higher risk items in DevSecOps.
So packages that are known to be malicious that are a much better indicator that your environment has been compromised rather than a vulnerability that may be unproven in nature. Or if you are still focused on vulnerabilities and that still should be a big part of your program, look at or prioritize those vulnerabilities to those that are impactful things that, like vulnerabilities that are exploitable or are mandated by CISA, for example, to fix. And there's various resources out there to do that. Things like the CISA KEV catalog, the known Exploited Vulnerabilities catalog can be helpful in, deploying those mechanisms.

PAUL ROBERTS
So what is some advice that you have for security practitioners and security practitioners could work within software development organizations or are actually on the end user side, on the customer side to address some of these supply chain risks. Apart from the work that they're already doing to address more kind of traditional it risks.
What are thoughts that you have or, recommendations.

CHARLIE JONES
Yeah. We touched base on this in my session, and I, say there are always the basic things that are covered by every security framework in existence of our modern society, right? It's the questionnaires for consumers, like you said, the questionnaire based third party assessment where you're going to assess the risk of doing business with a software supplier.
And there's things like pure code review for developers. I try to focus on some of those more impactful activities that can be really driven through technology and automation. So the first thing I'd like to say is: Make sure you're verifying the third party and open source components in the software that you're either producing or you're consuming.
And the main way of doing that is through the generation of an SBOM but beyond just understanding, yes, I under, I know the components which are within my software making, going a step further and making sure they're actually coming from a trusted source and making sure that the components that you actually intend to use so you can avoid these, types of attacks like typo, squatting attacks, for example. For publishers specifically something basic that you can do is hardening your build environment, right? It's a very basic kind of security hygiene control that you can accomplish in a myriad of ways. Things like enforcing, multifactor authentication minimizing and regularly auditing service accounts, those types of things. 
If we take it a step further and we want to start detecting those more sophisticated types of attacks one really good thing you can do is setting up mechanisms to. Identifying and blocking potential suspicious behaviors that you know are deviating from the intended purpose of the application you're using.
For example, if you're using a backend accounting application, a third party COTS software, should it be recording keystrokes? Should it be reaching out to remote servers and uploading files? Things are indicative that an attack may be occurring and have no place. In software of that use. And then finally looking for malware, proactively hunting for malware.
So beyond simply relying on some downstream controls like e d r antivirus things that you're hoping are gonna retroactively catch malware once it's already in your environment that actually weren't created for modern software packages themselves. Proactively go out and look for malware using things like custom Yara rules or intelligence threat intelligence, enrichment and file reputation databases and things like that.

PAUL ROBERTS
A final question if you could, Charlie. Obviously SolarWinds more re recently we had the 3CX supply chain attack. For consumers of some of these software and services these supply chain risks can seem very amorphous and beyond their control. But are there things that the end user, the customer, can do to insulate themselves a little bit from a software supplier who may have been compromised but doesn't know it yet?

CHARLIE JONES
Yeah, I think the constant attacks are just, once again, a reminder that. Third party software is not something you inherently trust, right? It does present a risk and you are largely limited on the consumer side because you can't really perform any invasive testing either because the supplier won't let you or because of the way contracts are naturally structured for software suppliers. They don't include things like the right to audit. So you have to ask yourself what actually can you do in the absence of that ability to perform due diligence or audit a, supplier? And so there are technologies out there like we've talked about, static binary analysis.
As long as you have the commercial off-the-shelf binary that, you're deploying in your environment you can gain insight into the risk that presents. You can do things. Generate your own SBOMs. You can do things like look for vulnerabilities, hunt for malware, identify tampering, and many other things.
So it's all about are there opportunities for you to shed your dependencies from your suppliers and equip yourself with the tooling that you need to independently validate that software. So there's certainly options out there for consumers. It's just about understanding what's gonna be most beneficial for you and.
Ability, you have to execute those.

PAUL ROBERTS
Charlie, is there anything I didn't ask you that I should have asked you or that you wanted to say??

CHARLIE JONES
No. If you're around RSA on Thursday morning feel free to come to my speech. I'd love to pick your brain and ask questions from the industry. We learn from each other. Excited to be here and excited to be at RSA.

PAUL ROBERTS
Indeed. And we will definitely include a link to your presentation when we post this as well. But Charlie Jones thanks so much for coming on and speaking to us on Conversing Labs. It's been great to have you back on.

CHARLIE JONES
Thanks Paul. Looking forward to the next time.