Everything You Need to Know About GitHub Security Alerts

DZone 's Guide to

Everything You Need to Know About GitHub Security Alerts

Here are 10 important facts to keep in mind when thinking about GitHub security.

· Open Source Zone ·
Free Resource

GitHub Security

I really love everything about security, and I'm especially intrigued by the GitHub security tab that is now available on your repository. However, in your projects, it is usually disabled by default.

You may also like: Staying Safe on GitHub

Let's take a closer look at everything you need to know about GitHub security alerts.

Introducing the GitHub Security Tab

Figure 1: GitHub Security tab on your repository

If you enable GitHub security alerts, you can start receiving suggestions based on code that you check on in the repository. As an example, GitHub will scan your npm packages source to find dependencies with libraries that are insecure.

Security Alert Warning Banner

Figure 2: Security alert warning banner

Figure 3: Summary of security issues for the repository
Figure 4: Detailed report of  the security issue
Figure 5: Pull request with the fix for the security issue

When GitHub finds something that requires your attention, it will put a nice warning header on your project, so the alert cannot really pass unnoticed.

If you go to the Security tab, you will find a detailed list of the analysis, so you can put a remediation plan in motion, or you can simply dismiss it if you believe that you can live with them.

Since I'm a big fan of the command line, I prefer to close that pull request manually. I simply issue a fetch, identify the new branch (it has annoying long name), and simply check it out as a hotfix branch.

Clearly, you can click on any issue to have a detailed description of the vulnerability, so you can decide if you are going to fix it or simply dismiss it because that issue is not relevant to you or you cannot, in any way, bypass the problem.

If you noticed in Figure 4, you have also a nice button "Create Automated Security Fix" in the upper right part of the page, this means that not only GitHub is telling me where the vulnerability is, it sometimes can fix the code for me. Pressing the button will simply create a new pull request to fix that error, how nice.

In this specific situation, it is simply a vulnerable package that is downloaded by the npm install. The change is simply bumping a library to a version that removed this vulnerability.

In fact, GitHub performs a security scan on project dependencies and can present a remediation with simple pull requests.

Figure 6: Pull request manually merged.

Figure 7: You can ask to receive an automated pull request for all vulnerabilities

Figure 8: A series of pull requests made to resolve security risks

Using pull request is really nice, and is really in the spirit of GitHub. The overall experience is really useful, the only annoying part is that the analysis seems to be done on the master branch and the proposed solution creates pull requests for the master branch.

While this is perfectly fine, the only problem I have is that when closing the pull request from the UI, it will merge this commit on the master branch, effectively bypassing GitFlow flow.

$ git checkout -b hotfix/0.3.1 remotes/origin/dependabot/npm_and_yarn/CoreBasicSample/src/MyWonderfulApp.Service/UI/tar-2.2.2
Switched to a new branch 'hotfix/0.3.1'
Branch 'hotfix/0.3.1' set up to track remote branch 'dependabot/npm_and_yarn/CoreBasicSample/src/MyWonderfulApp.Service/UI/tar-2.2.2' from 'origin'.

Figure 9: All pull requests were automatically closed after the push.

GitHub is really good in understanding that I've cherry-picked all commits in yellow from pull requests because all pull requests were automatically closed after the push.

Figure 10: Closed pull requests

My pull requests are correctly closed even if I cherry-picked all commits manually. Three of the pull requests were closed using simple cherry-pick.

With these commands, I simply check out the remote branch as hotfix/0.3.1, allowing us to issue a git flow hotfix finish and push everything back to the repository.

If you have a specific flow for hotfixes, like GitFlow, it is quite easy closing pull requests locally. Following your process, GitHub will automatically detect that the PR is closed after the push.

Now, branch is correctly merged.

If you really like this process, you can simply ask GitHub to automatically create pull requests without your intervention. As soon as a security fix is present, a PR will be created.

Et voilà, it is raining pull requests!

This raises another little issue; we have a single PR for each vulnerability, so if I want to apply all of them in a unique big hotfix, I only need to manually start the hotfix and then fetch all those branches from the repo and cherry-pick all the commits.

This operation is easy because each pull request contains a single commit that fixes a single vulnerability issue. The sequence of command is as follows:

git flow hotifx start 0.3.2
git cherry-pick commit1
git cherry-pick commit2
git cherry-pick commit3
git flow hotfix finish

The final result is a hotfix resulted from cherry-picking of three distinct PR.

This functionality is quite nice. In this simple repository, I have established a few lines of code that helped me reveal some npm dependencies with vulnerabilities, and most importantly, it gave me the solution so that I could immediately put remediation in place.


Further Reading

Staying Safe on GitHub

How to Check Open Source Code for Vulnerabilities

alerts ,github ,open source ,security

Published at DZone with permission of Ricci Gian Maria , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}