Open source software is the norm these days rather than the exception. The code is being written in high volumes and turning up in critical applications. While having this code available can offer big benefits, users also must be wary of issues the code can present and implement proper vetting. <\/p>\n
Josh Bressers, cybersecurity strategist at Red Hat, emphasized this point during a recent talk with InfoWorld Editor at Large Paul Krill. <\/p>\n
InfoWorld: Why is Red Hat getting on the soapbox about open source security? <\/p>\n
Bressers: We've been on this soapbox for a long time. Fundamentally, there's a supply chain with software. In the past, you've not really thought of software using the supply chain concept. [In the past, it was thought of as] some dude writes software, and that's how it is. We're realizing now that there are vendors, and vendors provide you with a thing that goes into your product and obviously it's designed in a way that with a supply chain if you use low-quality parts, by definition, you're only going to get a low-quality product out the other side. <\/p>\n
I think we're starting to recognize that if you're just grabbing any piece of software you find from a commercial vendor or from the open-source community and you don't know what it is or it's not vetted and you don't know the quality, you put your final product's quality at risk.... You have developers going out to GitHub, going out to Stack Overflow, and they are downloading code. They're not necessarily paying attention to what they're getting and how it's being taken care of. <\/p>\n
Open source won. It won because it's used everywhere now. But now we have a supply chain problem we need to start thinking about and that is, where did you get it and how is it being taken care of, because software doesn't age well. This is something that you have to take care of and you have to pay attention to. You can't just pull software into your project and you're done. <\/p>\n
InfoWorld: Where do you go from here? <\/p>\n
Bressers: Fundamentally, what it comes down to is you need to understand where your software came from, which means in the open source context, you have to think of open source as a third-party vendor, which means who's paying attention to it? From an organizational perspective, you need either a team paying attention and taking care of this, or you need to find a vendor to work with who will be your representative here and will do all the heavy lifting in terms of vetting the software, understanding what's good, what's bad, keeping it updated, making sure you understand what that means. <\/p>\n
That's the piece that's missing today. There's lots of organizations that have developers that will go out, find what they need in the open source universe, pull it in, and then they don't think about it a second time. Obviously, if you do that, if you never update this stuff, eventually there's going to be some sort of problem that you have to deal with in the software. Think of something like Heartbleed. It's a great example where people had literally just pulled this OpenSSL version into their applications, and a lot of them didn't even realize it was there. <\/p>\n
InfoWorld: So what do you do about this situation? <\/p>\n
Red Hat: I can tell you what Red Hat does, and every organization will be different. We have a team that's dedicated to paying attention to the open source universe, and they watch for security issues. This is where open source is unique compared to some of the third-party, typical software vendors, we could say, is there's a very understood relationship there where essentially they have a product, you pay them for the product, and the expectation is they will maintain it and you will go to them for help and support. In open source, it doesn't exactly work like that. You have two choices. <\/p>\n
Number one is you go to a vendor that specializes in essentially productizing open source. [That is] the traditional software vendor relationship. However, there's the alternative option now where you can actually treat open source as your vendor, but it doesn't work in the same way now because you have to pay attention to the community and you probably have to get involved. <\/p>\n
I would say if you have an organization that's concerned about this and they are using open source, they need people in-house who can work with the community, who can understand what's being used, and then they can engage at the appropriate level depending upon what's being used. The other side of this coin is you have to make sure that your developers aren't just pulling any random piece of stuff they find. You have to actually have a vetting process to ensure that the software you're using is accounted for so there are no surprises. [And] it has to be high-quality. <\/p>\n
InfoWorld: What kind of vetting do you do of the Linux kernel? <\/p>\n
Bressers: At Red Hat, obviously, we're known for Red Hat Enterprise Linux but even Red Hat Enterprise Linux is literally hundreds of other open source components put together. It's not just the Linux kernel. The Linux kernel is a big piece of it. Granted, a very important piece. Even though we have tons of kernel expertise, we still have people who focus on the security of the Linux kernel and making sure that we understand what's going on in these kernels: Does this stuff make sense, what are the security issues that we're seeing? What do we do with them, how do we fix them, what's going on? <\/p>\n
Heartbleed affected the OpenSSL library, and that was included in Red Hat Enterprise Linux, but we also included it in some of our middleware products, for example, for shipping web servers. We had various other products that used the OpenSSL from Red Hat Enterprise Linux embedded into their own product like an image that could ship them. We pay attention to all of these pieces, and we have teams dedicated to just paying attention to this stuff to make sure that we're using good software that's being vetted. <\/p>\n
InfoWorld: What processes do you use at Red Hat, and what do you recommend for others? <\/p>\n
Bressers: This is going to depend on, team size, maturity level and just talent to some degree. We fuzz-test certain libraries and applications inside Red Hat. We do automated source code scanning. We do some level of manual scanning. We have a bunch of internal tools that will look at the artifacts that we build, which are making sure we're not making obvious mistakes or making sure that, for example, when you have an RPM package that installs the application or library onto the system, is it putting things in places that make sense? We have dedicated build systems so we understand what's being built, how it's being built. <\/p>\n
InfoWorld: Would you say open source software today is more secure than it was five years ago? Is it more secure than proprietary software? <\/p>\n
Bressers: Open source is not more secure than proprietary software nor is it less secure. The concept of proprietary software doesn't really exist anymore because virtually every organization has open source inside of the products they're building. <\/p>\n
You also asked, is open source more secure today than it was five years ago? There isn't good information on this, necessarily. I would hesitate to say we're more secure. But I think we better understand a lot of the problems, I'm willing to say. Because we have various groups, and Red Hat is one of these and there are also various bug bounties that exist. There are security groups in places like Google that are doing a bunch of testing. There's all these organizations now that everybody is using open source, they're starting to give back. I suspect that as long as things continue the way they are, the future will be better than the past but, of course, it's up to us to make sure we get there because if people stop contributing back to the community, the power of open source is lost. That's the key here around security. You can't just take it and use it. You have to be involved and be a part of it. <\/p>\n
InfoWorld: What's next for securing open source software? <\/p>\n
Bressers: The big thing that's happening now is this concept of open source needs to be part of your supply chain. The message is starting to get out there, but I don't feel like it's where it needs to be yet because I still think there are a lot of organizations that are treating GitHub or Stack Overflow as a bunch of free software they can just take and that's fine, you never have to worry about it again. But it's not like that. My comparison here would be, what do you think would happen if a car manufacturer literally found some parts in the warehouse? They didn't know where they came from, they didn't know who made them but they're like, \"They look great, let's just use those.\" That would end horribly. That's kind of where we're at in some of these instances where you've got developers just like, \"That looks great, I'll take that.\" We're reaching a point now where we need organizations using this stuff to start understanding their supply chain with open source as part of it. <\/p>\n
This story, \"Open source users: Its time for extreme vetting\" was originally published by InfoWorld. <\/p>\n
<\/p>\n