Introduction
Did you know almost every piece of software depends on OpenSource? Not sure… What libraries is your software using? Bingo! 😉
Now we all know that package management can be a true hell. Tracking everything and ensure you are up-to-date to achieve the needed security level is hard. Next to that, there is always the risk that your build will break to moving to a library version.
What if we could enhance that flow a bit? You guessed it… Today’s post will be around how we can leverage native GitHub features to help us in this area!
Let’s hit the slopes!
For this walk-through, we’ll use the following ;
- an existing code repository, where we’ve forked CoreUI’s VueJS repo
- GitHub’s actions to run a workflow on every pull request
- GitHub’s automated security feature that will send pull requests to us when it detects security issues
Want to test this one out or follow along? Browse to the following sample repository ; https://github.com/beluxappdev/CoreUI-VueJS-GitHubSecurityDemo
So let’s fork this sample repository!
Once forked, it’ll take a few seconds to fork the repo.
Before we head out to configuring the security settings. Head over to the Actions pane, and allow the actions to run…
You’ll notice that there is one workflow called “npm pull request testing” ;
Let’s take a look at the contents of this one (under .gitflow/workflows) ;
Now let’s head over to settings and look for “Security Alerts” ;
Let’s enable this one!
Once done, head over to the “Security”-pane, and click on “Off, Automated security fixes”, and enable the “Automatic security fixes” ;
Once done, head over to the “Insights”-pane…
And in “Dependency graph”, let’s enable the dependency graph ;
It’ll throw you off that there is no manifest file found at first.
Just refresh the page and you’ll notice the security issues of your repo. If it has any of course! 😉
What does the “Security”-pane say now? Cool, it shows the various libraries that are out-of-date…
And what about our pull requests?
Still empty… Dang! Just kidding. Don’t worry. It takes a minute or two to kick in… Let’s take a look at our security warnings again.
It seems that the “set-value” is out-of-date. Let’s check our package lock if it’s true… And indeed, we allow a lower value.
Let’s go back to the pull requests. And we see that three pull requests have arrived.
And what does the “Actions”-pane say? We’ll see a workflow triggered for each of those pull requests.
So for each pull request, we’re doing an actual build of the software to test it out.
Sidenote ; You really want to do unit & end-to-end testing here! I’ve commented out those npm steps in the workflow as they gave issues for me. Though it is -really- advised to have this part of your pull request (and push) validation!
That being said, our build works!
Actually, all of the builds succeed!
Now this gives us with a good feeling to merge the pull request.
If you take a look at the pull request, you’ll also notice that “dependabot” (the one that creates the pull requests on behalf of GitHub) will also show the compatibility source for the change ;
Closing Thoughts
The integration between the automatic security fixes and actions (pull request validation) is awesome! It is an easy “hack” that provides so much value in terms of security & build quality. I don’t know for sure about you… Though I am in favor of anything that basically automates cumbersome tasks for me. 😉
Karim Vaes 