 Good morning everyone. Is this too loud? Should I move the mic down a bit or is it okay? At the back, everyone's happy, okay. So good morning and thank you for coming to my talk. My name is Shane Coughlin. I've been involved in open source now for about a decade. Actually, to tell the truth, I've been involved in open source since 1998 when I entered the high-tech world of Freedos and helped package the graphical user interface free gem for that. But I started working in open source a decade ago. I've been working in open source around the area of governance for these ten years. I focused on license compliance when leading the legal department of Free Software Foundation Europe. I focused on patents and cooperation when acting as global director of licensing at Open Invention Network. And I've also worked on various issues around supply chain management. Most recently, by way of example, I'm the chair of the open chain curriculum where we're building supply chain management processes that are freely available to all companies that want to implement world-class processes and world-class specification for managing open source in the supply chain. It's a Linux Foundation project. I'll talk about it a little later. Insignary is the company that I'm with. We're focused on dealing with binaries in the supply chain. We essentially have a technology that allows us to do some scanning into binaries to find out what open source is there and what security or compliance issues exist without undertaking reverse engineering. Now, today's talk is about security and IoT. I'm very interested in this topic because I think that IoT is going to be dominated by open source. And in open source, we haven't always put security first in how we develop, deploy and maintain our software. Let me explain why I think this and how I think things will develop next. The first point would be that open source is everywhere. Nowadays, open source is undoubtedly used by the vast majority of companies for the vast majority of purposes. There is a survey, a yearly survey, run by Black Dock Software, the future of open source survey, they call it. And there are some startling numbers out of the 2015 survey. One is that 78% of surveyed companies are using open source to run their infrastructure, let alone their products. And only 3% of surveyed companies said they don't use open source in any way. And that 3% figure itself is fascinating to me because in my job, I meet a lot of companies involved in mergers and acquisitions. I meet a lot of companies involved in scanning technology. And every company that I've spoken to who does mergers and acquisitions or has scanning technology tells me that they always find open source in every company. So I rather suspect that the 3% of companies that said they don't use open source just missed it. Another fascinating number, and this is a really important number for IoT especially, is that 89% of surveyed companies said that open source increases essentially their speed of innovation and their time to market. That the open source as an approach to dealing with software is just better when you need speed. And obviously around areas like consumer IoT, that's going to be critical. And that's one of the reasons that open source will be dominant in IoT. Now, these numbers represent the opinions of a lot of different companies in a lot of different industries. And they do give us a strong indication that a lot of people see great value. The next question, as you can probably guess from my accent, I'm from the British Isles and we're famous for being skeptical. The next question is what's the catch? This is fabulous. So what's the catch? And because we're talking security today, that's the catch I'm going to focus on. We have had some interesting, and I mean interesting in a completely neutral way, some interesting public exposures around open source and security in the last couple of years. Heart bleed, shell shock, freak, ghost and venom are two examples. And what's interesting about these exposures is that they were discovered by manual analysis. Static and dynamic tools to find security vulnerabilities did not discover these problems. And some of these problems were open for quite a long time. Look at this, 1989, until 2014. That's not really a fantastic amount of time to have a security vulnerability in the wild. So that is a bit of a catch. Now, of course, my majority in this room were people who are either engineers or very tech savvy. So we know that it doesn't matter if you're using proprietary or open source software, all software has bugs. The difference is that in open source we talk about it more openly. We do things like put these slides up and say, that's not good, how do we fix it? In proprietary software people tend to be less open about what's going on and have less ability to share information. But yes, we have had some serious security vulnerabilities discovered and we did not find them with automated tools for static and dynamic analysis. That is a concern. And it matters because this virtually unreadable graph, but important graph, this comes from AVTest, a German company, and this is a fascinating graph that just shows malware. Malware out in the wild. So here's, for example, 2006 and here's 2016. So we're seeing a lot of rather hostile software, an escalating curve. And when we have an escalating curve of things like malware and we have the issue that software has vulnerabilities and we're talking about things like smart homes, IoT, connected infrastructure, it becomes quite clear that we need to do something about this. Gartner had a very interesting survey, opinion about open source. Essentially they said that open source is going everywhere. It's being adopted everywhere and it's doing fantastically. But because of being so successful, there will be more security and quality defects discovered and attributed to open source projects precisely because it's mainstream. Now our challenge in open source is that as we go everywhere, as our defects are discovered, as our processes to prevent defects are found to need improvement, how do we do that? How do we improve our processes and how do we make sure that we correct our errors? We need to think about this very seriously. You're probably bored to death of seeing numbers like this, but the Drown Attack left 11 million websites using open SSL at risk. And I don't know if you followed closely the updates on websites, but an awful lot of websites didn't update very quickly to correct their potential breach. That's not good. And that's a website. That's very easy to update. That's very easy to patch. In Korea recently, there was an IoT breach. Harmless, it was just a prank. A transport information screen was hacked to display pornography, which was just a prank. But as we deploy more and more smart infrastructure, we need to stop that because the guys who are doing pranks are not the guys behind the majority of malware and they're not the people that we need to worry about. But the fact that a prankster can do that, we need to worry about. So open source security is a big deal. It really is. And it needs to be at the top of our list when we are talking about open source in areas like IoT. What do we do? How many of you are familiar with compliance, open source license compliance in this room? Quite a few. That's important and that's good because I think it's fair to say that we have a lot of documentation for processes, documentation for workflow, and documentation for training around open source license compliance today. We also have tooling available as well. We have proprietary and commercial tooling. We have open source projects which allow us to automate aspects of compliance management. I'll just name a few. Don't worry, you'll be able to find these on the open chain project later. But an example is Phosology, an open source license scanner. It allows you to dig into the licensing information of your files. A commercial example of BlackDuck is an obvious one. They analyze source code. But we're only starting to see the evolution of similar processes, documentation, tooling, automation for open source security. Most companies actually don't use any yet. I'm going to bring up another number, BlackDuck Survey again. This is not a good number. 67% of companies surveyed say they do not monitor open source for security vulnerabilities. That's not a good number. Now of course, the engineers in the room will point out that that is also a vague number because some of the companies surveyed outsource, the management of their open source to someone else. For example, they might only be using Red Hat Enterprise Linux and they might have a support contract with Red Hat. They don't need to monitor for vulnerabilities on Red Hat Enterprise Linux because Red Hat is doing that. All they have to do is update as soon as Red Hat pushes an update. When you have a number that high, it's quite clear that a lot of companies who should be looking at open source for security vulnerabilities are not. Now, we need to pull to the big picture. We need to think holistically about this. We need to think about how we manage this problem. The situation today is that an awful lot of people are using open source everywhere. A lot of people are using open source in IoT. Quite a few players in IoT are small companies or new to open source and they're essentially downloading and using code. Very few players in the field have the experience to do things like manage security comprehensively. So we need to think about how do we address that systemic challenge to making sure that when we use open source in IoT, we get the best possible result to address something like the security challenge. Now, I'm very positive about this. I actually don't think we have a problem. I think we have a great opportunity. We can't neglect this. I mean, we just can't. IoT, automotive, smart infrastructure need security to be a first class citizen. I speak with companies building trains that contain open source and they're deploying trains and updating the firmware on a train is non-trivial. You need to have it fairly well set up. I speak to companies building smart cars and it's the same deal. It's no joke if you deploy millions of cars and then it's hackable. So the community needs to evolve and it will evolve because we've done this before. We've done this before. We did this with license compliance. Ten years ago, when I started working in license compliance around open source, things were basically a mess. In Europe especially, America was a little bit ahead of us and Asia was largely a black box. The Japanese companies had their internal processes, but they didn't really communicate them to anyone. In Europe, each individual company was doing its best, but most were on the early phase of open source process management for compliance. Within ten years, that picture has completely changed. We now have very sophisticated compliance management all across open source. And the way we did it to solve the problem was open sourcey. We collaborated to create deliverables. We identified the core problems. We then proceeded to decide what needs documenting, what processes we need, and then what can be automated through tooling. And after doing that, we started to share the information with each other as far as we could through the supply chain. Open chain is probably where we need to start, and this is deployment processes. Open chain is a deployment specification. It's a way to manage your supply chain. And I strongly recommend that everyone in this room goes to this website, openchainproject.org, and has a look at what open chain is up to. Because it's best in class example of process management for supply chains in open source. Compliance today, but not limited to compliance for the future. It was just launched, actually. Gillian Lovejoy from ARM gave a really great speech, which included skateboarding metaphors on the 4th of October at LinuxCon Europe. But we've been working on open chain for about two years, and an awful lot of companies are involved. This process for managing supply chains essentially dramatically reduces the chance of compliance errors today. And one of the key aspects, an important aspect in my view, probably because I'm chair of this part, is great training materials. I believe that open chain is the first initiative to release open source compliance training slides into public domain using CC0 licensing. Best practice material from large companies like Qualcomm, ARM, Samsung, combined into a slide set, designed across around 70 slides, across seven chapters to help companies get started with best practices in compliance management. And you can get those slides today right there. Release one of the slides is available in English. And we have our first translation already set up for Korean. We have a volunteer from LG Electronics translating, so we should have a Korean version soon. I'm hoping other people will step forward to give us Chinese, Japanese, and so on. Now, once you have a deployment process, open chain is a great example in compliance, then you often need an update process. This is something where in IoT I've noticed a giant gaping hole. A lot of people do things like make smart light bulbs and just throw them out to market, and there's no update process, which would be great if software was perfect, not so great when software is imperfect and all software is imperfect. Updates obviously go far beyond features. Software will always, always, always have bugs. And this isn't just a security issue, this is also a compliance issue. I mean, whether you're deploying a light bulb, a car, a home, or a bridge, you need to think about what do we do if a critical bug is found? A compliance bug? A feature bug? A security bug? How do we update it? And actually, we're still pretty immature in that, in both compliance and security areas. For mobile devices, it doesn't really matter. You just send an over-the-air update. But when I talk with people building large infrastructure, I mentioned trains earlier. You know, it's actually difficult to update a train. All you need to do is stop the train, plug it in, and update the firmware. But the thing is that when trains are in deployment, they are busy, and they're busy on the tracks. It's actually hard to schedule times to take trains off the tracks and update them. When you have a bridge, that's a challenge. You might have hundreds of devices on the bridge. Have you set them for update? Are they truly interconnected? Think about that. Cars, billions of connected IoT devices. That's interesting. IoT devices that are inherently connected to your smartphone app, but don't necessarily have a way to update themselves if there's an error. We need processes for that, and we probably need to share that information around those processes in a much better way than we do today. While we manage to do deployment processing sharing, we haven't done that well on update process sharing yet. Now, once we have all those processes and training materials in place, next step is automation. Automation is an area where I've spent a lot of time, and it's very simple. Humans can only do so much. We need to automate as much as possible of everything that we do regarding maintaining our technology. So today, example automation with compliance teams. This is an area I'm very familiar with, so this is my example. It usually comes in the form of tools that check source code or binary code, and these tools help you meet process requirements. The best tools essentially really do know the process and can tell you, yes, this incoming code matches requirements. It matches the SPDX requirement and fits into your known requirements for OpenChain, for example. Now, I'm going to call out some of the tools, and this isn't endorsement, it's just to call out one project and one company in each area. So in source code, we have Phosology, which is a really interesting project initiated by HP, but with a large ecosystem of users now. And we have Black Duck ProTechs, which is a product, a proprietary product for scanning source code. Other tools, binary code, there's the binary analysis tool that is actually primarily maintained by my company. It's an open source project under the Apache license. And there's CodeNomica, a proprietary product to market, which looks into binary and also has some aspect of open source scanning. That's what we did in compliance. We need to kind of do the same around security, in my view. So my question is, what is coming next? And I bring to the table, ladies and gentlemen, a bit of a wish list. I should probably mention at this stage in the talk, which may be quite late and lose me all my credibility, that I'm a political scientist, not an engineer. But I am a political scientist and a researcher specialized in military communication networks. My specialty is net-centric warfare. And with that type of policy mindset, I bring my wish list for what we need to do next for open source and security. First of all, security needs to be a first-class citizen. Too many people take it too lightly. Too many engineers are blasé about security. Oh, I can patch it. That's great. How will you patch it? What's the process? Too many companies are blasé about security. Oh, it's too expensive, and besides this code is fine. It's mature. Really. We have those interesting statistics about how many bugs per thousand lines of code you find on average. Open source does well, but it still has an average number of bugs per thousand lines of code. We need freely available materials to actually help people train themselves in security and process management to bring them up to speed. The vast majority of our suppliers, especially around hot new areas like IoT that depend on lots and lots of little companies all over the place, the vast majority of these suppliers have no idea what they're doing with regards security and open source. They just don't. It's not their fault. We need to make the materials to help bring them up to speed. And we need a selection of projects and commercial proprietary solutions dedicated to helping address the challenge of open source security in deployment processes, update processes, and automation. In other words, what we need for security is exactly what we have in compliance. Now, very quick case study, how my company is dealing with this because we do security as well as compliance. Our catchphrase, get confidence through clarity. Our product is called incinerary clarity. So you see we're very smart. So we launched on the 4th of October. We've been working on this for a long time. We've been working on this company for quite a while, and it's based off an open source project called BAT, or the Binary Analysis Tool. BAT has been deployed to market for over six years, primarily to address compliance issues. But more recently, the open source project has also had security features in collaboration with the Dutch National Cyber Response Team. The Binary Analysis Tool is pretty interesting, and this is the open source project. I'll put up the URL in a bit, but basically just Google Binary Analysis Tool. No one else has made an open source project in this field. It uses symbol and string table comparisons, fingerprinting, to identify code in firmware without doing reverse engineering. Now that's important because you cannot do reverse engineering in legal jurisdictions like the United States. You can in Europe, for example, but not in the United States. It works in a very simple way. Every engineer in the room will just say, well, that's kind of obvious, and it is. Extracting binary files, locating identifiers like strings, functions, and variables. And then other method data like filenames and packaged database names to increase fidelity. No magic, no black box, and go get the source code and have a look. It's Python. It's designed to be effective in discovering real world open source issues. The CTO of my company, Armin Hemel, was one of the main people involved in gplviolations.org. And he said one day, I want to automate compliance engineering. So he did. And it's able to help monitor supply chains by automatically identifying open source code. Customers and supporters of the project over the years have been pretty significant. It's seen widespread use. It's been a lot of feedback. You can go and have a look at the code. It's iterating pretty quickly, actually. This is the project website. This is a terrible website. Our CTO made the website. It does not. I'm business development, so I'm going to take over that website and make it prettier. This website is currently maintained by our company. But we're actually moving the BAT project into the Anelnet Foundation Commons Conservancy in the Netherlands. Because we believe that it's very important that it's very clear that a project is a project and a company's product is a product. We have our own product built on top of this. We use this as our engine. But to ensure that it's very clear that the open source project is a real project, it will be moved to the Anelnet Foundation Commons in the next couple of months. You can follow our GitHub repository right here. John Hemmel is the CTO, and the commits happen pretty quickly. Version 27 of the code was released a week or two ago. Version 28 is queued up soon with a bunch of new features. This is an engine. It's a modular framework, and it's pretty powerful, a little bit geeky, and the user interface in the open source project is not human-friendly. If you're happy with the command line, this is an excellent tool for digging into firmware. Clarity, the commercial solution we do, a very brief overview on this one, because it's not a sales pitch, high-level overview. It basically increases fidelity, data sources, and packages everything for cloud or on-site deployment. You can either use its own user interface, or you can plug it into things that you have. For example, I don't know if you're aware of this, but large companies like Siemens are building tools like SW360 to run phosology. You could plug this tool into that and get the output through their interface. It's basically designed to do the normal security thing, identify, prioritize, and address concerns. So it has a look at security issues and compliance issues, and it's meant to help teams, not replace teams. Some companies, when they talk about tooling, make it sound as if you can use an automated tool and replace your in-house team. No. You need to support your team, exactly. You need to basically find ways to support your teams to do their job better. Our tool is designed to help teams do their job better, and this is the workflow, no magic. Again, very simple. In fact, this is the workflow everyone in the world probably uses when they're trying to do something like analyze a binary. Where we have some advantages is that when we are doing our filtering, we have some pretty clever ways of filtering out known files that we know very well, and we don't need to spend time digging into, and we have some pretty cool stuff for checking in context. Checking in context is basically, well, that looks like this. What is it? This is a cool thing. I'm bringing this up because I think everyone will do this soon, but currently we're the only person doing it. Almost everyone looking at binary code from suppliers does exact matches. They use checksums, which is great if what's included is an exact match. But if even one bit has changed, your checksum no longer works. So to address that, we're using virus scanning technology. So we do fuzzy matching or, in engineering terms, similarity matching. We use an open source library, TLSH, from Trend Micro, to allow us to do similarity matching with code in binaries. So, you know, your binary can be found in this package. Your binary looks an awful lot like this. It allows us to find code that has been slightly altered and to match it and to say, oh, that's interesting. That really does appear to be this open source component with this percentage of change. Find out more, just visit our website, or just email me. Happy to tell you. And I would stress that our tool is not the only tool in the market, obviously. It's just the one that I know best. But I think that for security purposes, we have relatively few tools like that right now to help with things like supply chain management, CodeNomicon, I would call out as a company that can help you do that. Though I think if you compare the results from CodeNomicon and the results from our tool, you'll find that we beat them on open source fidelity. Though they have a broader range of scanning in open source. I mean, in binary code than we have. We're focused on open source. Not alone. So CodeNomicon called it out. Binary analysis. They do have some open source binary analysis. Good Lord, the thing pinged. Black Duck Hub. That does some, checks some matching. Very good for stuff like Java code. And of course, there are other commercial tools available for binary analysis as well. Some of those tools are relevant to what we need to do and some are less relevant. I'd say those two are the most relevant today. CodeNomicon for general binary analysis. Some degree of open source support. Black Duck Hub able to do things like help you if you're concerned about what you're pulling down from the Maven repository in Java code. In signery is quite frankly much more focused on embedded code. We're much more focused on embedded Linux. So our solution is more targeted towards the embedded IoT automotive market. And we're very focused on open source. We don't scan for other stuff at this point in time. Okay, big picture again. Security is what you make of it. Open source has fantastic potential. Open source isn't actually about code, of course. We know open source is really a method of dealing with a knowledge good. Open source is a method of dealing with software. And it's probably the best method we ever found to deal with software. In potential. But to realize the potential, you need to have good processes and best practice. And that applies to compliance, to security, or to making good products. Improved security in open source is coming. I said I was an optimist. I meant it. You can expect more best practices for security in open source very soon. A bit of a spoiler. A bit of Mark Gesey's in this room. No, good. Excellent. I'll pre-announce him. In Open Chain, we're looking at having essentially modular aspects to the specification that allow you to expand it beyond compliance. And one of them is security. How do you manage your open source security process? And that's something that we're looking at having in 2017. And we're not the only people looking at this stuff. On the tooling side, you can expect the emergence of a range of tools to help you deal with things like security. Right now, there's a couple. There's the binary analysis tool open source project. There's incinerary clarity just coming to market now. There's CodeNomicon. And there's Black Duck Hub. That's about it at the moment. But you'll see a lot more tooling in 2017-2018 on the project side and on the proprietary side. Big picture again, open source has some security challenges. I mean, that's just true. It does have security challenges. It is also true that open source is just as secure as proprietary software. And it is also true that it will get better over time. We always do. We always have. That's why we've taken over software while we're eating the world. Now, my call out today is for you all to be part of the solution. We are a community and there's a limited amount of energy and time that each of us individually have and each of our companies has. So we need more people. So supporting things like the core infrastructure initiative, helping shape the open chain specification, sharing some of your best practices around security. That stuff is invaluable. That would be really cool. In open chain, when I said, please share your slides for compliance, we got incredible slide sets from companies like Arm and Qualcomm and Samsung. I would love if some companies shared some of their security process slides. I don't mean the secret slides. I don't mean the secret details. I mean just the general processes. Because if we can get the general processes together and polish it down to some core essentials, then we can share it with everyone in the supply chain. And everyone can get that knowledge. It's so valuable. We need three things. We need deployment processes. We need update processes and we need automation. Open source security is currently a little bit behind the curve on all three. Though we're doing okay in automation, but it's kind of sad there's only one open source project that's dedicated to, for instance, automation around binary analysis. We could do a little more competition here. Deployment processes don't have it. Update processes don't have it. Blank slate. Not good enough. So, you know, let's talk. Let's get this conversation rolling because I actually know for a fact that we're going to be working on the deployment processes in 2017 because I'm chair of the curriculum working on this. But I do need help. I do need slides. I do need knowledge. And I would like you to contact me. So Shane at incinerary.com. I'm very happy to tell you more about anything I've talked about today, but especially to put a call out for materials and knowledge so that we can try to make sure that security and open source are better addressed. And the security issue around IoT and open source and IoT doesn't become an unnecessary embarrassment to us. I think we've all seen recently what happens to companies when they deploy things prematurely or without the correct process management. And that happens. Everyone makes mistakes. It's the real world. But we know what we need. We know exactly what we need. All we have to do is build it. So my call out is let's do that. Let's do that together. Let's start building this. Deployment processes, we can get underway and have something out in Q1 2017. All I need is slides. All I need is slides and we can do it. Update processes depends on the field. The mobile guys and the Wi-Fi connected IoT guys, maybe you don't care so much because you can just update easily. But the infrastructure guys, they really care. And anyone who's deploying any IoT device that's connectable and doesn't have an update process, well, that's not a good idea. So let's talk. Let's work out how we fix it together, reduce costs together and make it easy and cheap together, just like we always do. Thank you very much, ladies and gentlemen. I really appreciated your attention and your time. And if you have any questions, just let me know. So, any questions? One question from this gentleman here. I mentioned that we could solve like the security problem similar to how we address the compliance problem. I think there's one more step. Actually, what I would want is four steps and we're missing one is participation. Ah! This kind of expect that the security system will come in for free. Yes. But we have a lot more users, a lot more people also like contributing. But what I see a lot of projects is like reviewing or adoption problems. And since we're all part of the community, I think the next step after just contributing code is like taking part in reviewing code, getting security code stuff like this. Yes. So, I think it's now to call out that the next step of participation is to engage in such an either doing it quite directly if you're component of critical view or like more and more like creating stuff like this. Yes. There's a lot more of that. So, we get the security pieces, which we then can deploy out there. I completely agree with you. Participation is something that I essentially pre-assumed in that... I mean, one of my call-outs was... We do, we do. I mean, one of my call-outs was... Oh, it's not on this slide, it's on an earlier slide. It was core infrastructure initiative. This is really important. This helps do things like fund audits. We have huge problems in participation and OpenSSL I think was such a great example of that. You know, this was a project we were using to essentially secure the Internet maintained by two people in their spare time. And the concept that many eyes squash all bugs works if many eyes are looking. But instead, we all deployed OpenSSL and we're like, well, I'm sure that Google is looking and I'm sure Facebook is looking. I'm sure it's fine. And the thing was badly broken. So, yeah, I entirely agree with you. Participation is so key. And nothing on this works without participation. I mean, that's just got to be there. If we're not collaborating, we're messing up. And if the projects are just left out in the wild and not supported, we're messing up. And one thing every project I speak to when we talk security is they tell me they don't have the resources to security audit. It's expensive. I mean, they need money for that. And it's not like they're out there begging for the money. It's opposite case. It's that they don't have the money and they don't have the special skills to do that. So they just can't do it. So it's not going to happen unless someone helps them. So things like core infrastructure initiative are absolutely critical and need more resources poured into them. I mean, we're generating tens of billions of dollars out of this code in revenue every year. We have to regard investment in security audits, investment in supporting security best practices as simply a cost of doing business in open source. If we don't, we're essentially being negligent in how we're dealing with our code for our customers. And I think it's part of the gaping holes in how we did this. We assumed that because we're all using it, we're all looking at it. But in reality, we were just using it and we didn't look at it. And participation is still a sore point. I mean, I still hear it from every project that I speak to that they just don't have enough resources, funding or support from their user base. We're going to have to work on that because none of this works without participation. So I pre-assumed participation must exist. I mean, if security is a first class citizen, if you're deploying a car with open source, if you're deploying IoT devices that will lock people's doors, you need to be part of checking out that the code you're deploying is supported for security reasons, period. That's that simple. Any other question? Two questions. I'm going to get with the gentleman in the green first. Especially in the professional domain, where the companies are around, they seem to target companies that are actually involved in that. Wouldn't it be quite for efficient trying to basically go one step to the actual movement of these components? I just get the comparison to the information that is out there. Right. Right. No, quite right. I mean, if we want to solve security, we need to go to the source. Projects need to have best practice security development. And for the projects to have that, they need the knowledge and resources to do it. A lot of the stuff out there, including pulling up logo, including my company, we're essentially doing an awful lot of work to address the symptom of security problems. But the long-term solution to security problems is actually more and more upstreaming and support. I mean, you know, companies sell fear quite often. They say open source is dangerous. Here's how you scan for it if you're a commercial entity using it, or whatever. Personally, I think that marketing approach is not optimal, because I think that, first of all, open source is awesome and it's on parity with proprietary code. And it's going to very quickly surpass it in areas like security. It's not fear that we need to be talking about. It's increased efficiency. And if we want to talk about optimal efficiency for security, today we have to do things like catch problems flowing through our supply chain. But tomorrow we need to ensure that the source, the actual projects, have the ability to make more secure code from their beginning point. And that code flows into the supply chain. I'll come to you, sir, in just one moment. The gentleman in red had a question. Is there a public or an ultimate? Yes. There are several databases. One of the public ones that I highly recommend that everyone considers building in for security is the National Vulnerability Database in the United States. Essentially that's the CVE database. And it's freely available. The disadvantage with CVEs... Well, I'm going to pull up a slide very quickly. Thank goodness I didn't have fancy transitions. This would take forever. Okay, the disadvantage with CVEs is that CVEs often state these devices are vulnerable and lists one device or two devices or three devices. They're often something like a bad driver. And that driver has been deployed in similar chipsets across a lot of the market. So sometimes you have a CVE report and the CVE report allows you to know certain devices are vulnerable, but in actuality, the vulnerability might affect hundreds of devices in market. And that's where something like similarity matching is really important, if there's a similar driver to one that's known to be vulnerable, for example. Similarity matching allows you to say, hmm, that could be bad. So National Vulnerability Database is a start and it's not a bad start. Commercial side, VundiB is an example for risk-based security. VundiB is a database which consolidates a lot of different security advisories and other databases. We are using the National Vulnerability Database. We have our own proprietary binary database for similarity matching. We're also using VundiB and we also are using the Fedora and Debian security advisories. The Fedora and Debian security advisories are a useful resource that is publicly available. But it's not necessarily in the database format you would want, but it is available. So National Vulnerability Database is a project you're including and it seems to me that there should be an easy solution to just scan that list and say, well, sorry, you have talked with me there, it has no go. Well, here's kind of the kicker. There is an awesome project underway in France called Software Heritage. So have a look at softwareheritage.org. SoftwareHeritage is consolidating all of the open source in the world into a massive single database. And we're integrating into SoftwareHeritage. Actually, we're helping to build their public API so everyone can access it and pull out all the different types of information necessary. SoftwareHeritage has over 2 billion files and tens of millions of projects covered today and it's crawling the web continuously. For open source, that has the potential to integrate with things like your build farm and in combination with a scanning tool like Phosology for Source Code to basically help you identify things very well. The challenge is optimization. As you know, false negatives and false positives when we have massive data. So for example, we have a proprietary open source database internally as well as using SoftwareHeritage. And our optimized database is much more optimal for our scanning approach. What we want to do is help SoftwareHeritage equal and surpass our database in terms of data access speeds and so on. So we'll work with them on that and we're not the only people. Large companies all over the world are beginning to look at SoftwareHeritage and I think that database is the one to watch not necessarily for security vulnerabilities but for all open source. And if then you're able to plug into National Vulnerability Database, you're able to plug into 1db commercial solution. Those two provide probably the best direction at the moment. You're welcome. V-U-L-N-D-B. So Vulnerability Database. It's a proprietary database commercial company so you have to pay for it but it consolidates a lot of sources. And most of the tooling in the market supports it. So if you're using something like BlackDuck ProTechs I believe it plugs into it. I think BlackDuck Hub, I think Protocode might support it as well. We support it. So most scanning companies support 1db but you can also support it direct in your build system. For instance, we were asked by one company in Germany to integrate with Jenkins just as one of the processes. We can do that and I'm sure tooling like SW360. Have a look at SW360 from Siemens Open Source Project. It's an open source scanning solution for source code that leverages phosology. SW360 might be a good place for you to start and they're looking for participants. I know the team, they're really great. Gentlemen. Okay, so I still see a gap or maybe my view is wrong. So first of all, we will always get source code so on universities there are young students and interesting new technologies are very interesting open source code but obviously with a higher rate of bugs. So we will need, at least speaking for my company to invest in doing for critical parts doing reviews. But now looking on where are those big bugs found typically by security experts, real experts, experience. So we would have the capabilities in our company to do reviews on the same level. My opinion is that on the other hand as of today or as the tools that we use for automatic scanning, there's still a gap between what these tools can find and what these experts can find where we could train our developers to do reviews. Absolutely. And therefore maybe I didn't look exactly, I did not find much literature web information to do this training so we just did it at Hock. So for example, had some developers do the patching from vulnerability reports so we need to get some patches from vendors or whatever we do. So I have them to do these patches and then learn on what are the typical things which go wrong and which are found but that's pretty much at Hock. I don't think that's a good way of doing it. This is a wonderful point. I think one of the most important points we have to keep coming back to automation can only automate some things and we must never oversell it. A gentleman at the front laughed when I said about replacing internal teams with automatic tools. Automation can do some things but not everything and we need security experts and perhaps it's not a dirty little secret of software industry but it's certainly something we don't address head on. There's very little literature about this area and how to fix it. In a nutshell, it's really expensive to get security experts and what we need to do is we need to pay them and you can do that with bug bounties or we can do it through things like core infrastructure initiative and I think the sustainable solution is we all put in a little bit of money into core infrastructure and we pay security audits on the core infrastructure code. We share the cost and ad hoc, you've learned a lot obviously so your processes would be so valuable so if you could consider at some point talking to me about what might be shared I would deeply appreciate it because everyone does ad hoc and then we combine our knowledge. I'll come to you in one moment. I'm working for a company so I cannot really share it. Oh of course. So I can of course join the open project Oh no no. No no no. I totally understand. In fact what I would suggest is if at all possible email me at Shane at incinery.com and what I will do is I will share the information that we're developing and perhaps you could share that into your company and see if it is positively received and in that case maybe a dialogue. I mean this is a long-term project it took us two years to build open chain and get the specification and the shared slides out. We're not in a hurry. It's more if we want to gradually work together. You had a comment sir. I think there are two parts to that. So I think we need security audits which are expected. But some parts just take in because of the review process or slowly there are not enough resources. Absolutely. Absolutely. Absolutely. And one thing I think I'm going to call out Microsoft here and just say they did great work with their IDE for flagging security errors I thought years ago where their IDE would essentially nag you about security problems and as annoying as that might be I thought that was a good idea and I thought that was a good idea. So I think we need to I thought that was a great step forward in trying to help all developers think secure all the time. And the more that we help our developers and give them support to build security in the better they don't have to be security experts. So I mean I think that if we have any IDE that isn't flagging obvious potential security problems that feature needs to be added and I think that if there's any training process that isn't telling our engineers think security first as a first class citizen we need to adjust that process and I completely agree. So yeah, we always need to train internal we need to make security first class but we also need to fund those real experts out there who do stuff like find heart bleed and shell shock and all of that. So I think that's it. Thank you so much for the wonderful questions at your time and I have business cards if you need them somewhere I think, I hope. Well maybe I have business cards. I really appreciated your time. Thank you.