This week at GitHub InFocus: Code security and DevSecOps

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.

We’re talking about a few different concepts during Security Week. So let’s define some base terms here. What are application security, DevSecOps, and code security, and why are they important for organizations?

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:

• Application security leverages a system of tools, processes, and best practices to manage application-related business risk.
• DevSecOps makes everyone who’s part of the development lifecycle responsible for an application’s security—like how in DevOps, everyone is accountable for operations and supportability.
• Code security is protecting the code that goes into your application, whether it’s open source or custom code developed by your team.

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.

Like DevOps, automation plays a big role in making DevSecOps successful. What are some quick examples of automated security tools or best practices that folks can expect to learn this week?

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.

Nigel defined some terms for us above, but another area we’ll be covering is ‘supply chain security.’ This is different from securing your own code. Can you tell us more and why?

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.

Security is complicated and can feel a little intimidating. For teams that are new to application security, how can they learn more before they attend?

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.

We’ve learned a lot about security through working with other organizations. What are some of the common application security pitfalls we’ll be sharing how to watch out for this week?

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.

From developer experience to DevOps, the last two weeks of InFocus has shown us why thinking ‘developer-first’ can help your team and your organization. How does this apply to 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.

Question for all hosts: If folks could only take away one thing from Security Week, what should it be?

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.

Want to learn more? Tune in to Security Week at InFocus starting on March 9 at 11am PT / 2pm ET or check out the full list of sessions.