I haven’t been using GitHub very long, in fact, its been less than a year. The greatest challenge was understanding how all the moving parts connect and how they should fit into my work flow. My first experience with GitHub was through Learn.co and I was shielded from a lot of the inner workings of Git by a web software layer that made it easy to use the functionality of GitHub without actually understanding how it worked.
Prior to starting my software development journey I hadn’t heard about Version Control Systems (VCS). For those of you, who, like me, learn through hands-on practice, there can be a very long journey from basic usage to true understanding. Starting from my first month at the Flatiron School we continually delved deeper into Git, especially after we started group projects. Oftentimes, we needed to work separately on the same project and Git helped coordinate this work.
And, for those of you still wrestling to understand VCS, of which Git is one (there’s also CVS, SVN, Mercurial, Bazaar, Monotone and many others), there is a well written document by Micheal Ernst, a professor of Computer Science & Engineering, at the University of Washington’s Paul G. Allen school of computer science & engineering. There’s also a good <6 minute video by Joel Shapiro of Altassian named What is Version Control? which gives a good overview in a viewer-friendly format.
Now that I’ve worked with Git for several months, I’ve gotten used to the features and command structure. I’ve also become better acquainted with GitHub’s features, as well as their great tutorials at the GitHub Learning Lab. These interactive tutorials cover basic, as well as much more advanced topics. And, all of them are free. It’s almost like getting free money, and who doesn’t like that? 😉
What’s a GitHub Security Alert?
That’s what I hope to answer during our time together today. My curiosity about GitHub Security Alerts started when I recently received this email from GitHub.com:
Subject: A new security advisory on activesupport affects 5 of your repositories.
Can’t I just ignore it? 🙈
Now, I’ve received similar notices in the past, which notified me when a repository’s dependencies were outdated because of some security reason. For the most part, I ignored them because they were attached to defunct projects. This time the dependencies were related to Rails features in some of my active projects, so I decided to take the dive and figure this out.
Now, please let me preface my exploratory blog post by saying that after looking over the various vulnerabilities, I can’t make heads or tails out of some of them. I tried decrypting what they do, soon became befuddled, and decided not to dwell too long on topics that are beyond the scope of my (current) understanding.
For now, I’ll look to the Programming Giants, upon whose shoulders my newbie developer projects sit. I’ll open wide my eyes and ears. Then, simply and naively choose to believe that when an issue is labeled "high severity", that I should do my best to implement the fix.
Let’s Dive In
When I clicked the view alert link in the email, my browser opened up GitHub, specifically to the Security tab (blue arrow below) of my affected repository. From here, I can see the severity of the security alert along the right hand side of each entry.
Also, there’s a drop down on the right side (red box below) where I can dismiss the warnings for various reasons, or adjust my notification settings. On the bottom of the page there is a link to “Learn more about security alerts”, which I highly recommend skimming through to help understand how GitHub implements these alerts. For example, through that help article I learned that on public repositories, monitoring is turned on by default, but for private repositories (of which, I have quite a few), this feature needs to be switched on.
Welp, looks like we have a grand ole total of 9 Security Alerts.
We also got 3 pull requests (orange arrow above), which weren’t there before. Let’s open the Pull requests tab so we can see the requests and interact with them. Now, just for the record, I didn’t create any of these PRs.
Side note: They are auto generated by GitHub Dependabot. (Fahmida Rashid wrote about GitHub’s acquisition of Dependabot in May of 2019, and more details are available from GitHub’s official announcement by Justin Hutchings.
Let’s take a look at those requests, specifically the earliest one (March 15) on the bottom (green arrow). When we click into that link, we get the following screen:
A couple of things to note here. Obviously, the thing that stands out most is the “Merge pull request” button. And I know in the past, I’ve just pressed this button, accepted the changes and deleted the branch. And for the most part, this is how may of these kind of updates can be handled.
Above that, in the area where @dependabot is “commenting” on the PR, I drew a green arrow pointing to the compatibility rating. This rating is a good gauge as to whether or not the pull request will make “breaking changes” to your project (This PR has a 96% compatibility).
Also, note the “compare view” (yellow arrow), which will open up a new page that has all the individual changes that are being made in the code, broken down by filename. This is exactly the same functionality you get when you compare two different commits with each other. Changes being shown in green and red.
Beside the blue arrow you can see a triangle and collapsible menu item named “Dependabot commands and options” which will open up a drop down box. This drop down box lists a variety commands you can send @dependabot. These can be sent in the comments section of the pull request, much like your would message somebody on Slack, and it allows you to command @dependabot to do stuff for you automatically.
Since everything looks okay with this PR I’ll just go ahead and merge it, along with the other two PRs that were auto-generated for me by Dependabot (all 95+% compatibility ratings). Now that was …
Diving Even Deeper
Now that the easy fixes are done, let’s take a look at the Security Alerts that GitHub did NOT auto-create fixes for. There’s are 7 of these left. And, it looks like even though we already had 2 pull requests for acorn, it’s still not completely vulnerability-free. acorn still has 1 security alert of “moderate severity” on it. We open it and see:
For those of you who noticed the big, green “Create automated security update”, I already tried it! 😒 It doesn’t work. Obviously, we can’t correct this from within GitHub.
Next, we see the “Remediation” or solution, which is to upgrade acorn to version 7.1.1. When I inspected other security alert detail pages, some had code blocks that we could use or a description of the kind of logic we would need to implement to patch the issue.
If we look above this line we see the location of the vulnerability, its in the yarn.lock file. This is not a file that we can edit ourselves, but is generated by yarn. And, what this is telling us is that one (or more) of our packages or gems needs to be updated.
Lastly, we see a detailed description of the vulnerability in the Details section at the bottom . This is a pretty clear cut vulnerability. An attacker sends a certain “evil” string and it causes an endless loop. By clicking the ID (e.g. GHSA-6chw-6frg-f759) we can see more information, including a list of links the organizations that reported the issue, document the issue or who are responsible to fix the issues.
Stand back! And, let me do my magic!
Looks like the first thing to do is try and update the packages (or gems) in my repository. This is something I haven’t done often, for fear of making breaking changes, but there comes a time to try new things, and if you fail, you’ll learn.
So, I open up my local machine’s terminal app and execute:
$ yarn upgradeNote: If you use npm then the vulnerability might show up in your package-lock.json . And, you can use npm upgrade instead of yarn upgrade.
So, after running that command, I see, that in addition to upgrading my packages, yarn is telling me my yarn is out of date. Now, I never knew how self-aware yarn was, but I’m very happy for it 👏. So, I went ahead and put in my 2¢ to upgrade yarn to it’s 🧘♂️next level of consciousness 🧘♀️with :
$ brew upgrade yarnAfter doing this, I run my git commands to update my GitHub repository, so that GitHub has an updated yarn.lock to evaluate:
$ git add .
$ git commit -m 'run Yarn upgrade'
$ git pushAnd when I return to my repository’s security alerts tab I see that 2 of the alerts are gone, including the acorn one that I was working on. So, now there are only Five left!
Taking a closer look at my list of security alerts, I notice that this repository has separate directories for my front-end and back-end. The acorn alert was in my front-end and all the remaining alerts are in my back-end, so I’ll cd to my back-end directory and do another:
$ yarn upgradeAnother git add and git commit and git push so that my Gemfile.lock can be updated in my GitHub repository. Now, I refresh my GitHub security alerts page and ….
It knocked out 1 alert.
Well, we’ve got 4 security alerts left. Looking into each alert’s details, there is more information about the vulnerabilities, as well as links to EVEN MORE information at nist.gov, discussion groups that work on the bugs, as well as possible workarounds (code and/or logic) until a fix can be implemented and updated through npm or yarn.
Three of the alerts became active just 4 days ago. What this says to me is that fixes are in the works. By whom, you ask? By the Programming Giants, that I mentioned earlier. Give them a few more days or weeks and everything will be patched and the world will be right. (I hope.)
At this point, I’ve gone just about as far as I can. And, after reading through the vulnerabilities I’ve come to realize that they do not actually affect my app because I don’t use the functionality of these vulnerable dependencies.
However, if they did, I would have a plethora of resources to continue my search for a solution. Plunging into the deep end of the pool through the links to working groups, discussion forums and email lists will lead to all kinds of useful resources and contacts. The chances are not bad for a solution-seeking developer to get in touch with the actual developers who are working on and, in essence, creating these software that developers like me can sometimes take for granted. Just be ready to describe your issue thoroughly, do your homework before asking a question that’s been asked a dozen times before and be patient, these are busy people, generally.
[update: While proofreading and editing my final draft, I realized I used yarn upgrade in my backend. This updates javascript packages in what is a Ruby on Rails backend, but not Ruby Gems 🙄. For those of you who caught this while reading, kudos to you 🙌! I went back and did a bundle update and was ecstatic when I saw tons of lime green lines showing up as bundle downloaded new versions of actionview, actionpack, activerecord, activestorage and many others. A quick git add ; git commit -m 'update' ; git push and I checked my repo and ….no more security alerts!]
If you’re one of these “programming giant” developers and through some happenchance come to this blog post. I sincerely thank you for your hard work, dedication and time to solve problems too difficult for me, so that I can build upon your work!
Thanks for reading! And, if you enjoyed the story, please throw me some applause or a follow. It definitely is encouraging to me to continue writing and sharing my journey!
For those of you interested in some basics of Git, I’ve previously written some articles on the subject and you can find them here:
Take care and be well!
