Open source security: who’s responsible? - GitHub Satellite 2019

You. Hello everyone I'm super. Excited to be here my name is Rima silk itis and today. We've, got a panel of guests here. Let. Me tell you a little bit about myself, I'm a senior product manager a senior. Director of, product management here at github, I'm. Mostly concerned with how teams and individuals, on those teams actually work through the entire, software, development lifecycle and, today, on our panel we're gonna talk about this, intersection, between, DevOps. The. Software development lifecycle developers. And security, and we're, mainly, gonna circle. Around the question you know whose responsibility. Is it when you have. Open source security. And all of those concerns, so. Why. Don't each of the panelists introduce themselves today, Tracy why don't you go, forth hi. Everybody I'm Tracy, Miranda, and I'm director, of open source community, at cloudBees, and. I focus on. Building. Up the so I work very closely with the Jenkins and Jenkins X open source communities, and. The mission there is you know just to help those communities really. Grow and thrive and of course kind of deal with aspects, like security. And. I work, at snick I'm. A director, of product and. It's Nick we find a fix open source, vulnerabilities. Fantastic. Right. My, name is Pierre I am, an open source manager at solando, I am. Responsible for how. We adopt. Open source software and how we release open source software as well and southland are. Over. I'm, Laura I'm. An engineering manager with, move air I try. To make engineers, happy. Why, don't we get a round of applause and say thank you to our panelists, today. Okay. Anna I'm gonna start with you first because. Your. Company is recently released or they actually released yearly, this, state, of open source security kind. Of survey right, in. That report there, were two metrics, that really kind of stood out to me the first being there's. Been an 88 88, percent, increase, in application, library, vulnerabilities, over the last two years and 81. Percent of users believe that developers, should be responsible for open source security so. My question, but first one is like when you say developers, like, need to be responsible, does, that mean staff, at companies, does that mean the folks that are actually implementing, open source software like. Who, is developers, in that context, so, the, onus can't completely, be on open-source.

Maintainer. So. I, don't know how many developers, are in the room how many people have created a open. Source repository, I. See. That's a lot and, keep. Your hand up if you, would feel confident, being able to fix a vulnerability, in your. Package. That's. That's, not me. Well. Our. State. Of open source security report, found the only. 70%. Of open-source, maintainer x' wouldn't. Feel comfortable i. Wouldn't. Feel like they had the knowledge to be able to fix a vulnerability, in their code, and. Actually have like a personal story of this i years. Ago I set up a, an. Open source repository which. Contained, a framework, that I'd written which, was a design, system and. It got kind of quite a bit of publicity yeah, there were quite a few people using it and. A few days after I published it I was. Checking Twitter and someone. Was pointing out that there was a massive under ability in it and. Yeah, I found out about this it was a weekend, and they wouldn't tell me what it was it would just say it's really really, bad, so. I kind of asked, a few of my friends like can you take a look what are they talking about and, we. Found out it was a. Basically. Anyone, who hosted, that framework on their server ended. Up basically. Opening. It up to the, world like any public server and could kind of like suddenly, access, it I'd basically written, this, massive, vulnerability, and I was really embarrassed I felt like I you know should. I have published this in the first place I didn't and didn't, have the skills to fix it but. What was really nice was that people. Stepped in to help so they stepped in they, provided their knowledge they, wrote, a fix, they helped me write a kind of practice release doing. Responsible. Disclosure. And. The way that I found out about it was actually quite typical, 48%. Of people who, have their like who do, open source find out about a vulnerability, in their code via, a public channel like Twitter which. Really sucks but. At the end of the day the. Code is fixed, and, as. Far as I know there were no exploits. But it really kind of sunk. Home to me about you, know I'm a front-end developer and, I I'm not confident, that I can release code that's cure so, I think in that situation we. Don't want to put people off writing. Code and publishing code it's really important that they feel confident, in doing that, so. I think it's kind of up to everyone everyone who consumes open source packages, to be a kind of responsible, citizen. And follow kind of. Disguise. Of processor, sort of thing so, you. You. Got this vulnerability, and, you'd like you weren't sure what to do with it and so like. What, did you do in that time before that fix, is actually manifested, did you ask somebody, to say hey can you fix it you ask somebody has said hey can you fix it for me I didn't ask I was immediately, offered you, know easily, we found it first of all they had a go at the person who publicly, disposed, it without you, know giving a heads up first yeah, but they then helped me fix. It they knew, immediately what the problem was, it. Was quite a simple fix but then the whole process of telling people about it making sure that they were on the latest version that, really, opened my eyes and that was actually what, kind of encouraged me to join a security, company interesting. And so. One more thing on that had. You not gotten that assistance. What would you have done I would probably have given up. Just. Like fished. My keyboard away and said I'm done with this oh gosh. Tracy, let me ask you you know with cloud bees in the community, that you manage there do. You see that same kind of behavior with, developers, and you know assisting in that kind of security, yeah. Absolutely and, like. Working, with the Jenkins community, which is, you. Know the scale of it is huge. In terms of like users, there's millions of users. Lots. Of developers, working on different. Plugins so this there's, definitely challenges there because. When. You, have an, exploit. In something like Jenkins which everybody is using the, scale is ridiculous, so a lot, of people had seen of like.

A Couple of years back there was this exploit, where. It, was like, the biggest Bitcoin, mining, exploit, was something like they'd made three million, of unpatched. Jenkins. Servers, they were out there because they run on these really, powerful machines. So I think, the challenge we have, it's. Like the community. Will. Help and, they will do things but just. Getting, the message out like, patch, your, servers and people. Get, into this habit you know they'll, just ignore the updates on, on. The jenkins dashboard, that says you know this is you know they'll be like I don't want things to break now I can't, handle, this so I'm just gonna leave it so. That's always the biggest thing we're thinking about you know how do. We make it so it's easier for people and. You. Know tweeting. On Twitter almost, is one. Way to get the attention but, you know we, always want. To know how to deal with those sort of challenges, at that scale so you're providing, you know assistance. In the interfaces, they're saying hey you, know you do this, thing and there's this like natural, inclination. To say well maybe, not because I have other things they could take care of and there's like a concern. I might break something in that, so you, know to take the kind of internal view I'm gonna look to like one of you both are her on the on the inside of that how. Do you like help folks inside, companies, say like yeah let's let's, go and do it. Not. Not easy of course yeah I mean, you just email them all the time you tell your like employee like all the developers in your company like hey just go do it I try I try to avoid that noise that that pushy noise yeah, I I'd, rather like, to focus on give, give them, incentives. Right try, to try, to build a community within the company as you do outside with open source communities, as well and. Within. A vivid, community, those, pushes. Are not needed anymore people, are interested, and they're are proud of what, they do and then, they have a big incentive to fix it themselves without letting, me know and, there is also no need to notify, me about it. In. Order to have that you. Have to set up such a community and this, this. Is small, steps you have to do this again and again and this. Is a marathon.

Basically. And we we, just started this journey so. What what are the levers do you have as an engineering manager to, help. In that journey, that, maybe other folks in the audience can take away today, well. I learned from pair of course. We've. Been together at, solando and this, was, great and, and. Being. A role model trying. Trying, to actually do what you ask others to do helps. Show. That you. Do not know everything you are vulnerable you you do not know every technology but there are there, are certain ideas and. Things. That work for others that, you, can give a try and if that works for you as well in your organization, why, not try, to spread, the word why not try to make, that broader. In the whole organization, and push. The community, does. Your organization have, incentives, that say if you know you do these things like you know there's performance, related. You, know, bonuses. Or something else you know if you do that. I say. We don't have direct, incentives. There, are more indirect, so, there are there are a lot of opportunities. To speak up. There. Are conference, like internal, formats where you can present and, there. Are syllable showing up and this. This helps apart. From all the, Twitter, likes like like. Technology. That you have in any company anyway right. Understood. So para I wanted to ask you a question now so as part of your. Work you know you kind of you know, you help the company both consume, external. Open-source as well, as organized how the company, publishes, its own open source projects, you, know how do those concepts, of open source security and responsibilities, apply with you, know with the work that you're doing for the folks that that do that kind of work yeah the company and, so, solando, is a company that very much relies on like, customer trusts if they don't trust that our store is secure they don't want to buy anything from us so ever say everyone depends, on our, customers trusting us and. So. Far for the way we release things we don't specifically, talk about security with our developers but more we we talk about responsibility, and. Taking. Responsibility for what we release as open source projects because. We do. Not just want to throw code over the fence and just leave it there just sharing. It for the sake of just sharing it I mean I love the rink yes it's great. Yeah. Take it up there and then you're the, writer, and so. We asked several questions during this release process where. I would say the three most crucial ones here are first, of all why. Do you want to open source this what is the value and the motivation, for you as a developer what, is the motivation, for solando. As a company what do we actually get out of it and we. Asked a specific question not to be a gate keeper but actually to ensure that there's a long term motivation, if you have a motivation, you take responsibility for you take ownership of it um.

Just. One part the other part is is asking, the specific questions of how. Many work hours have you actually been granted, to maintain this project do you actually have company, time to maintain it and, how. Many maintain is are you actually on this team are you just a one guy operation, if, not you, do it because that is too fragile that, that one person leaves the company and that project is basically just deserted even. If even if you get folks from external, to the company to help assist the project, that's still too fragile. It's too still too fragile because we see that a lot, of open source projects, are run. By a core group of people who care very much about this project but. A lot of the reason why they actually care about it is because in the context, of their work at least force Atlanta because we use a lot of this open source quote inside, our store. And so. When they leave for another job at another company they. Stop caring about it because it's not part of their work anymore. So. So these are the things we need to ensure happens, during, the release process that we take responsibility for resources. Being available to our developers that we have time and people on it and. That we actually have a long-term motivation to maintain it otherwise we will lose interest and eventually. Tell the developers to do something else that's just how it works and, again. That is those to take long term ownership, because, if we don't have that ownership we. Will not fix the box there will be no one in that inbox that gets that per request that's trying to fix an issue no one will respond to it so it sounds, like it's less so about security, and more about just, that responsibility. Which then leads to trust that that. That component, will, be there, over yeah it goes way beyond security because, it is also about how do we interact with the people actually approaching, us that, might just be a, design. Fix for a piece of bit could also might as well be a crucial piece, of information about a vulnerability, it doesn't really matter we have to be responsible, for a. Community, around these things as well. So. Let me take that again go back to the outside approach, to this and Tracy I'm gonna go back to you with me like distributed. Nature of Jenkins, and all the plugins that work. With that yeah, how do you deal. With that kind of responsibility. Concept. You know in the world that you're in today it, does that exist does it not or. Is it just a community. Come and help us out yeah. It. Definitely has its challenges and.

Again. Similar to like as, the company cloudBees, we, kind, of at. The company level get involved, with with, the project so a lot of Jenkins security, team work at, cloudBees, and. The. Things we're seeing there. That make it really. Challenging as. That, the whole security, area has become really. Professionalized. Recently, which is a very good thing for the industry but. What, that means for open-source so. If you take the example of Jenkins. We. In, the history of the project there have been eight. Security. Vulnerabilities. Which, were reported, with, coordinated. Disclosure dates so, you're getting the report and you've got a ticking clock and those all happened in 2018, so, now. If you're getting a vulnerability you, know there's a time countdown, so. How do you do that when you've got a community where, that vulnerability could be in a plug-in that an individual, wrote. Or. Even, if it's in a company the team is focused on something else and all of a sudden it's like okay drop everything and deal with this so. It's. Something we, think a lot about like a cloud ease we. Can, we. Have to keep that trust with the customer like you're saying but. We're also looking at how do we solve this in a in a bigger fashion, and it, has to be everybody's, responsibility, and we can't throw open-source. Developers under the bus, so. Well, how do you deal with that like you. Say. Hey you're not being responsible for this thing how do you like, walk, that line well, one of the things we have done very, recently, we've. Got together a bunch of the projects. In the space and a bunch of companies and we've started a new foundation called the continuous delivery foundation, fantastic. And, that is so we can take this long-term view of you know how can we focus, on cross-cutting. Issues like security, so. The hope there is we can have you know working groups focused, on these best practices, approach.

It From a way that we, can use this community, to spread. The message extend. Best practices, and get, everybody. Involved open source projects, companies, individuals so. Just just be more organized about it because I think that's what it takes and so and so that that should help that that notion of folks not necessarily, I'm not, taking, responsibility for. The security vulnerability, or whatever so. Then we can set you know we can set requirements, to say like. You. Know you have to meet these things or we we, can't highlight your plug-in and promote it and, in some cases or, you give the. Community permission, or the security team permission to push out fixes, to, your repository, and you. Know I really like the features announced at the keynote today because. We can start to think about okay. These now, we have the tooling tooling is another, big part of it so how, do we use that thank. You for mentioning the keynote too so I'll make sure to pay you afterwards. Yes. So yeah I mean with all the stuff that we launched at the Keene at the keynote today like I think a lot of that can be valuable, to this concept, of like taking responsibility. And like reducing, the friction for. Developers. On your team or if you're even working an open source to, get. Those vulnerabilities, patched, as soon as possible, because it. Sounds like it is really a team effort right we talked about interconnected. Community, and it's kind of important, for all of us to you know chip in on that front. I'm. Kind of curious. You. Know and, I want to ask you again so you know have you ever run into situations or. You know even based on your state, of open source security, report where, developers. Are kind of pointing to one another and saying like hey. You're responsible, you're responsible, and never really like taking care of the thing just, like is that show up in your report I think. The finger-pointing is. It. Usually comes down to, maintain. Is who either. Unresponsive. Or, or. Their, root you know you you tell them about a vulnerability and they're very kind of abrasive about, it like I I don't I don't have from abilities of my kind I'm a perfect developer but. I don't have any in mind yeah but, I write for obscure languages, crystals. They, don't have firm abilities yeah. But. Foreign abilities a fact of life and and what's, important to know is, on. The whole. Open. Source maintain is a very good we, we, asked how quickly. Developers. Would fix a vulnerability, if, they found out about one in their code and 84%. They do it within a week so, I think the. Really, good sign it's really good sign the the people, take it seriousiy. And. It's also really great to see things like having. A, security, dome defaul really. Increases, like by a massive, proportion, the. Number of reports that you will get versus, not having one at all but as soon as you could put a security, md file up then. You're going to get much more private. Disclosure. As. Opposed to tweets. Saying, that your code is vulnerable, and, what other what other things, can an open sit an open-source, maintainer do, to, like, help that, process and or what, can other folks do to encourage you know a project, to you, know take that path to being better at this it's, a bit of a trickle, effect we've got $0.78. Of vulnerabilities, are in direct. Indirect. Dependencies. So not your direct dependencies, it's, the other packages that use, so. It. Needs more, kind of people taking ownership more people auditing. Their code. They're, like, it's Nick we have a plugin for ideas. We have, you. Know CI tools we have a CLI there's every, single stage of the development, lifecycle we. Have a way for you to monitor, find. And, fix vulnerabilities and. That's that's crucial, we. Can't have it like I imagine the most of you in the audience work agile does anyone not work agile, yeah. The. Security team can't be just blocking bills you know they're not they don't want to be the gatekeeper, they want to be they, want to be the superheroes, not the villains, whereas, developers. Want to feel empowered you know they own the code they don't want some telling them no you can't merge this they. Want to be kind of owning that and making those decisions and having, those tools in place at, that every stage of the lifecycle means. That they can fix vulnerabilities before. They've even made a commit, and the, sooner that they can fix our abilities, the, last time they have to spend on them so, what, you're talking about it sounds like we have to make that just kind of natural. As part of our everyday development, across the whole lifecycle otherwise, like we have no chance if we wait. And it's really important for those developers who aren't confident, and you know that 70% of open-source, maintainer x' he said they don't feel confident, fixing vulnerabilities.

In Their code that. They have the tools in place I mean that they don't have to have that knowledge it just it's self-healing, it does it for them I think. That is the only way we're going to get kind of reducing. The vulnerabilities, and code okay. So I'm, gonna go back to the internal perspective on this all right do, are you doing that today within your company are you trying to provide that along every step of the lifecycle I really. Like. And. I. Would, like to underline that just you, know those. Those, teams and those quotes in our case if they, don't own the service the code, then. This is just a job for them but we want them we, want, to change parts of the world and we want them also to be with us on the journey and with their service, to help us to, change parts of the world and once. This ownership applies then. That. There is no finger-pointing there is no question is it yours or is it my problem this, is just about fixing the problem and. Also. The lifecycle aspect is really, crucial and I see, that every day and I'm really happy about it that. You, don't focus, certain. Iteration on certain topics like security, like throughput, like performance, you try that you try to make that an ongoing. Effort, for all those non-functional. And functional requirements, for, for all the changes that you do in the code for. Those quotes I work, closer, with they. Come up with so-called, tech talks so. There are, bi-weekly. Iterations, where the whole team meets together and we'll talk about all those technical aspects, that, may not, be so much focus on when talking about business, requirements, and so on and so forth and. This is this, is the squad's way to make, sure all, those. Technical. Considerations. Are also end up, in tickets, as well as business requirements, to end up in tickets and have to be provided by. School on an ongoing basis. Understood. And so para I'm gonna ask you you know how I want to know some details like how does security remediation. Work you, know within the scope, of what you do and for the folks that work with you yeah and so, there's. Different, ways of doing so our team to get all their github security, alerts and a lot of the teams just proactively, fix these as they come in with a I heard that correctly you are using github security, oh yeah are you doing yes yes. We use github Enterprise we also use the public it hub and, I'll get my money afterwards I guess. Thank. You. But. So, these teams get get notified and it's it's a good good process for the team because then they can work it into the sprint planning and so on then, there's the more critical things which actually reaches, into production, actually reaches our in customers and, our. Security, operations center work, with companies. Like hacker one and pentesters, and we discover, these a lot of these vulnerabilities ourselves. And then, it goes through like, an internal process saying this. Is this is affecting our customers, affecting customer trust so this must be fixed so those it's, like a hard mandate, so that's not a lot of finger-pointing here it just must be fixed. So. I think, remediation. Is is interesting in itself but, first that's rather simple because it just must be done I think for. Us the more interesting, question is how do, you avoid getting to that point how. Can you be more proactively. Aware, about what is when, you adopt the dependency, for instance if you look at an open source dependency, that. Typically happens in the team itself they have complete autonomy to do so and, they, typically go on and github and. They look at the project's they, look at the readme and say this looks nice and then, they adopt it and it becomes part of what they're building and then. It goes into production and then the alerts start coming so, how do they find those tools. And. I think I think the again, I would also like to mention the keynote is very nice to see things are getting done but. I think the key thing that's, missing here is to be able to assess, this before you adopt the dependency, developers. Have very little knowledge and, very, little noise is exposed, to them when they look at a project on github it's. All about all the great things that it can do but it doesn't actually talk about the risks so a developer is not really in a position to assess the risk of it Dependencies, he's about to well depend, on and live. With for a long time, so. I think that that that part is still missing and. Well. I think here. The only actor in the open source world that can do that and lift that burden it is github, because, you are very central piece of that ecosystem and could provide this information yeah. I mean I think the way that we look at it its github is like you know we, yeah. We can be central, to a lot of where the developer works like and you know my you, know interests, especially along the entire software development lifecycle right, but you know there are things and other companies, that provide, services.

As Well that can plug into that entire lifecycle that we're still very important, to making sure developers. Can. Yes. They. Can actually you know get everything that they need to get done along every single step of the way and. You. Know that's what you know it that's. What it means for us to be open and have that an interconnected. Community, from the get-go, and this, is not to say what's Nick is doing is not good it's, great I just, think I would just love to know these things way earlier then when it gets into my CI I would love to have that developers. Have this knowledge before, they actually do npm install, that's. Where i think that's the most valuable thing the longer you get into the developer journey the more expensive will it be to fix these security, issues they'll pop up eventually. So. I think you should be talking. If. You're not a customer. You might want to figure. Okay. So. Tracy. I want to ask you again, so I want to go to like you. Know kind of the broader community. Are. You noticing any trends. You know regarding. Security, like you. Know it's been a hot topic and, you know given, today's keynote it was one of the three, pillars that we had up there. You. Know in your perspective. Do you see it, despite, all the talk getting better is it getting worse you, know kind of give us kind of a State of the Union in banana I'm gonna ask you probably the same thing yeah. I think we have, to acknowledge that. Up. To now, the. Way as an industry we've dealt with security, has been, just a trash fire it's just horrendous. So. I think it's really good that we, are having these conversations I. Think the, the fact that people are starting to highlight it is it's a good start but. There's a lot of ground to make up. But. Again as we're saying it's getting, more professionalized, which is good I think once.

We Start doing that then we start saying okay well, how. Do we do this and then it comes down to you know open source and. How. Are you going to fund the people who are maintaining it so I think that's the other side of it you know just making sure, all. These open source projects which we depend on can, be sustained. In. The face of you know these vulnerabilities, with, ticking clocks and, software. In everything. So. I think it's a good start and I think if we keep going like taking it seriously, and working together it, just has to happen that way so it sounds so to summarize, it, sounds, like we're. On the right path but we still got a long way to go yeah. And just taking. Kind. Of a long long. Term view and. You. Know what do you think I think, it's really great what github, is doing it's really important that security, becomes kind of the default like, you have to go in and turn off the. Alerts you, you they were on by default it's telling you about them I think. There's still a way to go and like, what I said earlier about transitive. Vulnerabilities, so. For. An ability to are in your indirect, dependencies, as well, as making sure that we don't make it too noisy so if, we make it too noisy, then people, will turn it off or they'll ignore it they become desensitized, to it so, it's about making sure that they're every piece. Of advice we give is actionable, and that. That action is just seamless it just just works. Speaking. Of that, actionability. Do, you have any like in interesting. Information, on that regard or I mean do folks like you. Know I don't know maybe never, do anything I, wish, I had like the stats off the top of my head but. Generally. If it's not actionable then people went to do, anything about it I would love to hear, that we're saying earlier about all of the kind, of issues that have been opened all, of the kind of notifications. That they'd send about. Vulnerabilities. I'd love to know how many of those were actually resolved, afterwards. So. I think as long as you make it easy as long as it's kind of just part of the life cycle either you click on a button to fix it or it just fixes, itself opens. Pull requests that sort of thing then, I think it's, going to it's. Got more chance, of catching on and being kind of the standard part of developers. Workflow. And. So going. To the internal perspective, I'm gonna look at the other, two folks of the other side of the table. Speaking. Of that actionability, and/or, prioritization. Of that we know we've been talking about responsibility. But. To, what extent do, you. Have. As like a product philosophy, that hey we. Have to fix these things or, we prioritize, this above maybe feature requests, and things like that I mean do you have that level of maybe. Extrinsic. Levers. The to. Push the teams to do those things so, I get the Lando. Engineering teams are largely autonomous about, how they prioritize, their work but. There is a shared understanding that, Security's importance it does assist among the teams how are you going to attack, these problems but.

Yeah If we have something that has customer, impacts, then it is is priority. One that's. That's, when something like yeah shows up immediately I need to take care of it but then there's sometimes these like lower grade bugs that show up that you. Know maybe there are lower severity but, need to be taken care of at some point so like. Do, those things get prioritized, or do they no. They don't and that is the only honest, answer we don't have a company policy that says like prioritize, all books we don't have that we. Try to do in a different way saying when. You have a project like this sighs what, is the time you need for this how much time do you want to privately. Have for this like in company time to make sure that it gets done then, it's your responsibility to, maintain it but we grind you the time to do it and the resources, so you can do it in company time we don't expect you to do it at home for fun so. That's how we try to do it we give people the resources and the time to do it and but. Then they also have to take responsibility. For their work right, I, I. Still, am slide challenged, with you know you have business school right and you're trying to launch things to customers, but then you have, these lower grade bugs like, yes. I'm the product manager here and I should know how to prioritize things, but you know how, do you I'm. Still struggling with that yeah right and it just sounds like in your, perspective. Like. Just let the team. Decide. Themselves, yeah. That. Is the answer because it's only the team who can actually assess it properly it's also the team that know the context of their projects it's, also the team that knows their entire backlog, and the importance of that area of the business so it must be up to the team again. Certain, level it must be mandated, there, are certain things that's too important to be ignored but. Again it is the team's responsibility, to take care of this of course if we monitor. Our different projects and we see where, okay let's say we have an open source project that hasn't received an update for months then, we have a conversation about is this actually something we, are using and maintaining if, we are not let's let's archive it let's say that this is not used anymore there are processes, in place though. For. My like umbrella, perspective. So even though we're saying you. Know it's your responsibility developer. To go do this thing there are still like processes. That exist that you know you kind of look at these things and say you, know based on these variables.

Or Characteristics it, kicks, off another conversation which, I think, from a product manager perspective that says oh maybe. I should prioritize. This thing for the team because. You. Know we are getting called out on this and maintainability, is in, question yeah, and it's tough because we have we have 200 open source projects so we have to kind of look at the broad view and see what are the outliers and said 200, yeah 200, before, I think with you okay, who's counting all right. Great. If you could prioritize those based on like whether they're called a run time no that would be terrible. Okay. Well it's solos are you would you would you agree with what he said would with everything being said there, yes. But for me it's all about context. And options right so, I. Don't. See a distinction between the product manager and the team I think he's part of the team right and he he, should his or her view on security. Or business, features and it's, for the team about options so in case there are even lower lower. Prioritized, bugs like bugs to be privatized not, taken care of this, will have consequences and, the team should be aware of the consequences and should deal with them and you, should also take responsibility in, the ownership about, either the consequences, of fixing or not fixing it and. This. Is part, of the ongoing engineering. Effort that. Happens hopefully in every company and so, this. Is the way, we we, try to do that and in, terms of context I want to add another perspective, which is zero. Friction and, seamless. And. I mentioned that already so. Those developers. I, observe. And I work with their there. Are mainly working in free environments, it's either the terminal, or their. IDE or the source code management system, and, we. And I try to. Reduce. The context switches as much as often so I try to not approach them in person I try to select them and they, pick up the slack message whenever it, feels appropriate for, them same, with security, alerts right imagine those, happen. In, the context, that you are working on you, don't, need to go to a certain website or to some service to do. Experience those and there. Are there was so frictionless. Actionable. That, you maybe just do one click or you, to just issue one command and 10, of those gets. Fixed. By, reasonable. Recommendations. This. Is this, is the division, I have this, is. Even. A I. See that vision and happening, today with, with the news today and I, see even. More steps. To what as seamless, fully, integrated. Options. For for the engineers hopefully having soon. Okay. So we're almost out of time any parting thoughts and, I'll go down the line here for the audience today, with, regard to the topic so.

You Want to kick us off. It's. All about to come. It's, about taking. Care about. Your co-workers about, your, colleagues in the community, and also about the, stuff to it that you are building. Yes. I think the topic of security fits, into the larger story about open-source, sustainability. As well a, lot. Of the securities that we see is also because maintainer. Lose interest or don't have the time and don't have the resources to maintain, the projects that all of us depend on so, I think not. Just security but sustainability, of open, source and general is important in this aspect I. Think. Companies. Consume. Open source they're kind of tapping into this really great resource. And one way that they can give back is by giving their, developers, who have those skills either, the training or the kind, of the time to, fix. Open source vulnerabilities, if they know how and then, give back to the community that way I. Say. Yep, prioritize. Kind. Of the the long-term security fixes keep. Talking about it so it's, top of mind for people and yeah. Pass your jenkins service make sure they updated. My. Takeaway from today's panel, is i've learned that there's a bunch of intrinsic, or extrinsic levers. For folks that you, know on this path of security, that you can use as an engineering matter eat engineering. Managers developer, yourself, or even within the community, to say hey, there's, some things that you can do and by doing X you know this is the outcome on the other side right and. Then the other part of this is like really reducing, friction and helping, developers understand, and assessing risk earlier on and the. Software. Development lifecycle I, want to say thank you to all the panelists for being here today and I want to thank you all for listening, security. It's the thing we all got to do it thanks. Everyone. You.

2019-06-04 23:13

Other news