SAP CSO Justin Somaini on using blockchain for security

Blockchain seems to be everywhere these days, but Justin Somaini believes the technology has true potential for enterprise security that goes beyond the hype.

In this Q&A, Somaini, SAP's CSO, speaks about applying blockchain for security purposes and how it can address specific issues with open source software. Like many enterprises, SAP uses a significant amount of open source code, which is heavily fragmented and decentralized. A distributed ledger approach, he argues, can help enterprises monitor and authenticate the changes and updates to various open source projects.

Somaini, who was named SAP's first official CSO in 2016 and served in similar roles at Box, Yahoo and Symantec, also discusses the unique challenges open source software presents for enterprises, and how SAP confronts those challenges internally.

Here are excerpts from the conversation with Somaini on using blockchain for security programs, addressing open source software issues and more.

Blockchain has been in a heavy hype cycle lately, and it's also been the subject of criticism and even ridicule from some infosec professionals. Where do you see blockchain for security headed?

Justin Somaini: I've thought about this a lot. I think most of us in the industry see the potential for blockchain on the business side, but the question is, can it be applied to security problems?

One of the problems that has been very significant for us as an industry is wrapped around open source software. When I think about the challenges around open source, one of the things we do at SAP is not only identify and address vulnerabilities for open source software -- I think that's par for the course for enterprises -- but also to examine the pedigree of the nested modules within an overall Apache program, for example, or other tools that are being used within SAP. We do that in order to, first and foremost, understand the bill of materials and all the components of that software package that we're getting. Are they the appropriate ones that we expect?

Justin Somaini

We're talking about software supply chain in an open source world. I think there's an ability to apply this open registry to really enable the identification and vetting of those modules in your bill of materials to give not just transparency but, more importantly, the identification of malicious [modules] that aren't in that valid bill of materials as expected.

This is why we see blockchain as relevant for physical supply chains, whether it's manufacturing or automotive; they have distributed suppliers, and those suppliers have their own distributed suppliers, and tracking all the components that go into a car can be very, very difficult. Some of these companies are looking at blockchain to facilitate that.

A similar problem for us is open source software. And it's interesting because we feel open source is one of the most significant challenges that the industry is facing, with the vast majority of code created today being built on top of open source. When you look at cloud environments, it's anywhere from 50-90% open source.

From that perspective, does using open source software mean enterprises need to be more stringent with code analysis and patching? And how can applying blockchain help in that regard?

Somaini: The code analysis itself doesn't necessarily change. The tools and means and methods don't really change when it comes to open source. It does change how we remedy the situation.

For instance, within SAP products, we have a very rigid testing process, but we also have PSRT, Product Security Response Team. If a researcher identifies a vulnerability within our product, we're able to take that back and, in very short order, identify the issue and deliver a patch, and if it's in our cloud space, we update it immediately. That's fairly straightforward in that model, but it's a little bit more challenging in open source.

When a vulnerability is identified, the question is, are you going to fix the code and are you going to fork that code so that it's no longer effectively what is in the open source community, and then maintain that moving forward? Or are you going to issue it back into the development community for that open source project and wait for them to issue a patch.

The latter is what most people do, and, unfortunately, if you're in that gap, you need to take it upon yourself to put in mechanisms to defend against an attack while you're waiting for that patch. That assurance for open source is incredibly important, and also incredibly challenging to do. And we think blockchain can assist with that.

That assurance for open source is incredibly important, and also incredibly challenging to do. And we think blockchain can assist with that.

But the majority of open source projects still suffer from a lack of developers actively managing those projects. A lot of people consume open source, but not a lot of people participate. So the backlog for patching is pretty sizeable for a lot of open source projects.

And that's the biggest challenge of all, which is known issues not getting addressed because there are not enough hands in those projects. We have a huge open source security mechanism inside SAP, and we have decided we won't use some specific open source software packages, such as SSL sockets, just because it's critical for our security posture.

How do you measure which open source projects have enough hands -- so to speak -- and support, and that they are staying up to speed on addressing vulnerabilities?

Somaini: When we talk about security, usually the focus goes to the security team, which is natural.

For topics like this, the first line of defense is the development group itself. Our philosophy is whether we build the software ourselves or we consume from somebody else, like an open source project, we do need to know what that code is.

Our development teams themselves are effectively doing first layer vetting. What is the code, has it been written well and is there a supportable community out there? If we use this open source code, what is the longevity of this project? No developer wants to develop on something and have to shift it every year because there's a new project coming out. There needs to be stability. That dramatically narrows the number of open source projects that we use within the company.

We have an internal repository for any open source project that we manage instead of pulling the code off the internet. Doing that gives us the ability to apply our own tools and capabilities to analyze the code and identify issues. If we identify anything in the software, then we do have the luxury of being able to address vulnerabilities in our repository, even if it's just as a stopgap so that the industry as a whole addresses it.

So we have internal repositories [of open source code] to manage and to ensure that pedigree of code, and open source libraries, and we've really invested in strong partnerships with security vendors to ensure that we're helping them develop technologies in code analysis to identify issues and vulnerabilities better than most people do in the market. We invest a lot of time and money in the open source security problem. Unfortunately, it is a challenge for the industry as a whole.