GitHub to follow “shift left” strategy and integrate security at development stage


    Every Software project comprises millions of lines of codes and on a single project, multiple coders work to make the project a success. Even though there have been a lot of efforts to make code secure over the past decades, the number of vulnerabilities is going up linearly with the number of lines of code that people are writing and it becomes extremely difficult to keep the code free from vulnerabilities without integrating security within the development workflow. Open-source platform Github is trying to fix that by pushing for a shift left approach in security.

    The major problem with security is that the complexity of it is linear with the scope of the software ecosystem, more API, more frameworks. The bigger space gets, the harder it is. The striking issue is that security challenges will keep on rising, given how security teams are created separately from the development teams.

    “One of the things that GitHub is kind of good at is building experiences around the development workflow. And we’re trying to make it so that security’s a built-in part of that workflow, instead of being something that happens after. Security scanning of your code that’s being written while you’re writing the code, as opposed to weeks later by a different team within just files, tickets. So basically, focusing on making security part of the workflow is one of those core fundamentals,” Jamie Cool, Vice President of Product Management, Security at GitHub, told ETCIO.

    Vulnerabilities are often identified, some are identified early while some late in the process. The challenge is that once they have been identified – how can it be plugged into a workflow that it’s going to get fixed and get propagated out to maybe the millions of applications that are consuming that vulnerability. The solution to this is to make sure the security tools can be integrated into the development lifecycle. GitHub recently made its code scanning solution available for all that is made up of two things – One of them is GitHub’s CodeQL tool, and the other is a remediation workflow that works with other services too.

    “We put an integrated experience. We’ve shipped our code scanning tool, we’ve also made that experience extensible so that if you have another tool, like Lint, or Brakeman, or a third party commercial tool, and if you want to be able to run that as part of your CI process, and then send that data back in an integrated way to the developer portal. It gets that same kind of shift left experience,” Cool said.

    Building a bug bounty program has shown to be effective for most of the large internet companies including Google and Facebook in somewhat bridging this skills gap and deploying the same for fixing security issues in open source code could also prove to be quite effective. GitHub also started their Bug Bounty program last year to encourage people to discover bugs and report them.

    “Bug bounties, in general, are just one of the tools that the industry has created to help encourage and facilitate adoption. It can be a mechanism that we’re using to generate community energy around the initiative and generate awareness. One of the other ways to look at bug bounties is that instead of directly paying your testers, now you’re paying experts – getting a focused expert push from the community on that. It is a different way of spending money from that standpoint,” Cool said.

    Recent Articles

    Related Stories