Every week on Cyber Work, listeners ask us the same question. What cyber security skills should I learn? Well try this, go to infosecinstitute.com/free to get your free cybersecurity talent development eBook. It's got in depth training plans for the 12 most common roles including SOC analyst, penetration tester, cloud security engineer, information risk analyst, privacy manager, secure coder and more. We took notes from employees and the team of subject matter experts to build training plans that align with the most in demand skills. You can use the plans as is or customize them to create a unique training plan that aligns with your own unique career goals. One more time, just go to infosecinstitute.com/free or click the link in the description to get your free training plans plus many more free resources for Cyber Work listeners. Do it. infosecinstitute.com/free. Now, on with the show.

Today on Cyber Work, I'm talking about development security with Jacob DePriest, the VP Deputy Chief Security Officer at GitHub. In 2021, GitHub significantly ramped up its security department. Jacob told me all about the commitment to security that's come about and how you can move your own organization for any developer focused security team. Whether you're just hearing about GitHub now or you're using GitHub from the moment your workday starts, you will absolutely want to check out this episode of Cyber Work.

Welcome to this week's episode of the Cyber Work with InfoSec podcast. Each week we talk with a different industry thought leader about cybersecurity trends, the way those trends affect the work of InfoSec professionals while offering tips for breaking in or moving up the ladder in the cybersecurity industry.

Today's guest, Jacob DePriest is the Vice President, Deputy Chief Security Officer at GitHub. DePriest has over 16 years of experience in the field of cybersecurity, engineering, and open source across both the public and private sectors. Previously, DePriest held a senior executive role in the National Security Agency or NSA of the United States, and founded his own tech consultancy firm in Washington, DC.

So today, we're going to be talking all things GitHub. We'll bring it up soon. But in 2021, GitHub made some important strategic changes that Jacob was part of, and I'm looking forward to hearing more about them. So, Jacob, thanks for joining me. Welcome to Cyber Work.

Thanks, Chris. Really happy to be here. I look forward to our conversation.

Great. Me too. So yeah, just by way of breaking the ice, let’s start a little bit about your origin story. How did you first get interested in computers and tech? What was the initial draw to all of this stuff?

Yeah, I think like a lot of folks drawn to tech, as a kid I played with Lego probably took apart and attempted to put back together way too many of my parents’ electronics in the house. Not always successfully, unfortunately.

Were they cool with that?

For the most part. They were cool with it. I first kind of got fascinated with PCs in kind of middle school, high school, and then took a programming class and math class in high school and had a really great set of teachers that kind of pushed me along the technical path. I knew I liked the classes. I had no idea what that meant. So, they were like, “You should really think about engineering, if you like all this stuff.” And then the same teacher, my math teacher in high school, got me a summer internship at a local engineering company who built – they built AM radio towers and components. So, I like did software design and build for them during the summers for my first couple years after high school and just kind of pulled me into like practical engineering work, and then also started building a love for software defined radio around that as well.

Now, do you have a sense of whether your particular high school experience was noteworthy in the sense of, were there a lot of schools in the area that were offering this sort of extensive level of computer experience? Or do you feel like you really – that this was like an outlier that you were very lucky to be part of?

I think it was lucky in the sense that I had great teachers, right? I think that the classes in and of themselves weren't remarkable. I think it was someone taking an interest in seeing like, “Hey, this person really is interested in this and is really lights up when we talk about these topics, and didn't just brush it aside and kind of spent the extra time with me.” I actually sent that teacher a note, a few months ago. We reconnected on one of the social media platforms and just kind of told the story because I don't think they ever knew that. It had a huge impact that kind of shaped the course of my professional life.

Oh, I love to hear that. Yeah. And I've done that for a few teachers and they're always just thrilled because yeah, it can be very exhausting, otherwise. If you don't know what happens with any of this stuff at the end of it.

Indeed.

So, going further down. I like to look at my guest’s LinkedIn profiles, because it gives me a sense of the type of work that you've taken out over the years, and the types of roles you climb through to get through where you are now. So, I want to ask you in whatever way you feel comfortable about your journey up the ladder in the NSA. So, from 2006 to 2021, 15 years, you move through NSA roles starting with a hardware/software engineer, and technical lead position, up through engineering manager, technical director, director, developer, productivity, OSS evangelist, and finally, senior director, IT integration. So, none of these promotions seemed terribly unexpected in terms of taking a wide lateral step. But it does seem like these changes of focus gave you a huge jump and how to handle the overall view of IT in a way that makes sense to your current role at GitHub. So, can you talk about your time at the NSA in this regard and how it built your skills toolbox?

Yeah, absolutely. I mean, kind of going in, to cover the last thing, first. I think the diversity in those jobs and roles did give me a special appreciation for being able to do something as complex as security leadership at GitHub, because we're an incredibly technical company. So, being in security team also requires a fair bit of technical know-how in terms of engineering and sort of the whole span of the system.

My journey in NSA, I started out in software defined radio. I came out of grad school with software defined radio engineering experience, and did my master's work in that. I spent a lot of time focused on like real time processing, and how to blend, really complex math processing with reusable software components, which was super fun. That's when I kind of started getting into developer tools and open source.

One of the projects in there, we ended up going through the process to open source, which took a really long time in the government, particularly at NSA, because it was fairly early on. We were the first project to be open sourced from NSA, but one of the larger ones at the time. The combination of like building things for developers and open source has been something that I've done for a really long time and really enjoy, and kind of moved into people management around that time as well. So, did that for a few years.

Then, kind of had the opportunity to pivot into more cloud processing, distributed processing with other technologies. That's the fun thing about a place like NSA and a lot of federal agencies are similar, where you can reinvent and take what you've learned to build it into something new and shift and still kind of have multiple mini careers inside a single agency. So, I kind of came off of that, and then went and founded this developer productivity team. So, we were responsible for kind of all the developer tools at the agency. It was kind of the first time it had been centralized like that. So, everything from developer security, to kind of the normal CI/CD pipelines and things like that. That was just a fun opportunity to kind of build that team out, get the funding, get the buy in, do all the work associated with that. And then that kind of led to the IT integration work in enterprise security work of, okay, now taking those experiences, and how do we help scale that for the rest of the agency in other kind of core productivity areas.

So, it kind of all built together. Interestingly, at NSA, when you're doing engineering, and you're building complex systems and deploying them, you're also doing a whole bunch of security by default, by nature of the agency. So, going after NIST best practices and software standards, really, my entire career, just sort of naturally translates into a security role if you combine in some of that enterprise IT experience as well.

Yeah. I agree. It's funny, as you explained it, I realized that the path isn't quite as linear as it looked to me on first blush. It just seemed like just scaling more network creation or system creation, or what have you. But yeah, there really is a lot in there from, like you say, from people management to the sort of compliance and risk management elements and so forth.

Now, you said that the NSA sort of offered you or allowed you kind of a wide latitude in terms of creating your own systems. Can you talk about that? Is that still the case with things like CMMC? And all these different regulatory frameworks going into mind? Do you still think that there is that kind of flexibility at work in terms of like taking the initiative and creating things to your own style?

Yeah. I mean, I think ultimately, it's driven by what the mission needs and what the outcomes you're trying to achieve, really like any company. I don't think the agency is different in that sense. I think, it is clear to meet some of the security standards that are required, and they are very rigorous inside a place like NSA. And the ability to do that in a way that leverages modern technology, I think, is actually improved over the years as well. So, I think there's just a ton of opportunity to develop in those spaces, very similar to how you would on the outside. I mean, there can sometimes be additional security controls that maybe the average developer out in the industry doesn't have to deal with. But I think there's still a fair bit of autonomy in how you solve for the mission needs.

Got it. Can you talk about your average work day or work week as VP Deputy Chief Security Officer at GitHub? Because I think people want to know, if I get to this position or work towards this position, what would what would be my primary responsibilities or tasks that I can count on to take over my day? So, can you tell me a little bit about that? What point of the day does your to-list sets itself on fire?

Yeah, that's a fair question. So, my day to day responsibilities are essentially running the day to day from the security org, inside GitHub. So, that includes our product security teams, which includes bug bounty and product security, incident response, and kind of our architecture security review process includes security operations, like threat hunting and incident response and platform review, things like that, anti-abuse, GRC, and also security lab, which is kind of our outreach arm for education, training, and all those things.

So, I think what's interesting in terms of like how the weeks unfold, GitHub has a very strong culture of focus on people and connection. We're all pretty much 100% remote and async at this point. So, there are a few offices around the world, but for the most part, we all work remotely. And so, I think I spend a lot of my time in one on ones, with my leaders, with peers, with other leaders, kind of building those relationships and being intentional about that. I think it's really important, particularly in a remote environment. So, I'd say like, 40% of my time is people oriented, around people, whether that's coaching, being coached, having peer conversations and things like that.

I try to spend about 30% of my time on organizational work and kind of mission focused work, like what do we have on the plate this week? What do we need to do? What are the kinds of organizational priorities that need to happen? I'd say, ideally, 20% of the time on strategy and company level leadership. So, as an executive at a company like GitHub, I think it's really important to also look at how to level up the entire company. My primary responsibility is the security department, but I think it's also important for leaders to be part of other leadership conversations around the company, whether that might be a mentoring program, peer coaching, whatever it is, being present and engaged in leveling up the entire company, and learning as well, I think is really important.

Then the last bit, I tried to spend some amount of time with customers, and doing external engagement as well, particularly in security, I think it's really important to be in front of customers and hear what their struggles are, hear what their perceptions are. And I think, it's interesting security shifting to be a market differentiator, I think, for a lot of companies where it's not just like, “Oh, yeah, the security team keeps folks safe and keeps the product safe and we don't really ever talk to them. They just kind of, are off over there.” Where really like, consumers and other customers really want to be discerning buyers and want to know how we do our work and how we keep them safe and how we keep their data safe. So, I've tried to spend a little bit more time on that, than I probably otherwise would.

Okay. Yeah, that's, that's good to know, especially the sort of people element and it sounds like you still sort of have your hand in terms of evaluating what people are doing. And I also I know that as a C suite member, that you have a sort of communication element to your job in terms of, I'm assuming, making the board understand why you're making certain decisions and why you're asking for more money for this or that or what have you. Because that's something that our guests are always talking about is cybersecurity, like, you can learn the tech, but you really need to know how to communicate it and how to communicate it to the non-tech sector. Is that part of your job as well, as sort of, not evangelist, but someone who can make hard concepts easy?

Yeah, I think that's definitely true of really any senior leadership role of being able to communicate like incredibly complex issues in a way that resonates, ties to business outcomes, ties to impact. Thankfully, my boss who's the CSO and engineering SVP has a good grasp on all this as well. So, quite easy to chat with him and communicate that as well. But teeing that up for not just the board, but also customers and other stakeholders, I think is important as well. So, definitely, there's a lot of time there. And then, obviously, if there are security incidents, we all pitch in and roll up our sleeves and go dig into that. That’s, obviously, just part of the job aid and security as well. Thankfully, I have an amazing team that I trust, and they're empowered to go solve these problems. So, I think that makes my job quite a bit easier.

Well, yeah. We'll be getting to that team real soon here. I'm excited to learn more. So, we gave plenty of warning at the top of the show what this episode is about, and we've said it so far, but just to reiterate, this is about GitHub. So, asking what is GitHub to a developer might feel like asking what is a library to an obsessive reader. But if you're a cybersecurity student, or professional or want to be soon, you're probably going to be spending plenty of time on GitHub, whether searching for the exact tool you need, or maybe just browsing it to see what's out there. So, for listeners who are completely new to this space, can you explain briefly what GitHub is, who uses it, who contributes to it, and its current role in the software development field?

Yeah, happy to. I mean, at a really high level, GitHub is a cloud or SaaS provider. We also have on prem solutions, but it's a way for developers to store and manage their code, and then a lot of the tools around that. So, tracking those changes, building the outputs of the code. So, continuous integration, continuous deployment, the security tools around that. It's really a platform for developers to build, manage, in the ecosystem that kind of goes around that. So, just to kind of give you a sense of scale, we have over 100 million developers on the platform now, which is pretty incredible, and 90 of the Fortune 100 are customers for the platform. We’re really embedded into the entire world's software development ecosystem in some way, shape, or form.

So, even if a company is not using GitHub as their primary development tool, it's almost 100% certain that they're leveraging some sort of open source package that was developed and built on GitHub. And I think that's another really important aspect of GitHub is, it's not just for customers who are paying customers, there's an open source component to it, that's really core to what we do and have always done.

So, for those not familiar with that, open source is a way to collaborate and contribute to software in a very open way, where the outputs of that, and the collaboration is free and transparent to all, and it's a really incredible thing. So, I think I can't remember the latest stat, but it's something like 95% to 99% of all software has some component of it, that's based on open source. Really, that means that almost whole software has got some component that was built or developed around or through GitHub.

Yeah, and I think that's something for us sort of noobs to have a hard time getting our heads around is that, any sort of software development that you're going to do is going to be made up of lots of other people's code at different points. It's almost like making a cake or something. You're going to have to buy, get all these supplies, you're going to put your own spin on it, but you still need to get the eggs from the store. You're not going to raise your own chickens and so forth.

I mean, can you talk about that? In an average say, like app development or something like that, how many pieces of tools, software, code, whatever, need to be pulled from kind of outside sources versus what's created by the team?

Yeah, I think that's a great question. I mean, I think it really depends on what the outcome is, that the development team is trying to achieve. But I think in a lot of cases, companies and even hobbyist developers realized, what's the value they want to add? What's the harm problem they want to go solve? Usually, that's not reimplementing a thing that's been implemented before. Whether that's text parsing, or a graphics framework in JavaScript, or a core security tool for scanning and looking for vulnerabilities. Most of the time, it's the additional secret sauce that somebody wants to develop on top of those things.

So, often people will start with an open source foundation, pulling these tools together, and then saying, “Okay, how can I combine this in an innovative way, or add to it or build a new, either open source, or commercial tool on top of it, that goes with it?” So, I think, it's not true in every case, but I think many, many developers start with that open source foundation for whatever it is they're building. We certainly do, which is no surprise in our tool in GitHub.

So, since you joined GitHub in 2021, the company has invested heavily in the security team and has doubled down on the company's commitment to fostering better security team experiences across the software ecosystem. So, can you tell our listeners why and how this came about? I mean, I know that my minimal poking around in GitHub, there was maybe a perception of the feeling of a wild west feeling with everything kind of on display and available for you. Can you talk about what brought up the decision to really lock in the security team here?

Yeah. I mean, ultimately, you know, get ups sort of been leading the way in helping developers create secure software for a long time. We were very early adopters of bug bounties, acquisitions, like Dependabot and SML, standing up the security lab. So, I think this is really just a continuation of those investments, and the serious responsibility we take is kind of, as we talked about before, being really central to the software development ecosystem. So, with hundred million developers on the platform, and then more upstream dependencies, there's a huge opportunity for us to really have that impact. And so, I think each member of the security team takes that very seriously. We actually talk about it on a fairly regular basis, like in one on ones and other discussions. But I think it's a recognition, that company also takes it seriously as well.

And just for my own understanding, when you say upstream dependencies, that means, like, for instance, a bunch of different apps might use this one thing – there's one piece of tool and if that has a vulnerability in it, then it becomes a problem for everything. Is that kind of what I'm understanding?

Yeah, I think that's part of it. I think, too, there are so many companies whose products depend on GitHub every day, right? Their developers may spend all day long in GitHub, and then the average consumer who downloads that app on their mobile phone, uses it on their computer or interacts with the bank may not realize that, like that work actually happened on GitHub. And so, we kind of recognize and see that that dependency stream, and do our best to kind of continue that investment and continue to focus on what can we do to make that more secure, make it easier for developers to do their job, and then go from there.

All right, so what are some of the security risks that GitHub faces? What tasks do this in large security team have to perform to keep things safe and on even keel?

Yeah, I think, we probably face a lot of the same tasks that a lot of others in the ecosystem do. There are threat actors out there looking to make a quick payday, right? In our case, because we do have so many kind of key customers, right? That's a thing that we think about a lot. How do we protect our customer data and intellectual property? That's really, really important to us. We spent a lot of time and energy and resources thinking about that.

One of the other things that we spend a fair bit of time on, because GitHub is so widely used, in such a big platform, is how to detect and combat abuse, as well. So, we have a whole team, which is, I think, somewhat unique in the security space, in our security team that's focused on building machine learning models, and creating tools and detections to detect abuse, but also combat it, and we have to do it effectively near real time to be able to handle the scale of the threat actors out there.

Yeah. So, can you talk about GitHub’s role in the area of software security? And some of your suggested best practices in making a developer focused security team? What are some common issues or mistakes that you see in security teams in this regard?

Yeah. I think about this probably in a couple different ways. One, from the developer’s perspective, how do we help developers stay in the flow, and have the security tools they need at their fingertips, so that it's not an interrupt driven process? It's sort of baked into how they do their work. So, if you look at some of our products, like Dependabot and secret scanning, and things like that, code scanning, it's really baked into that GitHub experience. And we provide those also, for free, for open source public projects, as well.

Certainly, our paying customers get those as part of their GitHub advanced security subscriptions. But also, because of the importance to the ecosystem and open source, any open source developer with a public repo can turn these features on as well, which is really cool. From a more kind of – if you take a step back from that developer flow, when I'm talking to customers, the three things I always talk about of like, what are the top three things folks can do? It depends on the customer. It depends on the on the situation. So, this is slightly abstracted. But turning on multi factor authentication, and SSO if you have SSO available, that's just table stakes now, I think, because of so many threat actors going after account takeovers, and all the data like credentials being leaked all the places and you can go purchase them in various darker places on the internet. It's just important to start with that.

The second one we talk about a lot is secrets scanning. One of the biggest threats and most successful threats we see on a regular basis is a threat actor getting access to source code that had secrets stored in it. And then they take those secrets and go do something much worse than just get access to the source code. They pivot it into an infrastructure. They get access to another SaaS tool, and it just kind of keep going from there.

So, we talked a lot about the importance of secret hygiene and storing secrets in the correct place, in the right place, and keeping them out of code when possible, and that's where our secret scanning tools come in. And then, the last one is really kind of basic, but it's what do you have hooked up to your systems, both GitHub and other places? What are your third-party integrations? Because all those integrations end up having their own security risks as well. So, understanding that kind of total landscape, I think is really important. And so those are kind of the three big ones that I tend to also draw from a lot, maybe not exclusively, but a lot.

Well, good, because my next question was about a point number two there. Especially, understanding code, vulnerabilities, and so forth. One of my past guests on our podcast and one of my returning guests, 25:24] was talking about digital identity. But along the way, she noted based on something that we were talking about, that having a background in secure coding isn't just good for analyzing code that your own developers create, but can help you become sort of a quality assurance member of the team. You're evaluating tools and apps found on GitHub to make sure that you aren't introducing issues or vulnerabilities. And like you said, the example of having secrets inside of a piece of code.

So, speaking to that role, into that task, do you have advice for anyone using GitHub or not just secure code experts for navigating the available tools with an eye for determining their strength of security and usability?

Yeah, I think, I mean, to kind of go back to not everybody's got that security background. I think that's okay. And I think understanding sort of the basics and the fundamentals about threats and risks and vulnerabilities is really important. And then leveraging other tools to help with the details of that, I think, is where the sweet spot can be for a lot of people. So, not all developers are security experts who use GitHub, and that's totally fine. That's where I think a combination of things like turning on some of the security tools by default, just so that we’re just constantly scanning repos for secrets, which we do for public repos already as a company, but even private repos, I think it's important for teams to think about that.

And then things like our bug bounty program. So, being able to have that open to where folks can kind of provide that feedback as well. I do think there's also, for folks getting started, how to think about this space, there's some really good guides that we produce, and that other partners produce as well on like, when you're thinking about GitHub actions, which is the kind of our core CI/CD platform. How do you secure that? How do you harden it? How do you make sure that the things that it's building are secure? So, there are really great guides out there for things like that.

I think, for folks kind of looking for that way to step into it, there's another interesting opportunity with Code Spaces, which is our kind of ability to kind of get, almost like a clean room that we host, where you can do compute. You don't have to worry about like trying to build an environment on your laptop or your computer in somebody else's kind of cloud environment. You can just kind of get it up and running quickly on GitHub, and do the builds and the development there. So, there's like this ability to kind of have a cleanroom setup, in some ways, which is nice.

Yeah, I was going to say, like you have given them virtual study halls or something like that.

Yeah. I'm personally really excited about this, as I was talking to a university professor, not too long ago. They had not heard yet that we were releasing a free tier for Code Spaces. I think it's 60 hours a month. So, they were really excited, because this is an opportunity to say like, you can get even like a classroom environment and say, “Hey, we want you to do this project. Here's the config file. You run it on Code Spaces. You know every single student has the exact same environment. There are no changes. When it's done, you can close it down, shut it off. And it's not a thing a university has to worry about securing over time, keeping up with.”

Yeah, that's a great tool. I hope listeners are looking into that. You said you're excited about? Is that sort of a new development?

Code Spaces is released, I think, a little bit about a year ago. But the kind of free tier of 60 hours, I think came along with our GA not too long ago.

Gotcha. Okay. So yeah, just a couple more questions for you here, and right now, we're going to kind of move into the sort of work portion of Cyber Work. So, for young people, or older people transitioning into cybersecurity, software security, or software development. Do you have any advice for areas of study or skills or experiences that you should be pursuing that will help you rise to the top of the resume pile in this area? In other words, what does a company looking to hire new talent want to see that you've done learned or documented?

Yeah. First of all, I would say, I'm a really firm believer that diversity is key to building a world class security program. I mean, I think that's true, really, of any team. But we're talking about security today. That's all types of diversity, right? It's cultural, it's race, it’s gender, but it's also a professional background. So, to folks who are hiring and listening to this out there in security, I would encourage people to take a broader view of folks that are looking to get in or maybe have a nontraditional professional background. Because I think, having people on the team who think differently, who've experienced different things, in different professions is really, really important.

There are cases where we need very specific set of background and experiences. If we're hiring a specific engineering manager for a very technical team, right? We're going to need somebody who's got experience in that space. But I think there's a lot of other roles in security that don't require that very tailored specific technical experience, but could benefit from our broader view. So, in terms of how to get started and what to focus on, I think, I usually tell folks, technical experience translates everywhere. Taking Azure classes that are free or GitHub does a bunch of free training as well. Linux programming, networking, like whatever is exciting to that person, taking some of the free classes, learning in that space, that technical foundation is going to translate really into any discipline, insecurity and be helpful.

Nice. That's great advice. So, as the task of juggling an almost infinite number of moving parts, many of which originate on GitHub, it feels like, at least, again, to my sort of way of seeing things, it feels like that development becomes an increasingly complex proposition. In cybersecurity, a lot of my guests have said that half of anything you learned today will be out of date in six months. So, with secure software development, it feels like that window might even be a little shorter, and worryingly, it could feel a little overwhelming to jump into this line of work, when it seems like there's so much existing knowledge and new knowledge to absorb quickly. It's like trying to merge onto a 70-mile per hour highway from a stop position. So, do you have any thoughts on breaking down the massive task of entering the software security space and getting up to the same high speed that other developers seem to live in and swim in?

Yeah, it's a really good question, and it can certainly on a daily basis, feel that way. I think if I take a step back, certainly, the specific tech changes at just an incredibly rapid pace. I mean, if anyone subscribes to new cloud services coming from one of the big cloud providers, it's almost impossible to keep up with all the changes that are happening there. But at a fundamental level, though, I don't think the fundamental tech approaches change all that regularly. There are some key shifts, right? The cloud adoption and the cloud services, and SaaS and paths and all those things over the last 15 years, I think, is a fairly fundamental shift that we've seen.

But those core principles, I think, once they're integrated into somebody's thinking and technical approach, really translate into any field. And so, chasing the latest JavaScript framework, or new cool tool can be fun. But I think the core principles of both software development and security really stay the same. So, I think, you know, the second thing I'll say, in that space, too, is I think open source is a bit of a normalizing opportunity here. Being able to participate in open source, see the code, other people are writing, contribute, right? It's fairly straightforward as a new developer, to go open a pull request on an open source repository, and just start to be part of that ecosystem and community. That may lead to helping fix some bugs, and that may lead to becoming a maintainer, and answering questions for other people that all of a sudden, that person is part of this broader technical ecosystem.

So, it's also probably the new form of resume as well of, send me your GitHub profile. We’ll browse through and see what open source you've been contributing to. It's definitely something I look at, when I'm looking at resumes as well, somebody has that listed, I'll go take a browse and see what their chart looks like and see what that they know.

Because I think people have said that for years about LinkedIn that people can “endorse you” for different things. But that doesn't really mean anything, because you can't really look into it. But yeah, something like this, where you can actually – that's a really good way to sort of expand the experience section of your resume. So, I hope you all are taking notes. That's a great idea.

So, I'm about to wrap up here. But one thing I learned from a previous guest about developers is, and I'm paraphrasing him, and you talked about this a little bit, but their convenience focus to a fault, because everything has to be done at high speeds all the time. And expediency is required, not just to meet deadlines, but to stay in the flow without being interrupted. Some developers will have access codes and passwords over their computer, desktop, or an easy to find places, which is easy for them, but it makes them kind of a variable pirate's treasure, if someone should reach the company and navigate to their workstation

You talked about this a little bit before. As we talk about software security and DevSecOps and so forth, can you speak about security tips for developers? Are there ways to speed up the authorization process? Sounds like some of that maybe even GitHub has developed but without leaving all of your credentials, basically sticky note into your forehead every time you're working?

Yeah. That's a good question. I think a couple parts to that. One is, we are focused on making security easy and automated within the flow, right? Sure, developers want a convenience focused flow and don't want to get out of the flow. When I used to write code all day long every day, you're in the flow and you get pulled out of it. It can take, I think it's 15 to 20 minutes to get back into it as a developer. We don't want our developers to break out of that flow, and we certainly don't want our customers in the 100 million developers that use our platform to be there as well. You start to think about the minutes wasted or breaking that flow, it gets a little overwhelming.

So, I think the key is from the beginning, trying to think about some of these security principles as a developer, and I think, that's probably one of the shifts that I think we're seeing over the last few years is software development, security are almost the same thing now. Doing software development in a vacuum and not thinking about security is becoming less and less of, I think, an expectation for companies, and I think, for developers, as well. So, kind of approaching technical challenges with that in mind. Okay, cool, I'm going to go build this software platform, where do I put my secrets? How do I think about IM, and building those in as part of that core design, I think we're just going to see more and more of that.

I also think, it depends on are we talking about developers who are building kind of core infrastructure or more like user facing apps, and there's kind of different models to think about it. We were kind of talking about earlier things so complex, some of these infrastructure apps are really, really complex. And you can't just go sit down and build because it may use like 10 core cloud services, and IM provider, network, connections, storage, all these things. So, I think that's where having a core team with these experiences and being able to think about what is security from the outset is so important, and kind of bake it in from the beginning.

That's great to hear. Yeah, I think that's some excellent advice there. So, we’re about to finish here. But as we wrap up today, we've already talked quite a bit about GitHub. But if there's anything you want to discuss further regarding upcoming changes, or innovations, or rollouts that you're excited about, feel free to do so here.

Oh, yeah. One thing I'll mention that we're starting to see some really interesting and fun traction on is we just released something Called Private Vulnerability Reporting. So, this allows open source maintainers, of which there are many, many on GitHub, to be able to accept private vulnerability reports from researchers or developers or whoever. So, they're using open source tool. They find something they think might be a security issue, and instead of trying to figure out a way to contact the maintainer, or sometimes post it publicly, which is not always the best responsible disclosure method, we now have a way for them to report that privately, and it can be triaged by the maintainer. And then it's kind of built into our whole dependency security tools as well, if it kind of moves forward from there. So, I think, I'm excited to continue to watch that space. I think it's just the beginning of seeing the benefits of that for the security community.

Very cool. All right, one last question, for all the marbles, IF our listeners want to learn more about Jacob DePriest or GitHub, where should they go online?

I'm @JacobDePriest on LinkedIn and GitHub and most of the social media, so feel free to find me on any of those.

Okay, and would you mind if our listeners drop you a line?

Not at all. Would love to hear from them.

Great. All right, well, Jacob, thank you for joining me today and for helping our listeners navigate the ocean of info over GitHub. This definitely helped me and I'm sure it helped them as well.

Thanks, Chris. It was a pleasure.

As always, I'd like to thank you all for listening to and watching the Cyber Work podcast on an unprecedented scale. The needle just keeps going up and we're really delighted to have you all along for the ride. So, keep subscribing, keep hitting the notification buttons, tell your friends, tell your teachers, whatever you want to do. But thank you for what you're doing right now.

So, I'm going to remind you, go to infosecinstitute.com/free to get your free cybersecurity talent development eBook. It's got in depth training plans for the 12 most common roles, including SOC analyst, penetration tester, cloud security engineer, information risk analyst, privacy manager, secure coder and more. We took notes from employers and a team of subject matter experts to build training plans that align with the most in demand skills. You can use these plans as is or customize them to create a unique training plan that aligns with all of your unique career goals.

So, one more time, go to infosecinstitute.com/free or click the link in the description below to get your free training plans, plus many more free resources that’s being updated all the time.

Thank you, once again, to Jacob DePriest. And thank you so much to all of you for watching and listening. As always, we will speak to you next week. Take care now.