 All right, sounds like we're live. Well, fantastic. So I guess good afternoon, everyone. My name is Brittany Isennis and my partner over here. Michael Grouch, hi everyone. So, and today we're gonna be talking a little bit about open source with the security mindset. We want to kind of share our experiences as well as our partnership on what we do in the realm of open source and security. So before we get started into that, we're gonna do a little bit about talking about ourselves. So kind of my path to getting to open source. So as I mentioned, my name is Brittany Isennis. I'm a program manager within the program source open, the open source program office at Comcast. And my main focus is basically on delivery of open source software as well as community building. My journey to open source is relatively a pretty interesting one. I did not initially start off thinking that this was my path. I thought my path was going to be education. And so a fun fact about me is that I'm a lifetime certified K through sixth grade elementary teacher as well as a N through 12th grade special educator. I graduated from Temple University in 2011 and I taught fourth and fifth grade in like kind of the deeper part of the city of Philadelphia. So it was really, it was a really interesting experience and really powerful for me and my students. And together we moved mountains, little kids and I moved mountains. It was really, really, really cool. But when I was working in the charter school and realizing there was such a need for technology for these children to become successful. I wanted them to be ahead of the curve. I wanted them to experience everything as well as just get just really well versed in everything because that's kind of your way out and really where the future is going. So I became the lead technology trainer at the school and then realized that there's other doors that can be opened up in technology and education. So I moved into educational technology and I worked with superintendents and teachers all across the country helping them utilize this online reading program, which was absolutely fantastic. And we saw lots of great results in children who were reading at or above their grade level and you could tell within one year, it was fantastic. And so being completely honest, that was a beautiful, wonderful experience but it was really far away from the city. So I'm currently living in Philadelphia and traffic is not great. It's not fun at all. And commuting an hour and a half every day just wasn't doing it for me. I was like, I can't, I can't do this anymore. So I applied at Comcast and lo and behold, working at Comcast led me to the team that I'm with now which is really, really fantastic. And now I'm an open source program manager. And so with that, I will pass that over to Mike and he can share a little bit more about himself. Sure, thanks, Brittany. So my name is Mike LaCroche. So I'm a security automation engineer for Comcast. So my path here is a little different than Brittany's is I'm sure. I got my master's in computer science. I actually was in a starter company for about eight or nine years. And we worked on hosted voice for IP. So being a startup, I wore many hats. So it was implementation, it was support, it was programming, it was automation, that sort of thing. I did that for about eight years, went to Comcast actually as a contractor, as a voice for IP, IMS tester went back to the startup to come manager and kind of create processes around everything, do some more automation, that sort of thing as an implementation engineer manager. And now I'm in Comcast. I've been here for about four years. I had a lot of different roles. I was a documentation specialist, then migrated to a network engineer. And then with that, I did some more automation engineering and now I work with the security team, mostly focused on security pentesting and also anything related to automation tasks and network tasks. So the open source team, the Bernie takes care of, she needs someone's security and being that I fit that role in the fact that there's a lot of need for coding, a lot of need for networking. And I've been through that, lower cycle process, I kind of fit in really well there. So yeah, that's it for me. So something that Jeff's excellent, thank you. So something that we're going to chat about next is open source keeps developers happy. It just, it really does. It's paramount to work together with internal and external technologists for quality, well-rounded projects. We know open source practice and methodologies bring people together. We were speaking with Angela Brown a little bit before this session started. And she mentioned that there are 4,000 people at this conference from over 100 countries. And that is so amazing. Where else would we have that sort of opportunity to connect with people from all over the world on such a different varying experienced level than without open source? And that's just something that's been exciting. Meeting people from all over the world working on our projects. How fun was it to mail out swag to someone in Singapore when they were working on some initiative for us for Hacktoberfest? And that was really cool. And then we've talked to so many companies that really want to bring open source into their space just because they know that technologists are happy generally when they work with it. And then it really does attract young talent. And then open source as well, if I'm a technologist and I'm working on an initiative that I know already exists, why is my company making me reinvent the wheel and having me just redevelop something that already happens that costs so much time. It's so expensive and it causes burnout. And so it's just, it's really, really, really important to keep that mindset and keep that focus that we open source keeps people happy at least for myself, I can say that it does. So something else that's pretty cool is for those of you that don't know, Comcast, we have a pretty strong open source initiative. We're getting there. Well, I think I'm so proud of where we're going and I'm so excited that we're there. We have roughly 200 projects in our public repo which is Comcast.github.io. Some of these projects that you may be familiar with would be a Trickster. We have Vinyl DNS, a brand new project that we just came out with that's built completely on the Rust language is Capsule, Guber Healthy. I highly recommend checking them out on Comcast.github.io. And a little history about our office is Comcast started consuming open source in 2006. And then they heavily as a company started contributing very, very, started consuming it in 2006 contributing back heavily in 2010. And then come 2011, we launched our first projects with RDK and CDN. And then throughout 2013 to 16, Apache Traffic Control has been formed and now that's incubated in the Apache Software Foundation. And it brings us to 2017 when the team really came together. The team is comprised of our leader, Nithya Ruff whom many of you know as the chairwoman of the board at the Linux Foundation. Sheila Sabi, she's a big community advocate and community manager on our team who also spoke at OSNA yesterday on our ambassador program. And I really hope that you were all able to check that out. We have Pristakare and Ananya Malaku are fearless leaders when it comes to compliance because we all know that is tough stuff. We need to have their sharp, they're helpful, they're fantastic. And it's really taught me a lot as well on the side of compliance. And then Carl Ivey, he just leads our development team. And so that, and then myself came onto the team in 2019. So I've been there for a year now. It's a pretty rock and roll group. I really, I really am proud of the work that we do. So please check out Comcast.github.io. And, you know, since we have this solid focus group, we've been working really, really hard that we open source quality projects. We wanna work with people from all over the world. We wanna develop and contribute back to as many open source projects as we see today. And we wanna make sure that we can support our team. So a little bit more for those not familiar. So we support the roughly 7,000 technologists. It's pretty cool that our current Ospo, we support about 7,000 technologists, which is fantastic. Our offices, we have offices in Austin, we have offices in Philadelphia, Sunnyvale, Denver. We also have a really large, wonderful office in Chennai, India. It's fantastic. And we support technologists. You know, I've talked to technologists all over the world, Italy, London, South America. And so we support people from all down there. So kind of getting back to what we were talking about is how the Ospo and security partners together. And so this is something that, you know, Mike and I have worked together on I don't know how many companies do have this type of partnership within the security team and their open source program office. I'm gonna share a little bit about what we do here. So as I mentioned, the partnership's very strong. We have a level of transparency, which is so fantastic because we wanna make sure that we, our developers have clear guidelines in which they should be following for successful projects. And Mike will definitely be talking about these later. You know, we have governance where we've established the best practices of developers can consistently remain protected. Mike and I, with the communication, it's always been clear throughout the entire open source request approval process. Not only do we talk to each other throughout, but we also keep all the developers on the same page, which then enables the trust within the partnership and then it makes and aids into that low barrier for entry that technologists and developers can get into when they want to start doing open source within the company. And expectations, going back to keeping developers happy, Mike and I just within ourselves, just through working together, have clear processes in which we select time frames throughout the entire approval process. And these honestly were just established by Mike and I, you know, talking to one another about how we both work and what are some of the best practices that would make us both successful and not stressed out because who wants to be stressed out? I don't, I don't want that. So going into some more of the things that we do within open source at Comcast, is we have this group called the Open Source Advisory Council and this group was formed back in 2013 because once, you know, the company realized, hey, we're consuming and contributing, we gotta just kind of see what we can do to make sure that we have a process to this so that way we can keep track of everything. And so this group is a very focused group that determines which projects go to open source as well as which contributions, bug fixes and so on. And as of right now, we have a really strong approval rating. I think we're at 95 to 98% every year. Anyone that wants to contribute back to open source can be approved. We ensure that the developers and technologists are successful and they make the contributions by we provide the guardrails where necessary. And we'll definitely talk about that later. We're gonna feel free to add any questions. We're gonna get deep into a question time. I have a feeling. So please feel free to add any questions into the chat. And then once the presentation is over, Mike and I will get to them and make sure that everyone gets an answer. So we have the oaths. So we lovingly call them the OSAC, the Open Source Advisory Council. They're comprised of members of the security team, legal team, we have our high level engineers that focus on all of the technical side of things. And then also the open source program office. So a little bit more about it. So on average, we have roughly 150 to 180 open source contribution requests from our internal technologists going out into the public. And so they flow through this council annually. And so kind of a high level of what I do and what Mike does is I love being the developer advocate. I wanna align best practices and then also have things, making sure that the technologists are following into the compliance space because we want to protect them. But I also triage out all next steps. If I look at contribution, I'm like, okay, well we should talk to this group of folks together. Let's see what we can do. So, and then we work together for the council success. That's kind of what we do. And then on the security side, which Michael be talking about later on in the presentation, he does scans and he also provides advice to the maintainers for best practices. So we know the word council is, it's very intimidating. It sounds, you know, because we're coming at it from a larger corporation perspective. You think council, you're like, oh, I don't know. This seems like if I do something here, it's gonna be very formal. I don't know if I should even try. It's not. We communicate that through the develop the technologists. We want them to know that it's not hard. Please reach out to us. Please, we want to break down the barriers for you. We want to promote your projects. We want to walk you through the process. Don't be scared of a word. You know, it's technology. We'll get you there. And then also another level of balancing, which is fun in its own way, is how we keep the company happy. So we, you know, like I mentioned, I work with legal, I work with the compliance side, and then I work with security because we really, you know, want to make sure that everyone's protected. So with that being said, I think that's a wonderful caveat to open up to have Mike come on board and talk a little bit about what he does on the open source advisory console. So my role, like I said, ACOMPGAS is an automation engineer and security pentester. So my initial goal with the open source team is to really go through all the code that they put up there, talk to the contributors, you know, kind of see what the purpose is, just kind of talk out how they got to the different ways you got to it, and I'll kind of include to this later on and take it from two different angles, which I will also talk about later. You know, support the developers of the best practices that we need to put stuff in repos that are safe, and also the best advice to get them for making things secure and also supporting the company, you know, make sure that we at ACOMPGAS aren't giving ourselves away with a different security vulnerabilities in public GitHub, for example, and kind of give advice to the open source team as to how to not do that. So I'll give to Brittany. Honestly, you know, why does any of this matter? You know, we've been talking a lot about why it's important to have partnership and security, but why does this matter? We always think that, yeah, it's common sense. We know what we should do, but in all reality, obviously, you know, we live in a world where chaos exists, it does, and open source code, it can really, really, really invite dangers that you just wouldn't even think about can happen. And so Mike's gonna go back and he's gonna share a little bit about what sorts of things he's seen and what sorts of things you can do about it. Great, thank you, Brittany. So we kind of see it through two different lenses. You know, we see through the eyes of the open source community and through the eyes of our employer. This is ACOMPGAS. So, you know, there's kind of a level of trust with the open source community that, you know, we are gonna contribute code that's not going to leak information or have viruses or, you know, leave the person open for any attacks. So we obviously want to be a good place to go for, for a good, useful, secure code. And, you know, we, ACOMPGAS obviously benefit from open source and want to do our best to give our projects to open source to people to, you know, develop and, you know, use for whatever they want and kind of increase the life cycle that way. And then the other side is to protect our IP, our intellectual property, you know. We want to scrub the code of anything that's going to expose our company to hackers. You know, nothing's worse than having your name on the front street of the Wall Street Journal, you know, like a lot of companies have in the last five, six years. I'm sure everyone has seen. So, the first thing I want to talk about is the trust factor. So we want to be a place for developers and go to get open source contact. Like I alluded to before, you know, we want to get back to the community and have people improving the code, the life cycle of the projects. And obviously any breach of trust looks bad for your company. It doesn't really matter what the source is, you know. If any issues come or are tied back to bad code, it's going to come back to us. And we don't want to be, you know, in that position where we say, hey, we put this bad code on the internet for you guys to use. And it came back that, you know, something malicious happened to it. I put down there as an example, the malicious Python library. So for those of you unfamiliar, Python has built-in libraries that you use, you know, for third party applications, you can use a port or people upload that you can use. There's been a couple of times where people had imported and got through the cracks, some third party applications that you can use and that end up being malicious. So one example, there was this date time util, most times you can just use this to set the time or whatever. And another being a malicious code that will steal your usage keys and send it back. So obviously, you know, the reason I bring this up is that if we didn't catch this, you know, this is something that we use in our code, you know, the blame would be on us because we're the ones who published it. So we obviously want to make sure that those are clear of those kind of issues. And hackers be hacking. So GitHub has extremely powerful search capabilities. You can search by regular expressions across all different repositories. You can search by passwords, you can search by SSH keys, you know, there's really no end there. So, you know, anything that we can do to do the same kind of searching that hackers do that it will obviously save us. And also there is a well crafted automation code that you can use to scour through GitHub, looking for examples. You know, GitHub has API access, so it's really easy to look for certain things in GitHub that, and you can do it in a matter of minutes, essentially, so. And exposures can be hiding anywhere, which will bring me to my next slide, different hacking attack points. Very simple secrets, using passwords. You surprise how many people have used any passwords, just statically set it into their code. These are kind of low hanging fruits. Open, code, and back doors, these are mostly for network or web server projects. These are things that, hey, if you are, if we're developing a web server, we're developing multi-media across platforms, what ports are they going across? Is there any way that anyone can infiltrate that in some sense? Prior to having information, very simple and stuff about the company, whether it be IP addresses, whether it be backend servers, that sort of thing. OS calls, you know, a lot of times, well, it's a lot easier to do a bash call and just find a shell strip and just put that in an OS call, but those can be exploited in a lot of ways. So we try to take that into consideration and make sure that any OS call is safe or they're not used at all. SQL injections, you know, we want to make sure that, you know, database input is being sanitized, that people can't inject SQL queries and any kind of database queries to get either put malicious information or get a malicious information. Compile code, there's a lot of times where developers will either use third party or compile their own code. You don't really know what's in there because you just call it in their function. We try to decompile it to make sure that there's nothing in there because there's a lot of very third party, you know, free to use compiler apps out there that can easily do that. And hopefully there's no kind of information that'll keep us accountable to any issues. Comments or comments or comments. There are, you know, obviously, depending on language, there's many ways to make comments and then make sure that, you know, a lot of times our programmers or contributors use useful things in comments to help people who are reading the code but they also use things that can be, for example, used for social engineering. You know, talk to this person about this, you know, using any kind of information, we want to kind of keep that away. And Git history, you know, Git has, obviously, we want to scour through the history of all your Git commits. You know, you could commit your password and get in your first commit and then, you know, 3,000 commits later, you forget about it or it lets them scrub and you can still get that information. So we make sure that that is not existing. So what can we do about it? You know, are we victims of room faith? Should we just hope for the best or are we just holding on to your life for this sad person in this thick, which is actually me. This is something that me and Brittany kind of joked about but this is me climbing Kilimanjaro and there's actually a ledger, so don't worry, I didn't actually fall or hold on to your life. So code review is kind of an art in my opinion. You know, there's a lot of ways you can do it. You know, you can scour the code but that would be a full-time job. Obviously for a thousand line commit, you know, that's not a big deal but you know, for a, you know, something that has multiple contributors and it has multiple folder structures, you're gonna need some kind of tool or something else to help you out. And you know, we want to assess intelligibly and not haphazardly. Knowing folder structures, knowing frameworks will help you look for issues in a much easier process. And knowing your audience, knowing your language. You know, I'll touch about this a little later but in general, you want to get ideas what the languages are using, you know, it'll speed up that process being knowing where most of the secrets are being held, you know, most folder structures are a little more insecure for certain ways. And also, you know, if you're working with containers, working with macro windows, so forth and so on. Tools can be your best friends, you know, they, there's a lot of third-party and free tools that you can use to help you look at your GitHub code or look at anything that's being contributed and find a lot of the low-hanging fruits and any other issues there. It could also be your enemy because you're gonna have a lot of false positives too so you gotta make sure that everything's kind of skewed out in that way. But in most cases, it's your friend. So next is skill sets, code, what to really know. So you gotta know your goals and purpose, you know, who's it for, what to try to solve, you know, it's hard to turn people into hackers kind of day one but information gathering of, you know, why the coder want to do the thing they did, you know, will help you for next steps which is basically, you know, know where to look. You know, for example, you know, anything that's during your network project, you wanna check server settings, you wanna check firewall, you wanna check open ports, IP addresses, et cetera. And different frameworks, you know, know where secrets are held for each framework because each, you know, obviously each language, each framework have different places to put, you know, the database access wouldn't any kind of a stitch keys, that sort of thing. Get ignore in the likes. You know, obviously in getting more pages you put in there all the folders and all the files you wanna be used. If you're a hacker, you're gonna wanna look at that and say, oh, these are probably sensitive folders. We wanna make sure that those are being safe on our end that people can't access those through the code itself and second of all languages. Knowing multiple languages, you know, each one has a runway point. We wanna make sure that there is, and there's places of issue high for all of them. And knowing your audience, you know, who's ingesting this, you know, knowing they use it for in what scenario will open up ideas how it could be used maliciously. Next is what tools we use. So, you know, there are dozens of tools on the market, you know, I, there's no one size fits all and, you know, I implore you do your own researches on this because, you know, one tool for one person is not gonna be the same for others because everyone has code uses in different ways. But for the lazy, this is what we use. You know, for pattern recognition, we use Truffle Hawk was a very low maintenance kind of thing that's based on regular expressions that we could put, you know, it will find Azure keys, AWS keys, you know, passwords all in your GitHub repo is all in the history. So anything you're gonna make public wanna make sure that those are obviously scripted out. Decompiler is obviously that is language dependent. You know, we use on compile for Python, we use JDGY for Java, et cetera. All those are pretty open source and you can find those pretty quickly. Code injection and kind of a catch all, we use check marks and there's a couple others that are out there on the market. And what this does, it actually kind of takes your repo and it will take inputs for different ways and go through the functions, how they get to the other end. So it would say, hey, this could be, this object isn't serialized, this is open to people, you know, in any way maliciously you can use any inputs. So a really good tool. So next is communications, how to put it all together. So it starts before they write their first piece of code. You know, we at Comcast kind of hammer home the importance of security. We have a lot of security in place, you know, a lot of different processes along the way. So, you know, obviously it's the big initiative for IR and as you can, I'm sure you know, you know, security is the big initiative for a lot of the major companies based on a lot of things that's happened and, you know, we're making sure that we wanna be secure as a company. So we hammer that home and it kind of helps the coder to be able to write with a security mindset and like also putting yourself in the mind of the contributor, you know, find out why they did what they did. So if they're, if they're making something, you know, why they coded it this way, you know, one of the biggest things obviously that I mentioned was OS calls, you know, is that the best way to write this? You know, is there a better way to do it? Have the coder kind of explained it and kind of figure out whether they, if that's the way they did it because they were lazy or they're, you know, when they went through all the options it was the fastest, it was the best way to do it, that sort of thing. And then last is communication, process and remediation, you know, with the open source advisory council, it's been great that we had like kind of a solid process involved. You know, we have a website with steps involved. So there's constant communication with the group of you, constant communication with OSAP team so that we can work with them to resolve any issues, you know, quickly as possible. And I'm gonna hand it off to Brenda now. All right. Well, thank you so much, Mike. That was very well said. Yeah, I really liked that a lot, very good information. So, you know, like I mentioned multiple times, we want to get best practices for maintainers. So to really have that home, a lot of these do sound like common sense, but common sense only works when you practice, you know, you need to practice, you need to practice what you preach, you need to make sure that you're like, oh, yes, I always check in on my project regularly. Well, think of, do you, you know, think about it. You know, always research and resolve vulnerabilities. That's one of the things that I have to work on is vulnerabilities come flying in and I'm, you know, have to not contact all the maintainers and well, it would be good if, you know, always having a maintainer being like, yes, we're on it, we're on it, we're gonna resolve it. You know, another thing that's great as a maintainer is be transparent. You know, everyone wants to be able to understand exactly why you're working on what you're doing and why you're doing the way that you communicate. So always, always be transparent and then also create a little barrier for entry. You know, for somebody like myself, I'm very new to open source. I'm very new to developing and technology as a whole. And so it's something I would like to get more so into. Even if it's documentation changes within a README, you know, I want to have something that's a low barrier for entry that doesn't intimidate me. And then something else that's so important and this is something I've been hammering home so much lately is just a very clear contributing guide, a very clear README that's so important for just the low barrier for entry and it's inviting. Oh, okay, so let me read this contributing guide. Oh, this makes sense for me. Okay, well, what is this contributing guide saying potentially about vulnerabilities, what to do, what not to do, that's fantastic. And then contact info. I have tried to reach out to so many technologists over the past year of my life and I can't find them because there is no contact information and going down the deep dives, Twitter, GitHub, LinkedIn, who knows where I find some of these team members. It would just be always have contact info in your projects. And then also most importantly, I feel is just be kind. You know, you want people to be excited to contribute to their project or somebody, you know, like myself, it would be a very new to open source. I, if you're kind to them, that's pretty awesome because they're like, oh, this project was great. I'm gonna go tell all my friends. I'm in this particular community. I want to be more involved with this. So I think that that's just one of my, that's one of my favorite, that's like my motto in life. So be nice, that's not that hard. It really isn't. And then of course, we all are experiencing this right now. This is fine. Everything's fine. No, it's not. We understand that it's not, but we have to avoid burnout, you know, in the technological space, we have to avoid burnout. And we find that many maintainers create a project to set it to forget it or they are burnt out and they don't want to work on it anymore. And what I've talked to many technologists about is that they are feeling very stressed and very tired at the moment. And so ways to mitigate that is to reach out to your community, find a trusted committer, find a team member that can be your partner in, you know, poll requests, reviews, things like that, somebody that's really excited, like let's say you were very kind to someone and they were grateful and appreciative and then you trust them, you have rapport, ask them to be your trusted committer. And we all know if a person's completely exhausted and burnt out, that it's super easy for mistakes to occur. Like right now I'm in the process of moving across states, so apologies if I'm a little out of sorts and leaving in two days. So, you know, if you're exhausted, it's easy for mistakes to occur. So, and then another big thing too is if you no longer care about the project, find a new maintainer, reach out to your community and see if anybody in your trusted sphere wants to take the helm. And then also the best practice is to archive it and make it read only and then once again, leave your contact info. It makes the world so much better. So please, if you have credit index out there and you don't have your contact information on it, please do me a favor, can you do that for us? And then that's, I mean, essentially team, that's our presentation. We're at the question and answer part of it. You know, we have one question that's in which is fantastic. Someone wrote in, how does one of our technologists become part of the current like Comcast open source advisory council? And well, essentially you would talk to me and then we have, you know, Mike and I talk about a partnership. We worked together at the beginning of the year. I think that was the beginning of the year or last year. I don't remember, my time has no relevance. I don't remember. Yeah, exactly. That's it. It was like mid year last year, yeah. Mid year last year. So Mike and I worked together and be like, okay, well, Mike, for example, is like the only one on the security side that's doing all of this work. Well, I didn't want Mike to get burnt out and say like, this is fine. So I was like, well, Mike, let's put a set of, what would you call them like checklists or requirement pieces? Like if somebody wants to get involved from your team, we would just bring them on, chat with them, see their experience against Mike's experience and see what Mike says would be great. And that's kind of how it is. Essentially, like I mentioned, word council is not meant to be intimidating. It's just asked. I'm a very approachable person. Mike's a very approachable person. So you could just ask us, it's fine. And then best way to get ahold of us, I would say for after this presentation, you could follow me on Twitter. I put it shamelessly at the bottom, just every single one of my slides. Apologies there. But please, please, please shoot us an email. At least I mentioned, I'm gonna be in and out of this lack throughout the rest of this event, which is unfortunate, because I really wanna get to know so many of you. But please just shoot me an email because my life is a little bonkers right now. And I think Mike, probably. Yep. I think we have one more question there for me. Yeah. Oh, do you have any tips for the folks who don't like leaving their contact info because of security concerns? Well, I mean, what do you think? Just make another Gmail address and just check it every once in a while. That's something you could do, Mike. I don't know, that's what I would think. Yeah, I'm sorry. Yeah. Wait, sorry, I'm sorry. Oh, I'm down. Yeah, I mean, yeah, sorry. Yeah, we missed one above there. But anyway, just wish you don't leave their contact info because of security. I mean, distribution groups kinda help too. A lot of times we, for at least as I'm concerning, we make distribution groups for all of our projects, even if I'm the single person so that we can kind of flow people in and out of it so we can leave the email address there and it will go to certain people and that will kind of be a line of barrier between your contact information and also putting stuff online essentially. And then there's one regarding, yeah, how can you make the upstream open source projects most secure? I'm guessing that's meaning that anything that's already been published, is that kind of what that is? You know, we actually do open scans on all of our things. You know, we were basically, as security team, trying to hack before the hackers hack, you know? So, you know, everything that I said here is something you can do on your open source, you know, our public open source GitHub, if that's so. And when it comes to getting back, you know, we, because of, you know, Bernie said, with that contact information, you know, if we find anything, we gotta alert them right away to make those changes. And then, yeah, yes, we contribute back to security fixes when we do season. And we try to erase the GitHub history, you know, a lot of the reasons you could say, oh, I found this fix, commit the new one. Well, it's still in history, it's still there. So there's different tools actually, kind of, get rid of a lot of that information so that your Git history does not include any of the malicious information that we have on there, or any like IP information. Then we have another question. I've experienced a time, and Mike, this is definitely something that I would, I kind of want to lean on you. Have you experienced a time where an open source project didn't meet security standards? If so, did you remove it and how did you deal with it? Yeah, so most of the times when we started out with a repo, it's private, and we're allowed in there. So there's that level of security, which is good, that, you know, if anyone does make mistakes, you know, it's only within our realm. There's rarely a time where you can, you know, have someone just take down an entire repo, but there are a lot of times where there are issues. A lot of things, you know, the things we see the most are like SSH keys, and passwords, you know, those are the two-hand inputs, or, you know, there might be IP addresses that are statically set in there. And a lot of them that go back to the distributor, just say, like, hey, we found this. These are the steps you need to remove it or replace them, and that sort of thing. So, you know, the most important thing, you know, Bernie will, you know, sure agree with, is that, you know, don't make things public unless you're actually sure that you don't have this information on there. Yeah, I think that's really about it. So unless there's another question wants to come in, I think, I just, I personally like, I just want to thank everyone for attending. This was fantastic. This was the first talk I've ever given an external event. So it's really, it's really cool. And that was, that was my cat that just jumped behind me. She's somewhere back there. But she's, yeah, she's all over the place. But, so I just, yeah, I want to thank everybody for attending, and then especially a big thank you to you, Mike, for wanting to be on this wacky conference journey in time of COVID. Right, yeah, that's great, thank you. Yeah, thank you all so very much. And to everyone that hung out, great. Judith's an email, loved to chat, tell jokes, whatever. It's all good. All right, I think that's about it. Great. Thanks, Jeff, high fives. Yeah, thanks Jeff. Great, thanks so much. Boom. Ha ha ha. Ha ha ha ha. Yeah, I don't know. I don't know.