 So welcome to the open GS world fireside chat on security Today I have with me Jessica and Adam and I'll give them a few minutes to introduce themselves before we get started Jessica, why don't you start first? Sure. Thank you. My name is Jessica Wilkerson And I currently am a cyber policy advisor for the food and drug administration where I work on Cybersecurity policy for securing medical devices before that and particularly relevant to this group I was the cyber security research director at the Linux Foundation and then prior to that I spent five and a half years and with the United States Congress looking at cyber security issues in Healthcare and energy telecommunications pretty much all over the map. So that's me. Thank you All right. Hey everybody, I'm Adam Baldwin. I am a product manager focus on software supply chain security at github As you see I'm sporting my npm shirt I came over recently in the npm acquisition where I Used to at npm run security operations and as Let's see prior. I also started the node security project Which many of you may be familiar with as well And I'm Michael Dawson IBM's committee leave for Node.js What that means is I get to spend a lot of time involved in the Node.js and OpenJS Foundation Participating in a whole bunch of the different working groups including ones which have touched on security and so far So Jessica one of the things that really interested you me interested me about the things you said you're working on is Your work at the FDA and I kind of wonder how you know Javascript being used in critical infrastructure if you're already seeing that happen Like medical devices cars and so forth changes how You know, we need to build maintain or sort of think about security for Javascript Sure, it's definitely it's a it's a huge consideration for the food and drug administration In particular and for when I was at the United States Congress and we oversaw other federal agencies who have stakeholders in in critical infrastructure like you said cars and others and Certainly everybody on this panel and everybody I think who's going to be in the audience knows that most software today is primarily open source You have open source software and everything you're never going to have a piece of software and or really should you That isn't built with open source. And so Open source security is critical infrastructure cyber security. That's just the way that it is today. And so for us We are working currently with our stakeholders and within the agency itself to Figure out how to tell what a given product is built out of so software bill materials is something that some folks may be familiar with that is a Policy that we're very much pursuing where we are looking to have folks who are developing medical devices submit to us a list of all the Software that's contained within it. And while we don't necessarily have those in all cases yet Well, we are expecting in the future as we get more and more software bill materials We're going to see more open source software We're going to see more Javascript and in that case It's clearly going to have medical device impacts and it's going to drive Continued interest from us at the food and drug administration in that security And I can I can see that being really interesting in terms of you know some of the things we're working on in the community in terms of say like the package maintenance working group where you know some Packages, you know, we're looking for more support or struggling to keep things going if that software is being used in some of that critical infrastructure It's even more important to figure out how we get the businesses which are using them involved in participating to Collaborate with the the maintainers support them financially or through some other mechanism Yeah, I definitely love to see more support coming out organizations that rely on open source I've often said you're you're responsible for what you require right what you depend on and that risk is transferred to that organization and a lot of times we hear. Oh well, you know We're just consuming it. We're not we're not basically if you're not supporting it then you're you're sort of like pushing that responsibility on others and Which is which unfortunate I mean and I guess there's Sorry go ahead no go ahead I was going to say you know we're at the food and drug administration I think in other parts of the government we're much more used to dealing with physical supply chains You know we've we've known how to do that for a long time if you are the final goods manufacturer and actually I think the term is final goods assembler For a car something you are responsible for anything that you put into your final good And I think we don't necessarily have that same mentality and software and nor necessarily should we but I think Lessons learned and best practices that we can look at from the physical manufacturing space and certainly transfer over to software I think if we don't have to relearn all of those very Lessons we shouldn't Yeah, definitely like in the package maintenance working group or working on some tooling And I think that'll be you know important things like the the npm audit seems to have helped a lot in terms of raising the visibility of vulnerabilities The tooling we're looking at is to help you under better understand The packages that you do depend on what level of support they provide what kind of backing there is behind The you know the project is it a you know one person building it themselves as a hobby or is it actually backed by a commercial company I just wonder you know if there's any analogs or Experience we can we can pull from those other areas that you mentioned in terms of tooling that's necessary to do that Meet those kinds of requirements Yeah, I think there there probably are The tooling I think is an interesting question. That's something that's being developed in parts of the sector right now for Many folks who are involved in ongoing efforts multi-stakeholder efforts around software building materials That effort is passed to a certain extent one that the idea of whether or not it's a good thing I think every the answer is yes, it's a good thing and everybody needs to be doing it In two even necessarily what it looks like there's certainly been frameworks proposed for if you were going to do software building materials Here are the base elements it needs to have and now I think the the next really large hurdle that everyone is trying to figure out how to Surmount is How do you possibly do that much outside an inventory tracking when you have Versioning concerns and all these other things and so the tooling is going to be very important And I think in some circumstances it is unique in ways that physical manufacturing and physical goods tracking isn't But certainly there are enough analogs and parallels that you know, there are certain things that we can carry from one to the next It seems like there'd be a lot of like a lot of things that we can adapt kind of pull in adapt There's you know, there's automation for food processing right to identify a bad piece of fruit and to automatically, you know Remove it from from going to further down the line or and a lot of that is process driven, right? So so luckily in the digital space we can we can implement those things in a lot of automated ways One thing this this conversation has me thinking about I think it's going to be important No, no, go ahead. Sorry There's a little bit of a lag. I think yeah Our talk here it might be my internet apologies everyone But I think one thing that I do that we want to be careful on and this was something that we Explored when I was still at the United States Congress Energy and Commerce Committee and it's something that we certainly taken into consideration now Open source software developers in some cases their commercial they're getting they're getting paid to do this As part of their jobs and others there are not You know we're in many physical manufacturing or physical supply chain issues You're doing business to business and these are sophisticated organizations negotiating with each other I think one thing that we do want to be cognizant of and careful of as we continue to see At least as we continue to reveal more open source usage within critical infrastructure Is to be careful about what we can realistically expect those developers and those package maintainers and others to be providing you know depending on What level of support they're getting in their daily lives to do this kind of development? I think you know there has to be a proportionality and a balance there so that we're not overloading Overloading that system Yeah, I know absolutely One thing I you know the conversation has has made me think a little bit about like is there something that You know the project or the open JS foundation should be trying to do to bring people together to talk about This particular topic so that the JavaScript community is ready to continue to participate in those areas In terms of the software being used or Or is it that you know the the larger problems will be figured out in general and just apply to the JavaScript as well I Mean we're the we're the kind of the leading edge right in terms of a lot of that we've we've We tried to establish a bill of materials as has a core piece of like a node a node project right we've got a package Jason It doesn't solve all the problems right you can still vendor Better things But you know I kind of look To what JavaScript is done is as definitely leading edge in terms of like We Get my words mixed up here, but Yeah, I mean like what we're doing is is going to influence I think a lot of the other ecosystems given given the popularity of JavaScript Okay, so we're kind of we're kind of hopefully Already doing what we need to be doing just need to continue pushing forward on that I Want to wait maybe move move to another topic based on what Jessica just said in terms of expectations One of the things I kind of seen recently flare up a couple times is there seems to be some tension between Maintainers and vulnerability reporters And you know some discussion around you know reporters Reporters will get paid through bug bounties or through some other way Meanwhile that can cause a lot of work to maintainers who aren't necessarily getting paid and that the existing tools Don't necessarily help out and that you know if they revolt that they report a vulnerability It may not even apply to a to a particular package or project But they still end up having to go through a fire drill to address that So I wonder what your take was was on that discussion Well, you can kind of blame for the the npm audit If you if you want to you can you can tweet me at Adam on her square Baldwin But yeah, I mean we started that pattern a long time ago with with NSP right like sort of being able to like okay This is this package doesn't own vulnerability surface that and it's it's well It's brought attention that the we wanted to erase awareness of that. That's definitely caused you know some Some heartache some chore some frustration Because it doesn't it's we're using the same tech. We're doing the same thing that that you know I started doing eight years ago right like it's it hasn't really adapted it hasn't We haven't got context around the exploit ability those vulnerabilities Are you actually calling the method that that is referenced for a piece of vulnerable code and of course that brings then Pain to the the maintainers right like that brings somebody that says like this is a bug And you know the maintainer might not think it is but security researcher thinks it is and there is definitely a You know attention there, but what we have to realize is that on the on the researcher side They're they're trying to help there. They're genuinely in in in most cases trying to help they're trying to surface A problem that they see and they're trying to help And I think that we haven't done you know what what we need is to facilitate better communication between those between those worlds You know right now we say like well they're getting paid for to find bounties right now I'm not getting paid like there's nobody sponsoring my page to fix You know to fix these things they're doing you know in a lot of cases the bugs that we're talking about the ones that are just kind of you know What I consider kind of these garbage bugs that are that are not really interesting they're not getting paid for those they're not getting they're not getting paid out for those And they're doing the equivalent of what the open source contributor was doing or their career right they're creating some open source maybe to create an opportunity for themselves to create something for the world Security researchers doing the same they're following that curiosity there they are also trying to make a name for themselves by finding these things and ultimately trying to trying to help the ecosystem the way they know how We as developers and as that ecosystem have not invited them in fully we still keep them kind of at arms length report things here and even though that tooling is not not that great We even have like we have npm we have github we have the foundation we have a multitude of places for these researchers to go report things to That are all over the place so it's like that's not even consistent so there's there's communication a communication problem here really Yeah, I'd agree like there's you know even discussion in the community right now and the security working group about the vulnerability database and reporting and like you know as you said things have changed over the last eight years and so it's a good time to kind of figure out well should we have these different Vulnerability databases can we consolidate can we can we make it easier to report and I think your point about bringing people into the projects more closely is important like I think You know a lot of the time there's friction that's because you have you have sort of what feel like two sides if we can bring the researchers and the project closer together hopefully we can get more of the you know the us and I think things go a lot more smoothly like that so You know maybe that's something that we need to try and get some focus on sorry yeah Jessica I was actually going to say it's it's interesting because I think you know in government we're usually a couple steps behind everybody else but I think in this it's interesting because we actually have developed At FDA over the last couple of years a very robust coordinated disclosure program so not necessarily that Finders of bugs and medical products are reporting them directly to us so they can But I'm going directly to the manufacturers but in a lot of cases we found in more recent Issues that we've had we're able to essentially put us the manufacturer who has the issue and the person who found the issue on a single call or not right now during covid but in the past in a single room together And everybody just kind of sits down And I think the part that's made that very valuable for us is in this time element of you know you're all saying sometimes it's very difficult for these maintainers they have to go in these fire drills And what the model that we've sort of adopted here where appropriate of having everybody on the same caller in the same room The manufacturer can just ask the researcher about the technical details and the researcher can provide the feedback and it becomes this this loop so that the The those little pieces can be identified and the okay this isn't part of this vulnerability and we don't need to worry about that And it's not something that the the manufacturer in our case is tracking down into vacuum and we found that to increase the speed with which vulnerabilities can be fixed Yeah that almost that almost makes me wonder like today it's kind of the model where you report the vulnerability but doesn't necessarily come along with a fix I think it would be a lot more valuable if we could somehow get to the point where it's like either you know if the fix is jointly developed or along with the vulnerability it's like and here's a way we can fix it Part of that's maybe making the researchers more comfortable you know working in the projects or or working in the projects as part of the work that they do to find problems but then positioning them so they could fix them as well Yeah that's the that's an interesting thing I've been on both sides of that in terms of I'm a security practitioner I can write code but I don't write very good code And so you probably don't want what I consider to be a fix to be contributed to your project right like but I can certainly find and in point that flow out I would absolutely love to see more security practitioners coding and to be contributing code I think that if they were they would feel more empathy for the other party on the other side of what's happening here I don't again I think that sometimes I really think it needs to be collaborative effort I would love to you know obviously getting a pull request that says hey here's a problem and here's a fix like that's that's absolutely wonderful but but you know You run into projects that are like well we don't have any test coverage so you have no idea what you're breaking right there's a lot of like basic hygiene things that could be done You know across the board and you're talking about moving thousand thousand thousand developers in the right direction so that that these things can improve Yeah, but certainly a checklist like that that says what makes it what makes you ready to accept vulnerabilities and potentially fix this along with it because you're right like without test coverage it's a much scarier thing to propose or even accept a change like that Yes, so the starting point for most developers is going to be to create like a security MD File in your repository right basically creating your as a as a maintainer as a project here's how we want to accept your feedback right here's how we want to accept your report That is the one sort of like method that that we have to sort of communicate that is put that in your project and say you know email me here Because of wonderful things like GDPR and all the things like we don't necessarily make all that data like how to contact you public And I'm hopeful I'm new to GitHub but I'm hopeful that we can get some of those private channels to maintainers for reports so they don't show up in public issues And things like that but basically asserting like this is this is what you can expect from me as a maintainer But we also have to hold that with a grand assault right these again are typically volunteer projects right these are people with small amounts of time and Right okay so actually you know time flies we're almost out of time so I just want to give you each you know 30 seconds to you know make your call to action what would you like people to be thinking about or doing to help move As forward on the security front for JavaScript Jessica you want to start Sure I think what I would say and this is not meant to be a frightening thing at all just in just an awareness thing is understanding that while open source software is not typically associated with critical infrastructure it's not typically thought of as something that could have Physical harm potentially harmful impacts to patients or to cards or the grid or whatever it is is acknowledging that Rightly or wrongly it's ended up there there's there's open source software in implanted medical devices and others and just thinking about that as development is occurring and decisions are being made about the security and other characteristics of the software. Thanks, Adam. I think you know in this in the same vein right like that that that open source has showed up in those super important places. We as maintainers have to do good hygiene that you know to take care of our accounts because our accounts are the thing that give access to publishing as us or you know adding, you know, a back door or something malicious so I would really love to see adoption of 2fa Getting getting more maintainers to enable 2fa if if just a handful of you listening go enable 2fa you'll have made my day so Okay, and I'll just close out with you know we've mentioned a few times that collaboration would help in a lot of areas and so my call to action would really be to come and get involved in the JavaScript community. We've got a proposal for collaboration spaces out there you know we could make security one of those. I think if we can get more people involved to figure out what the best practices would be what that basic basic maintenance would be. It's going to be a lot easier than each maintainer having to figure it out themselves and then security reporters having to deal with different approaches and so forth so that's my call is is for everybody to you know hopefully come out and and and help be part of the solution by getting involved there. So that's the time we think we have thanks for everybody who's who's been watching the panel and you know we look forward to, you know, maybe meeting you in the open jazz foundation work going forward. Thanks. Bye. Thanks. Thank you.