Nick Wadge

My name is Nick Wadge, and I'm an old COBOL programmer. I started back in the days when we used to have to write code on 80-column coding sheets. I don't know if anybody remembers those. I just about missed punch cards. I'm not that old.

But if you're not aware of what 80-column coding sheets are, they're like these landscape sheets of paper divided into 80 columns where you actually handwrite your code. And when you're talking about 10,000-line-long COBOL programs, this really gives you an appreciation for how the software supply chain has changed over the years.

So I'm now Chief Technology Officer. I don't really know what that means. There seems to be all kinds of different versions of CTO around. But for me, I get involved in technology vision and strategy and architecture and technology governance. And what that means is that I get to say no a lot. And we've got 1,000 developers and engineers globally, so I really get to say no a lot.

But it's not all fun. So one of the things that I'm involved in is a program around raising digital awareness, and this takes a number of forms. We have a whole speaker series where we're trying to get people to think more innovatively. We have a tech fair, a hugely popular tech fair, and I'll go into that in a little bit more detail in a bit. And we have a global hackathon event annually as well. And I'll just talk a little bit about those.

But first, a little bit about the company that I work for. So I work for Nomura. Nomura is a global investment bank headquartered in Japan. We have around about a $21 billion market cap, 28,000-plus employees globally, and around 3,000 of those are in our EMEA headquarters here in London. So we've got a very strong European heritage.

I'm not going to spend too much time on this. But one thing I'll say, obviously, I can't go into any details about what we've done with Nomura, so hopefully the story will be generic enough that I'm not going to annoy our corporate communications, but you'll be able to take something away from it.

Now, as you'll see, I've also learned how to do PowerPoint animations for the first time, so you'll see a lot of those. So apologies for that.

I mentioned the tech fair earlier. This is some photos from last year's tech fair. What tech fair is, it's an opportunity, effectively, it's like an internal trade show. And so this is an opportunity for our internal developers and technology staff to be able to showcase the great work that they do, usually around a particular theme. And last year, the theme was innovation.

We film the events for internal marketing purposes. Top right there, you can see we have a charity raffle where we raise thousands of pounds for our chosen charity. In the bottom right, you'll see me there giving the keynote from last year's event, explaining to everybody what a 5.25-inch floppy disk is. Now, what's amazing with this was how many people truly thought that was a compact disk. There you go, youth of today.

One of the other events we held, we held our first one last year, was our hackathon. The theme this year was around building chatbots on our messaging platform. This was a fantastic event, an amazing event to get all our developers in working globally, collaboratively around the world for 24 hours. And of course, as the night wears on, you see the architecture diagrams get increasingly surreal and strange. We've got the Teenage Mutant Ninja Turtles there for some reason.

In the bottom right, you see me talking to one of the teams here. This is an interesting one. These were our team of grads. And that's very relevant to our story today. But these grads had only been in the organization about two weeks, but they felt they were able to join and participate in this hackathon event. So absolutely amazing.

There are a number of reasons why I run these events. And we'll come back to one of them later. But for me, I get the opportunity to work with our younger junior developers. Now, perhaps not this young, but sometimes when you've been around as long as I have, it kind of feels that way. But it's brilliant for me to work with these guys because I get to see their enthusiasm and how they work. I get to see what they're interested in, what technologies that they're interested in.

And it was here, really, where the story starts. So about two years ago, I was talking to our developers around one of these events, and there was a lot of buzz around Node. So I thought, "Okay, this sounds interesting. This sounds like something as CTO I ought to know a little bit more about."

So I set myself a challenge. I thought, "I'll get myself a Raspberry Pi. I'll get Node installed. I'll work out how it all fits and works together." And my challenge to myself was I'll build a home automation server.

So I found the framework I wanted, got my Raspberry Pi installed, up and running. I was really pleased with myself. Typed `npm install`, and then sat back and waited, and waited, and waited while hundreds, possibly even thousands, of chained open source dependencies were just streamed into my network at home.

Now, I won't tell you what my first reaction was, but my second reaction was, "Whoa, hang on. Is this legit? How do I know the veracity of these hundreds or thousands of components that are coming in?" And the simple answer is, I didn't.

So I switched the Raspberry Pi off and actually never to have restarted it again. But it really got me thinking. It really concerned me.

Now, we all know open source is important. So we understand that it's important to all of your organizations. But do we know, do we really truly know the level of dependency we have on open source?

So I was talking to Wayne Jackson, the CEO at Sonatype, last year, and he's not here today, so he can't stop me from telling this story. But he told me that he was talking to one of the CIOs at one of the top Wall Street banks. And he asked the CIO a question. He said, "Who's the biggest user of open source components or open source projects?"

The CIO said, "I don't know. Google?"

"No."

"Facebook?"

"No."

"Amazon?"

"No."

And Wayne said, "It's you."

So he wasn't aware of this, and I think that's a general thing that we get at senior management: that they're not aware of the huge dependency that we have on open source components these days.

Now, this is an interesting slide that I've stolen from Sonatype. And it's not uncommon now for 90% of an application to be assembled, 90% of the code to come from open source, and only 10% handcrafted.

So if you compare that back to when I was a COBOL programmer all those years ago, when it was 100% handcrafted, we've kind of flipped it completely. But even going back maybe eight, 10 years ago, when I stopped being a practicing developer, I might have used the odd framework, the odd XML library, but really, it's changed so much.

Now, if you're developers, you're obviously aware of this. But I think from a senior management perspective, it's not particularly well-known how the software supply chain has changed so much.

So I think the question you've got to ask yourself is, do you truly understand the risk? Do you truly understand the risk of all these open source software components that you're bringing into the organization?

So just to illustrate that, let's look at a few of the perhaps more well-known vulnerabilities. So Bouncy Castle, very well-known TLS vulnerability discovered, what was that, 11 years ago. But in 2016, nine years after this was discovered, out of the 23 million downloads of this project, 11 million of them still had the vulnerability. That's just a huge number. And ironically, this is a TLS vulnerability.

Something a little bit more recent, so the Commons Collections vulnerability here. A year after this vulnerability was discovered, out of 23.5 million downloads, over 18 million of them contained a vulnerable component. So 78% of those downloads were vulnerable. It's just astonishing numbers we're talking about.

So here's a slide I stole from Derek Weeks. I understand he's not here, so that's good. So he can't have a go at me for stealing this. But this is cybersecurity hygiene ratio. So in 2015, 6.1% of downloads from the Maven Central Repository contained vulnerable components. Last year, 2017, that doubled. So one in eight downloads from the Maven Central Repository contained some form of vulnerability.

So we go back to the risk. Do you really and truly understand your risk?

So it's something that I wanted to know. I wanted to really understand what our risk was. Now, I'm not here to plug Sonatype or give them any marketing, much as they might like me to, but I've worked with Sonatype to try and better understand what our risk was.

Now, I can't share those details with you today, but what I can show you is a photograph of me that was taken after I got the Sonatype analysis.

We'll move on quickly from that.

But how do we control this? How do we control the risk that's coming in, but still giving the developers the flexibility that they need?

Now, I call this speed with control. I think I might have stolen this from Jon Smart at Barclays, but I can't see him here, so if I did, I'll claim it. But this is what we're trying to do. We're trying to give the developers the flexibility they need, but still controlling access.

So this is a screen print of Juice Shop. This is the OWASP reference app that's deliberately built to be vulnerable, and this is the screenshot of the Sonatype product here.

So we can see here that it's very clear where you have policy alerts against a policy that you've set. You can see the critical vulnerabilities that you've got, and you can see the license analysis as well. Because remember, using open source and the risk associated with open source is not just about cyber vulnerabilities.

Not all open-source license types are created equal. And as an organization, there are certain license types you might not want your staff to use. So you can set up policy around license types as well. There's architectural risk as well. So there's a number of risks here.

We can drill down a bit. So this is the kind of screen that developers would see, and this is our old friend Struts. So the Struts 2. And you see where it says this version. This is the version the developer's using. And as you can see, that has the highest policy threat and the highest security threat. So it's very clear to the developer that they're dealing with a vulnerable component.

But what's also clear, and this is where it's really great for the developer, is that they only have to upgrade that component version, what, three versions, and that vulnerability's gone. It's cleared.

So that's how you get speed with control. That's how you get the opportunity to apply the policy that is required by your organization, but still giving the developers the flexibility that they need.

Now, the last thing that I wanted to do when I was looking at this last year was write a 30-, 35-page business case, which I knew nobody was ever going to read, and that was going to take me a week, two weeks to write, for something that seemed so obvious to me, so clear.

So again, I'm not averse to stealing the odd thing, so I stole this, I think, from Scaled Agile, and I think they're here today, so you can go and speak to them. But this is what they call a lean business case.

So the idea behind this is that you use this, it's one page, to effectively replace your 30-, 40-page business case. The key to this is the analysis. So now very handily, Sonatype were able to provide me that analysis, which I could plug straight in there.

And then what you define is your outcomes, and your outcomes must be measurable, and that's what we have with the leading indicators. Now, you can change the language here if you don't like leading indicators. You can call them metrics, KPIs, whatever works in your organization.

I think the proposal here is in Scaled Agile, they call it a hypothesis. So I didn't think that would work at our org, so we changed that to a proposal. But this worked brilliantly for me. So I took this to my CIO, said, "We want to fix this problem." My CIO loved this, said, "I want to see more of this," because the last thing he wants is to go through 35 pages of stuff he doesn't understand.

So finally, I want to circle back to tech fair. So I said earlier that there were a number of reasons why I hold these tech fairs, these events, and one of them is that we get the opportunity to start seeding some of the ideas within the development community.

So these are some photos from last year's tech fair. This is where we had Sonatype come in and demonstrate the product with our head of DevOps tools engineering, who's sitting at the back there. He didn't know he was in this slide, so sorry about that, Mike.

But the idea was that we could demo the product, and we were doing live scans. So the developers were coming along, they were giving their repo details, and we were actually doing live scans so they could see the product in action. And the idea being that we're warming them up to this, that this is coming, so that when we do the rollout, it's much easier. They know what's coming, and in fact, we're generating interest. It's something they want to do.

So with that, I'll hand it over to questions. But I would say that I am not an expert in the product, but we do have experts here, I think. So if there are any questions to do with the product, I'm sure Sonatype at the back.

Q&A

Q: Yes. I work at Volvo Cars. We don't use a lot of open source.

A: Yes.

Q: The security risk we have is more on license.

A: Yep.

Q: How well do you cover that?

A: Yeah, we care about it a lot, but perhaps not as much. I work in a bank, so our primary concern really is about cyber risk. But yes, it is a concern for us, and we are able to use the product to define what particular licenses that we're interested in or not interested in.

So I particularly don't like the strong copyleft licenses. I'm sure you're the same. But I think we did find, Mike might be able to shed some more light on this, but we did find when we installed the product that we got some really unusual things.

So we got open-source components which purported to be under Apache 2 license, for example, but then we found out they'd been changed. So we had absolutely no idea we were going to see that issue at all, but the toolset highlights that for you.

Are there any other questions?

Okay. Well, I hope you found that useful, and I'm happy to talk through anything after the event if anybody's interested.

Thank you.

Thank you.