Spectra Assure Free Trial
Get your 14-day free trial of Spectra Assure for Software Supply Chain Security
Get Free TrialMore about Spectra Assure Free TrialIn our experience, companies are used to looking at managed software, either as it enters or exits their organization's controlled environment. They'll have known trusted suppliers and discreet installers, and more likely keep their focus on delivering production-ready software and less on application security. So, what happens in-between?
As more tools pop up in new repositories, developers use whatever they need to get the job done. It might be a containerized deployment architecture for one application and something else entirely for another. Most companies are not looking at the components within their environment, or the security of this software. And while that's true to an extent, it isn't always true.
It's possible that there's a perception, among developers, that the community self-patrols itself. And while this may be true, the community simply can’t predict developer behavior. For example, the potential to mis-type package names and erroneously download typosquatting malware. The challenge, then, is: Volume and Proliferation. There are more tools in use, more people using them, and they're being examined only as they are in motion during entry or exit.
Another challenge comes to mind in considering how many people use each tool, and when: Ownership. Quality Assurance has always fallen to someone in the organization, but it's largely a measure of whether an application is working and usable, not whether it contains malicious objects. In today's world, QA belongs to developers, while the SecOps team handles inbound threats and data leakage. However, more and more Security teams are being pulled into examining Application Security, and the broader software lifecycle - even if they don't own it. So, who does own examining that code? Is it developers? SecOps? Or the community providing the packages?
And with all of these challenges, what can you do to begin to protect your system, even as your engineers leverage open-source components and your SecOps team focuses on what's coming in and going out?
First things first, a traditional antivirus will not successfully thwart software supply chain attacks. We can dismiss that as an option.
What will help keep the increasingly porous software lifecycle free of vulnerabilities and malware? Largely, process. Of course, technology is required as well, but ultimately, software development can't be secure unless you insert new security procedures into the process of pulling code out of repositories and using it for your own applications- whether for internal use or external distribution, and into the process for validating 3rd party applications- as a second check on the source.
Let's say you add a checkpoint for every time a new (to you — it already exists elsewhere) piece of code is about to be brought into the software lifecycle. What do you do at that checkpoint to ensure nothing in the software has any malicious components? Executing in a sandbox for every package leaves you with gaps, still; not every file or piece of a file is a simple executable.
Instead, you have to look — really look — at the code you want to bring in, using static analysis. With static analysis, you can see characteristics of the files that are indicative of certain malicious content types, allowing you to flag and further analyze said file.
(To learn more about how static analysis can find malicious code within a package manager repository and get all the details, listen to our podcast hosted by Cyberwire: Detecting Malware in Package Manager Repositories)
The way to protect your systems and your software supply chain best, then, is to analyze content you download from 3rd party repositories so your developers can feel more confident using what's at their disposal. Rather than requiring developers to alert anyone when they need a new piece of code, and rather than waiting until pushing that code to production, they can place that code in another repository — one designed for malware analysis.
From there, the malware analysis can be automated and retro hunting enabled, allowing the process of review and alert to run seamlessly once you have the right solution in place. As alerts are generated, threat hunters and analysts will know exactly where to intervene, and any bad code engineers unknowingly pull from a trusted repository will not make it into production. Your software supply chain stays clean.

Unveiling the Hidden Threats: Enhancing Email Security with Object-Level Analysis
Enhancing Endpoint Visibility: Leveraging Advanced File Intelligence to Uncover Evasive Threats


