 I'm going to go ahead and get started. My name's Jeff Borek. I've been working in open source for over a decade at IBM. And for the last six years, I've been running part of the IBM Ospo, the open source program office that's associated with the IBM license clearance function. And I'm going to spend about a half hour to kind of bring you up to speed on what's happening around the evolution of the supply chain security concerns about open source. You've heard a bit about it already, I'm sure, if you've been at some of the keynotes. More than happy to make this really interactive. So if you have questions, feel free to just raise your hand or shout out. And we'll make this as interactive as you guys would like it to be with that. Also, feel free to follow me on Twitter or if you have any questions that we don't get to today. My contact information is up on the main slide here. All right, I'd like to not be trapped behind the podium, so I'm going to move around a little bit. But I think one of the things I really connected with when I was doing some research for this talk was this concept of the interplay between cybersecurity and regulatory compliance. And this is some findings from a MIT management Sloan School report from earlier this year. Cybersecurity is responsible for the internal procedures established by a company to basically protect itself. And compliance, on the other hand, is essentially what companies have to do to make sure that they're on the right side of legal and regulatory affairs. And regulatory is this ongoing process of adhering to these guidelines to make sure that you're doing everything you need to be compliant. They've got similar goals around securing data and assets. They want to do the right thing for the organization. But compliance is primarily driven by enforcement risk. Anyone have an idea of what that means? Enforcement risk? Essentially, the concept is, it's like obeying the law. Don't jaywalk. Don't speed. You've got to stay on the right side of the law. The cybersecurity is focused on the concept of protecting the business. And to use the same metaphor, it's like, don't walk down a dark alley. Don't go or don't allow your business to go anywhere where you might get ripped off or be vulnerable to a security risk. And that sets up an interesting dynamic. Because the stakeholders that are looking at these two issues, they both agree that they're important, but they often have different conflicting goals and priorities depending upon their perspective. And you can see the various constituents that have to get involved and play and all have something to say about this space. Whether it's your legal group or your organization's leadership, the security professionals that your group employs, and there's a whole mix of different security professionals that can weigh in on this, financial professionals that look at the numbers behind trying to assess what the legal risks are, country and international stakeholders. And what I think is really fascinating about this is that you can be compliant without being secure, and you can be pretty secure without being at all compliant. And that's sort of like nonsensical to me at first. But the more I thought about it and the more I read on this, the more it really makes sense. And so it really sets up a situation where there's this complex interplay and it creates opportunities for getting off the rails or misstepping or not getting your organization to where you want it to be. Poor compliance oversight and management, difficulty in developing and implementing these regulations, appropriate allocation of resources, how do you, everyone's got limited resources, especially throughout the pandemic and now with the other economic shocks that are happening. So there's never going to be all the resources you need to completely cover the basis. So you've got to make good choices about where you do invest. And another big part of this is just the whole culture issue. Does your organization have not just a security group that's kind of off to the side or a GRA or government and regulatory affairs group that worries about this or a product security group within your organization if you happen to be a vendor in the industry? And at the bottom line, the cyber world is just moving too fast. Standards bodies are having a hard time keeping up. And there's an interesting metaphor or analogy, if you will, to this with respect to how open sources change the ecosystem in the last 20 years, because go back 20 years in information technology and industry standards were how interfaces got established, how customers dealt with trying to avoid lock-in, how different vendors tried to establish interoperability. That was all done through traditional standards bodies. And then over the last two decades, but really accelerating in the last seven or eight years, is that standards organizations have kind of taken a back seat because the open source process generates code so rapidly that they outpace the standards organizations. And so the same thing is happening here in the security space. And that's both potentially a good thing because it could be part of the solution, but it also could be problematic. And I like to look at both of these graphs when we talk about what's really changed. Because some people say, Jeff, open source, is it inherently flawed? Is it bad? I mean, I've had some management start to push back to say, maybe we shouldn't be using open source because it's not secure. And actually, studies have proven that whether you develop code out in the open in a distributed fashion versus behind a firewall in your corporate data center isn't the primary determinant of how secure that code is. There are other factors as to how secure that code is. And so open source is neither more or less secure than proprietary code. So why is it a problem now? Well, as you can see on the graph on the left, about five years ago an average enterprise application had a little over 80 open source packages bundled in under the covers. And that's something that's been going on. IBM is an early entrant where it saw the value of consuming open source and essentially code reuse as opposed to writing everything from scratch. But fast forward to today, that same enterprise application is now likely to have over 500 open source packages bundled under the covers. The applications are more sophisticated. What you can do with the components and reuse is more compelling. And it's just created this huge attack surface. So again, it's not like open source is inherently flawed or bad. But the other low hanging fruit of how to attack an organization through software has already kind of been substantially deterred. And so the sheer volume of open source and the inherent nature of being frictionless and the fact that you can just, a software developer can go out, grab a package, adopt it, use it in their application has created part of this challenge. The other graph on the right side here, spending on enterprise software worldwide. So clearly we're in the era of cloud, right? And cloud was going to, according to some analysts, seven or eight years ago, cloud was just going to decimate the enterprise software business. Well, guess what? It's kind of like everything else in the information technology industry. It's like customers never stop buying things. And customers rarely unplug things. And so therefore, you can see by this graph, the enterprise software business is vibrant and growing rapidly. And we'll have to wait to see what happens in 2023. Everyone quickly light a candle for the economy. But the point is, is that all of this enterprise software, you can imagine that you can change the color on that bar at the three quarters mark. And that would tell you how much open source is in that software. Boom. So that's part of the reason why this has become critical now, is that the sheer volume, again, of open source consumption in the enterprise has just gone off the charts. And this process of source integrity and build integrity, when a developer is putting together a solution, this shows you a representation of all the potential weak points in the chain where a bad actor could bypass a code review, or they could intercept the CI CD package. They could, any one of these links in the chain is a area of higher risk. And as you can see by the statement at the bottom there, 84% of open source code bases had at least one vulnerability in them with an average of over 150 in a typical code base. So it's, again, software is written by humans, at least it's up until maybe another year or two or three. But for the most part, humans are flawed, and there's always going to be opportunities for threats to emerge. So I started losing sleep about this in my role at IBM about five years ago. And I started talking with my management, talking with the open source community and the context that I had. But there was still a lot of uncertainty as to, is this, sure we're going to have to address this sometime, but maybe not this year, and maybe not right now. And finally, about three years ago, there was this collective understanding that, look, we can't kick this can down the road anymore. And so conversations that IBM was having, Microsoft was having, Google, everyone started to kind of get their head wrapped around this idea of that this is one too big of a problem for any one company to solve. This is a problem that occurred over the last 15 plus years. And I'll be transparent with you and maybe make my management uncomfortable. But when IBM first started doing open source two decades ago, it really invested in a crack legal team that understood this emerging open source license space and invested time and figured out that, yeah, this is kind of sketchy, this early open source thing, but we can collaborate with it. We can come up with ways to sort of sandbox the IP or legal risk associated with these OSI open source licenses. And yes, in general, and we won't turn this into a license review, but you've got restrictive and permissive licenses. So IBM really was ahead of the curve with this how to nurture and at the same time, protect open source. There's something called the OIN, the Open Innovation Network. IBM actually donated patents to that to help bolster the industry and to kind of put a dent in patent rolls in the early days. Lots of other interesting background. But the net of it is that just going into just about two and a half years ago, we gathered at the Linux Foundation and said, hey, now is the time. And then the pandemic hit. So at that point, no one was really ready to pull out their checkbook, no one was certain what the next two or three years of this pandemic would bring. But there was a lot of best efforts, collaboration for the last 18 months or so in the actually last 24 months around, let's see if we can get something done without a lot of funding. And some things were accomplished. But by and large, last fall, the industry got back together again and said, hey, we delayed another 18 months. We can't delay anymore. And this press release went out. And as you can see on the right side, there's a quote from the GM that I worked for. Jamie Thomas, a great individual. And this is actually one of the more significant accomplishments that I was able to help pull off in IBM last fall. Because Jamie, as a GM, is the most senior executive at IBM directly engaged in an open source community in the last 10 years. And it's really been good for both the community and great for IBM to have someone at her level understand exactly what's happening here. And she happens to have been elected the board chair of the organization. So there are some working groups that are a key part of kind of think of this fall announcement is OpenSSF 2.0. So the governing board kind of did a reset. The technical advisory committee of the organization, they elected some new memberships. So that's kind of another reset. And right now, the working groups have been making some progress. And they're going through a bit of a reset as well. There's also some really interesting projects that have been emerging. And companies like Google and Red Hat and Microsoft and others have all been bringing forward interesting concepts about not just working groups, but let's bring some code here. So Salsa, supply chain levels for software artifacts, it's a framework you can use to help measure your organization and its performance. The graphic in the middle is a scorecard. It's a way of trying to automate and evaluate projects to look beyond just how many security vulnerabilities they may have to other metrics that would help determine, to some degree, the quality of the project. And SIGSTOR is another, Alpha Omega is another. So lots of interesting things that are coming up on the radar. One of the other things that has driven this focus is that almost exactly at maybe 54, I was going to say a year, but 54 weeks ago, the White House issued an executive order on cybersecurity. How many heard about that order? I'm just curious. Just about 95%. So it's funny how when the White House does something like that, people tend to pay attention. Certainly one of the most significant drivers of this was the SolarWinds incident, which wasn't an open source related cyber attack. But there's this realization on the part of the government. And if you haven't heard this metaphor, I think it's also somewhat useful. What's happening in the software supply chain today is not unlike what happened in the package goods food industry in this country about 50 years ago, plus or minus. And when I was a little kid, the cereal box that was on our table didn't have any information about what was in the box, really. And now you can't buy anything in a grocery store without a detailed analysis of the ingredients. That's what's coming for the software industry. And that's what's coming for open source. So one point, though, I want you to take away from this topic, how many have initiatives within their organizations that are trying to produce S-bombs currently? About half. So the other half of the room, you're not that far behind. But what's key about this is that what you hear from the government is that create an S-bomb and publish it. Publish your S-bomb. That's where we're all going to eventually have to go. But if you take away only one thing from my talk this afternoon, it's that, yes, get started with S-bombs. S-bombs are part of your future. And you want to start your learning curve now. But once you produce them, don't share them. Use them to begin to remediate the challenges you find when that S-bomb reveals exactly how exposed you are. And God forbid, we'll have other interesting issues if I'm here a year from now. And in the last 12 months, people have been passing S-bombs around like baseball trading cards. That wouldn't be a good thing at this stage of the industry. So some minimum requirements. And I want to leave some time for questions. So I'm going to be very brief on this. But S-bombs are not inherently as scary as you think. But it's going to require a cross-collaboration throughout your organization. So don't leave here thinking that, well, the Office of the CISO or the product security team or the IT department is going to be the one that's going to take care of this for the business. It's going to require a multidiscipline approach in your organization. And the other thing that I'll say about this is that it's a great opportunity for you to just modernize your software development organization in general. Because if I had a dollar for every time I've heard CICD at a tech conference in the last three years, I'd be a wealthy man. But the truth of the matter is that organizations aren't changing or adapting as fast as they need to. And this is an opportunity to both begin to become compliant as well as to improve your chances of continuing to evolve to be a leading digital organization. The other thing about this is that that table shows you the bare minimum. But there's a lot of interesting things that you might want to collect when you start to put this kind of infrastructure in place in your organization. So think of the data schema and think of what else you might want to do to capture information about your supply chain so that you can improve your business's performance. And then you can decide for yourself looking at the regulations as to what you really need to or have to share. So I mentioned the fall reboot. In the first quarter of this calendar year, there was a follow-up meeting that was, again, hosted by the White House. It ended up being a virtual meeting. But it brought back some of the leadership that had attended the initial kickoff. And it focused specifically on open source. And that led to this follow-up meeting that happened in Washington DC just a little over a month ago. And the Linux Foundation, to their credit, saw that the follow-up from the first quarter meeting was delayed because of world events, conflicts in Europe, et cetera. So the LF raised its hand and said, hey, look, we'll host this meeting for the second quarter because we think this is too important to delay. So it was really well received by the White House. It was really well attended by both industry leaders. Why is that? Pardon me one second. And in the run-up to that meeting, the governing board and the subset of the open SSF created this open source software security mobilization plan. I don't have time to go into it, but the net of it is I'd encourage you to use the QR code, get a URL, or just Google it and find the PDF. But it's a basically think of those early working groups and the work that was done for the last 18 months. This meeting used the opportunity to step back and say, well, if we could bring additional resources, what are some of the other major things that we really learned in the last 12 months that need to be addressed? So this 10-point plan was delivered to the government. It was really well received. And as you can see, other organizations stepped up and added to the funding, Amazon, Ericsson, Google, Intel, Microsoft, VMware, all pledging up to $30 million. And it's definitely moving in the right direction. So what has IBM specifically been doing in this space? Well, one of the things I'm very proud of is that in that meeting, the original meeting at the White House back in August of last year, Arvind Krishna and the center there flanked by the Apple and Google executives came out and stated that we'd partner with more than 20 historically black colleges and universities to establish cybersecurity centers in their organizations to try and help grow the funnel of cybersecurity experts that can help with the next 10 years of remediation of these challenges. And another interesting fact that came out of my looking into this was that IBM teams use cloud and AI powered software to manage 150 billion cybersecurity events each day for more than 17,000 commercial and government clients worldwide. So again, that just gives you an order of magnitude of just the challenge that the industry is facing. When we went to the meeting in the first quarter, we went with our colleagues at Red Hat. And Red Hat's division of IBM, it's an independent division of IBM. And they brought a point of view from a Red Hat perspective on the challenges as they saw it. We at IBM established another policy statement that went up again about a month ago. And if you have the chance to check it out, it's only about a five minute read. But it talks about this from a government and regulatory affairs more of a policy perspective. So your colleagues in your own respective GRA organizations will be interested in this. So I'd encourage you to check it out. So how OSPOs can play an important role going forward. So we've talked about some of the advice that I've shared throughout the talk. But to reiterate, this is going to be a team sport. So if you're starting your journey towards creating OSPOs, start to look at your data schema needs, start to look at your use cases, think about the different constituents with your organization that need to address this. Lots of vendors are popping up saying, hey, you can buy my tool and it'll produce S-bombs for you. And I'm certainly not here to throw shade on any vendors. But it's not that simple. And you don't want to just believe that you're going to be able to spend some money, spin up a tool, check a box, and sleep well at night. It's going to take a bit more than that. The other thing I'd like you to encourage you all to do would be to consider getting involved directly in the open SSF. There's a number of different tiers of participation. You don't have to write a $10 million check to start to participate. And the TAC, the OSSF TAC meetings are open to everyone. The next one's going to be Tuesday on June 28th, so just about five or six days away. The presentation is uploaded into the system. So all of these are links to those connections. The meeting minutes are also posted there and then there's a, if you're not getting enough business meetings during the day, at night you can go on the open SSF YouTube channel and start playbacks and catch up with some of those meetings you might have missed. Yes, exactly. I don't know that it's going to make it to Netflix, but it is up on YouTube. Mailing list, Slack channels, GitHub issues. So there are lots of relatively efficient lightweight ways for you to start getting up the learning curve and getting your organization involved. It's going to take a village. It's going to take broad participation across the industry to address this. But I'm looking forward to sleeping better at night. I don't know about you, but when these, the other thing I guess you could think of this as well is if this is something that you're getting involved with for your business, I can almost guarantee you it's three to five years of guaranteed employment at your organization. Because there's a lot to do and it's going to be a high priority for them. If it isn't now, it will be in the not too distant future. How am I doing on time? I've got a minute or two for questions. So feel free. If I don't know, I'll readily admit it. If I kind of know, I might make it up a little bit. Have a microphone coming around. Thanks, Jeff. Good presentation. Beyond the S-Bombs, and I know you had a very large host for organizations, so can you share with us some of the activities that you do around security, around making sure that the software that keeps changing, opens our software that keeps changing. You want insider knowledge. You want water cooler dialogue. Well, no, I'll be, again, up front with you. So if you think about an OSPO in its simplest form, an OSPO is all about how do you consume open source in the way your company believes is the right way to do it? And the other is how do you contribute back to open source? And hopefully your organization does it in a balanced way. When I talk about IBM, I like to say I stand on the shoulders of giants because IBM leadership 20 years ago, when I couldn't spell open source, really understood the complexity. And sometimes I use the metaphor of open sources like a large crystal. And if you see it across the room, it just looks interesting. But it isn't until you walk across the room and pick it up and hold it up to the light and look at all the different facets that you start to realize just how complex and how powerful the open source ecosystem can be. And specific to your question about interesting facts, IBM, I spent the last six years prior to this fall focused on trying to help lead IBM's renaissance in open source while also managing that compliance function and doing all sorts of other things to energize IBMers to get active in open source again in a more meaningful way. IBM never left open source, but I think it's fair to say about a decade ago, IBM instead of leaning in like it did for the first year started kind of leaning out, focused more on like intellectual property or other innovation areas. But an interesting data point is that when working with Jamie on this issue, she said, well, where is IBM contributing today? And you can go on to our website and you can see a list of some of the featured innovative product areas that we've been working in. And that's all great. And if you take IBM's participation in open source and add it to Red Hats, even though we're independent and they have a strategy and we have a strategy, those two numbers put us on par with all the other major companies. So in fact, one shows that we're the leading contributor. But what we also found working with Jamie is that IBM had been contributing in these new innovative areas like Kubernetes, K-Native, and IBM's participation in some of the more traditional open source areas that had been around quite some time had fallen off. So if you drew the Venn diagram of where IBM was participating and where a lot of our products are still dependent, it was not the kind of overlap you'd want to see. So one of the things I'm doing today is helping to re-energize some activity in some of those traditional spaces where IBM might have been or has been missing. So great question, thanks for that. They're gonna give me the hook soon, but there's time for one last one going once. All right, well, really enjoyed the session. I hope you found it interesting and I hope you enjoy the rest of, gosh, what do we have? One session or two left before the day is done and a half day tomorrow. So thanks again for being here, appreciate it.