Securing the software supply chain against malicious attacks

Bart: I am Brian Fox, and I work for Sonatype.

Brian: Hi, I'm Brian Fox. I'm co-founder and CTO, and I work for Sonatype.

Bart: What Kubernetes trends are you keeping an eye on?

Brian: I spend a lot of my time focused on software supply chain security. As you can see by the items behind me, that's the space I've been living in for 17 years. I focus on the artifacts, vulnerabilities, malware, and the ensuing regulations that are coming, such as the CRA (Cyber Resilience Act) and the Product Liability Directive, which may involve SBOM (Software Bill of Materials).

Bart: For people that might be new to the space, what's the first thing that you find yourself telling people?

Brian: Depends on what their background is.

Bart: Let's say if they're a Kubernetes engineer.

Brian: We speak more to C-levels that are responsible for securing the software supply chain, thinking about what the containers their developers are using, and what the dependencies are going into the software for their commercial applications. That's where I spend most of my time talking.

Bart: And do you feel like there's still a fair amount of awareness that needs to be done in the ecosystem?

Brian: Big time, especially as we're trying to raise awareness around intentionally malicious open source. This is a big blind spot in the industry. People are still grappling with dealing with what I'll call boring old vulnerabilities, accidental bugs that can have bad impacts. However, we're dealing with a massive rise of components whose sole purpose is to steal data, drop backdoors, basically a phishing attack on developers and development infrastructure coming from the software supply chain attacks. Not enough people understand that this is happening, and that they need to defend against it very differently than they would a typical vulnerability.

Bart: On the subject of supply chain security, particularly SBOM, or software bill of materials, one of our guests, Harsha, explained that container security doesn't stop at using minimal container images. Instead, one should look at the entire supply chain, dependencies, software supply chain attacks, and software bill of materials. What's your experience in securing the supply chain, especially considering your work at Sonatype?

Brian: A minimal container reduces the surface area, making it a great place to build upon. However, it is essential to be aware of everything added on top of it, including first-party code. A modern application today is comprised of about 90% open-source components, which means 90% of the software in the first-party code is written by people you may not know or trust from countries you may not prefer. This does not help with security. A minimal container does not help with these dependencies either. Therefore, it is crucial to focus on all dependencies up and down the stack. Having a SBOM (Software Bill of Materials), not just for the application but for the organization, is vital. This allows for immediate triage and response when a significant vulnerability like Log4Shell occurs, rather than spending six months contacting people to determine what dependencies they use.

Bart: When looking at leaks, security, and shadow IT, two guests, Yakir and Asaf, discussed their research on Kubernetes secrets and shared how most of the secrets leaked are from employees using personal accounts. Should companies monitor employees' personal GitHub profiles to avoid potential leaks? What tools or processes should they put in place to prevent those leaks?

Brian: Well, if they're monitoring employees' personal GitHub, that's just code for monitoring what's going on on the internet at large. It makes sense for organizations to be scanning for their secrets appearing anywhere, whether it's in an employee's personal account or somewhere else, such as an inadvertent leak that ends up on a pastebin-like website. The question is more about whether organizations should be looking for their secrets everywhere, and an employee's public personal account happens to be part of that.

Bart: Looking at the Kubernetes ecosystem more broadly and thinking about the role of security, we hear about shift left and shift down. For the average Kubernetes developer, is everyone a security stakeholder, or is it something left to the security team at an organizational level? What do you think about that?

Brian: I wrote an article seven years ago saying open source developers are the new front line. This is true, as it's not just the Kubernetes engineers using Kubernetes, but also the engineers working on Kubernetes who are targets. Many of these intentionally malicious components started by trying to attack publisher credentials, aiming to steal credentials from developers to push fake components. We are all on the front line of these attacks, which can be considered as software supply chain attacks. Nation states are increasingly targeting commercial entities as a proxy war, and we are all unwitting participants. Security will be best served when everybody is informed about what's going on and understands the risks. We need to educate developers and ourselves not to download components from unknown sources, as they might be fake and could cause harm similar to clicking on suspicious links, a practice that can lead to shadow IT. Raising awareness about this issue is crucial for our community, and companies like Sonatype are working to address these concerns.

Bart: Kubernetes turned 10 years old this year. What can we expect in the next 10 years?

Brian: Well, I think the industry at large is not responding to supply chain threats quickly enough, so regulators worldwide are stepping in. We have the CRA (Cyber Resilience Act) in Europe, the Product Liability Directive in Europe, and a number of other regulations worldwide. As a result, I think there will be increased scrutiny on practices and compliance, not only for the products we produce but also for how we produce them. This will dramatically change the scrutiny the open source community is under. In the next 10 years, I think we will see a lot of changes and new expectations from the ecosystem. To address these changes, new open source projects will emerge to make policy administration, policy enforcement, and data management easier. Overall, I think the next 10 years will bring a maturation of our ecosystem in terms of practices and expectations.

Bart: What's next for you?

Brian: The same thing. I've been preaching this message for 17 years. It's not done yet. So I think there's still a lot to keep going.

Bart: You mentioned at the beginning that you deal with folks at the C-suite level in terms of opening their eyes to the world of software supply chain security, in terms of resources. I know you said you've written some articles. What are the things that you find yourself often bringing as a sort of starter toolkit? Let's say someone's a CEO and they say, "I have no idea about SBOMs (Software Bill of Materials). This all sounds like a foreign language."

Brian: I focus on SBOM (Software Bill of Materials) as a means to an end. If you tell people they need to produce an SBOM (Software Bill of Materials), the inevitable question is why. Why do they care? What do they get from it? I always start from that perspective, asking the hypothetical. If I told you about a new vulnerability right now, how long would it take your organization to answer the question, "Are we using this dependency anywhere?" Could you then narrow it down to, "Are we using this specific version that's affected?" And then could you tell me in which applications? Many organizations can't answer that question. SBOM (Software Bill of Materials) are a way to get towards that answer. It's not the only way, but it certainly helps round out the picture. I have conversations trying to understand how well the C-suite understands that they actually have a de facto supply chain with their development. It wasn't that long ago that we would talk to CNCF, who were downloading hundreds of thousands of components from Maven Central, the Java repository that Sonatype runs, and they would tell us they don't use open source. This highlights that if they don't even know they have the exposure, then of course they don't have controls for it. The conversation usually goes around trying to tease out what their understanding is, where they are at, and then goes from the high-level benefits and works backwards to the practices that they're missing.

Bart: How can people get in touch with you?

Brian: You can find me at [email protected]. I'm on all the online platforms.