Interested in bringing GitHub Enterprise to your organization?
Start your free trial for 30 days and increase your team’s collaboration. $21 per user/month after trial expires.
Curious about other plans?
Two weeks ago, we kicked off GitHub InFocus, a global virtual series just for software teams. Last week, we learned what powers a successful DevOps program. Next up: Security. We…
Two weeks ago, we kicked off GitHub InFocus, a global virtual series just for software teams. Last week, we learned what powers a successful DevOps program. Next up: Security. We checked in with hosts Nigel, Pierluigi, and Shawn for a quick Q&A on what to expect, from using open source securely to achieving DevSecOps.
Nigel: All three are critical for delivering secure applications that don’t put your customers or your team at risk. Here are some quick definitions:
Why do they matter? We discussed during DevOps Week why every company is now a technology company. Digital applications drive customer experiences. Yet these applications are also a prime target for malicious actors. Many of the biggest recent security breaches are known to have leveraged vulnerabilities at the application layer. This week, we’ll be diving more into why that is, and how organizations can address these vulnerabilities before they get to production.
Nigel: Traditionally, security has been siloed and slow. It’s been treated like a final gate at deployment time, when in reality, application security problems are easiest and most cost-effective to solve at the source, starting with the first line of code. Doing this requires prioritizing tools or processes that can provide immediate feedback to developers as early as possible. Plugging raw security scan results into issue trackers, and just assuming that developers will fix them all doesn’t work. Instead, approaches like secret scanning and code scanning automatically check your code as it’s created. Open source tools like OWASP ZAP can also help automate testing for applications running in production. We’ll be demoing these tools and talking in-depth with security experts from Xpirit, Mnemonic, and others on how to build automation into your DevSecOps process.
Pierluigi: Modern software is built on open source, with up to 99% of codebases containing open source components. For organizations, that means the question isn’t about how much open source code is being used. It’s about what open source code you’re using. Also, if you aren’t aware of what is in your software supply chain, an upstream vulnerability in any of your dependencies can affect your applications, making them susceptible to potential security exposure.
Understanding these dependencies and the risks associated with them, conducting regular checks to remove unnecessary dependencies, and monitoring the entire software development supply chain are key steps developers need to take as they build secure code. It’s estimated that 85% of vulnerabilities in open source are disclosed with a patch already available. Yet being proactive and successful at addressing software supply chain threats goes beyond patching. With the shift to digital transformation heavily relying on software and the code underpinning it, it’s clear that security must be approached as a collaborative effort and one that puts developers first. At InFocus, we’ll be exploring why this means shifting security reviews and testing left, and enabling security controls earlier on in the development process so that vulnerabilities are fixed before entering the production cycle.
Pierluigi: Continuous security should run parallel to CI/CD, and security should be built into every step of the development process. This can feel like a big ask. For teams just getting started, know that since this is a mindset shift, there’s no canonical list of practices. Rather, the biggest change is to apply security practices earlier in the development lifecycle.
Start by partnering your security teams with developers in their preferred environment and leveraging their existing workflows. Putting developers front and center for application security is the most effective way to shift security left and succeed against the mounting technical debt that can overwhelm even the best teams. To get a better idea of what this looks like, check out our DevSecOps maturity ebook and some examples from other teams, like Thermo Fisher’s talk on how to treat security as a feature from GitHub Universe.
Shawn: The number one pitfall I come across time and time again is security as an afterthought. Every company I’ve worked with, I’ve seen that developers are heavily outnumbered by their security peers. Having developers create code and involving security at later stages in the development cycle is a losing battle because of the high speed and volume of releases. This approach doesn’t scale to cover all applications and keeps vulnerabilities from being discovered until it’s too late—resulting in vulnerable code being pushed to production. Grey Baker, senior product director for security, will be talking to us about how to solve this tomorrow during the Enterprise Showcase: Flipping the script on application security.
Shawn: This applies in the same way to security. The stats are clear—no organization has the number of security folks needed to keep up with the amount of security issues they deal with. It’s why we believe that application security is a joint responsibility between developers and security teams. As the home for developers and open source, GitHub strives to provide a natively integrated and automated security platform for developers. On Wednesday, we’ll be hearing what this looks like in practice at Eli Lilly. We’ve also got a great resource on this if you want to learn more: The complete guide to developer-first application security.
Nigel: If you’re already doing DevOps you’ve already done most of the work—DevSecOps is the natural next step. “Shifting left” doesn’t have to feel tough or intimidating. It applies the same best practices you’re already using with your developers and operations teams, now with your security teams integrated from the beginning.
Pierluigi: Like Nigel said, security is a team effort, not a final step. Following DevSecOps means approaching security as an ongoing part of software development, staying up-to-date with what dependencies are being used, being aware of vulnerabilities in those dependencies, patching them, and then getting back to work. For developers, that means having a few capabilities: the ability to know what’s in your environment, to manage your dependencies, and to monitor your supply chain.
Shawn: Put developers at the heart of what you’re trying to do. At the end of the day, they’re the people who will be hands-on fixing the vulnerabilities returned by whatever tool you may be using.