‘Focus on brilliance at the basics’ – GitHub CSO Mike Hanley on shifting left and securing the software supply chain

INTERVIEW Software developers are still burdened with using needlessly complex security tools that can lead to workarounds, mistakes, or vulnerabilities in code, laments Mike Hanley, GitHub’s chief security officer (CSO).

At the helm since February, GitHub’s first-ever CSO has previously occupied senior roles at Duo Security, Cisco, and the CERT Coordination Center.

In a Q&A with The Daily Swig, Hanley contends that “mastering the basics” of security is as important as it is often neglected, and is enthusiastic about the potential of GitHub’s newest tools to facilitate ‘shifting left’ and bolstering software supply chains.

How’s the new role going so far, Mike?

Mike Hanley: It’s been an incredible first eight months at GitHub, and I’m really enjoying the scale of the platform and team.

I spend a lot of time talking to customers, stakeholders in various teams, and people within my organization to help us craft a clear strategy and vision for security at GitHub, and then focus on creating great security outcomes for those groups.

What structural changes to GitHub’s security operation, if any, have you overseen so far?

MH: We approach security in the broadest sense, in that we include the traditional security functions like security operations and product security engineering, but also have anti-abuse and the GitHub Security Lab as part of our team.

We brought all these teams together and elevated the function inside GitHub because we know that security and trust are core to everything we do, and we want to make sure all the teams are working together with a shared understanding of our expectations and goals from a security perspective.

I’m fortunate to have come into this role where there was already an amazing team onboard, so we’re really focused on forward-looking investments and opportunities as we write this next chapter. We’ve already doubled the size of the team in just eight months and have several dozen more roles open across our entire team.

Which skills and experiences acquired in your previous positions are proving most transferable to your role at GitHub and why?

MH: My first real job was tech support for a large IT services company. Starting out in a technical support role was extremely valuable in terms of learning about how things break, what that means for the experience of people trying to get their jobs done, and really helping me develop a ‘customer-first’ mindset to everything that I’ve done since.

Combined with my experience at Duo Security, where I had the opportunity to build the security organization from scratch and focus on security products that are easy for people to use, these experiences really influence my approach to security at GitHub.

GitHub has made a number of tools available to the open source community

In a blog post you penned upon joining GitHub, you said that “good security and the speed of the business are not opposing concepts when met with thoughtful design and a customer-centric approach”. Can you elaborate on this point?

MH: For a few decades now, the industry has been making security tools that are hard for people to use. In 1999, Alma Whitten wrote a paper called ‘Why Johnny Can’t Encrypt’ (PDF), covering why it was hard for people who were not security experts to use PGP 5.0.

You could write the same paper today demonstrating why many security tools on the market in 2021 are just as hard to use.

Developers aren’t necessarily security experts, even though the safety of their software – dispersed throughout applications and services we use every day – has major repercussions across industries and geographies. But burdening developers with a complex set of tools that require a high degree of security friction or prior knowledge can slow their progress and lead to workarounds, mistakes, or vulnerabilities in code.

Good security should be baked directly into the development process and built with the experience of the developer in mind, not tacked on at the end. Platforms should focus on intentional design that balances usable account security with efficiency and speed as well as the ways developers want to work.

This isn’t lowering the bar for security – it’s raising the bar for our expectations of the experience of security for the developer.

You also said your priorities include “helping developers shift left” in line with your “developer-first security” ethos. How is GitHub helping facilitate this goal?

MH: I’ll give two quick examples. First, GitHub Codespaces recently launched and we’ve moved nearly all of our internal development to this new platform.

From a developer experience standpoint, it’s incredible to be able to have an ultra-fast development environment in the cloud within seconds, ready to go.

From a security perspective, it’s actually equally remarkable when you think about the fact that you’re no longer worried about potentially tens of thousands of unique physical endpoints, in various states of security hygiene, all with different and heavily customized local environments, and each as a vector for potential attack on a local checkout.

This has traditionally been a really challenging set of problems related to endpoint security and the impact of that on locally-developed code, but Codespaces means you’re actually abstracting away a non-trivial part of that traditional, local attack surface.

We also have GitHub Advanced Security, our suite of security products and features that integrate directly into the developer workflow, helping to shift security left.

I’m personally very excited about CodeQL, the underlying code analysis engine behind GitHub code scanning, and the work we’re doing there to make it easier for people to discover and prevent vulnerable code from ever shipping.

GitHub HQ in San Francisco, California

How can the open source community address the growing problem of software supply chain attacks?

MH: We’ve made a number of tools available for free to the open source community that can help improve the state of security in their organization and projects. There are hundreds of millions of open source projects on GitHub, and we feel that we have a responsibility to encourage and enable good security hygiene among builders by shipping security-first products.

The company takes that responsibility seriously and is setting an industry standard, formulating tools like Dependabot and Dependency Review with the right amount of ease and friction to make it simple for software developers to do the same in their own projects.

Increased collaboration is crucial as well, and is why we’re also partnering with other industry leaders to support the Open Source Security Foundation, with our latest participation in a $10 million funding announcement.

There’s an axiom that nothing is ever 100% secure, while security threats are myriad and hard to anticipate/predict. How do you triage your resources to prioritize actions that bolster your security posture and help developers secure their codebase?

MH: I like to think about this in the context of Forrester’s Targeted-Attack Hierarchy of Needs pyramid. Many organizations start at the top, where there’s a lot of interesting action and excitement, but they do that before they have the base of the pyramid – a clear strategy, a focus on developing and retaining talent, and focusing on brilliance at the basics and fundamentals of security.

If you excel at these foundational layers of the pyramid, not only do the higher order activities become more effective and valuable, but you’re also likely dramatically increasing the attack cost for adversaries across the board by mastering the basics, which so often are neglected, leaving the proverbial front door open for whomever wants to walk in.

Source: https://portswigger.net/daily-swig/focus-on-brilliance-at-the-basics-github-cso-mike-hanley-on-shifting-left-and-securing-the-software-supply-chain