Thomas.G for NodeSecure

Posted on Feb 19, 2023

Securizing your GitHub org

#opensource #github #security #tutorial

Hello 👋

I started open source a bit naively (like everyone I guess 😊).

But the more I progress and the more important/popular some of my projects become 😎. That's great, but at some point you have to deal with a lot of things related to security (like Vulnerability disclosure).

You start to hear and see a lot of scary stories around you 😱. Not to mention all the acronyms where you don't understand anything at first 😵 (VMT, CVE, SAST, SCA, CNA ...).

As I was working on an open source security project, I put pressure on myself to be ready. Also as a member of the Node.js Security WG I thought it was an interesting topic and that I was probably not the only one who was worried about not being up to the task 😖.

So I rolled up my sleeves and tackled the problem 💪. Here is my feedback/journey on how I improved the security of my NodeSecure GitHub organization.

👀 We use Node.js and JavaScript (but most recommendations are valid for other ecosystems).

Security Policy and Vulnerability Disclosure

Adding a root SECURITY.md file explaining how developers and security researchers should report vulnerability is important. You don't want a security threat to be turned into a public issue (This gives you time to analyze and possibly fix before disclosure).

⚠️ If you are a developer, never report a security threat using a public GitHub issue. This is a serious mistake. This could even put your business/team at risk.

I don't want to bullshit you, so let me share with you the OpenSSF guide that helped me set up my first reporting strategy: Guide to implementing a coordinated vulnerability disclosure process for open source projects.

I started from scratch by reading this guide and taking inspiration from their templates 🐤. As a small open source team we don't especially have DNS or mail servers (not even a defined Vulnerability Management Team A.K.A VMT).

I was a bit puzzled to put my personal email as I'm not alone 😟.

I quickly learned that Github added a new feature to report/create private security issue 😍. You can enable it in the Security tab (I think it's also now possible to enable it on every repositories at once).

And this is what it finally looks like:

Use OpenSSF scorecard

The OSSF scorecard initiative is really good to assess your project against security best practices. I am not the first to write about this.

You can easily setup the GitHub action workflow by following those instructions.

Once configured, you will have a set of alerts available in the Security tab.

This will give you an overview of the different subjects to improve (workflows, dependencies etc). Each of these alerts contains a full description of the actions to be taken to fix the problem.

I have personally used these recommendations to dig and train myself. The next chapters will help you improve your score.

📢 By the way NodeSecure CLI has a first-class support of the scorecard.

🔓 Enable branch protection

I am a bad student 😳. Almost all of my projects had no branch protection on the main / master branch 🙈.

To set up the protection, go to Settings > Branches and edit your main branch.

GitHub has quite a few options on the subject 😵. If you don't know what to choose in terms of options, don't check anything (it's ok to begin ✔️).

If you want to be more restrictive, be careful because it could block you (some options are only viable in projects with many contributors/reviewers).

As far as I am concerned I often choose:

Require a pull request before merging
Require conversation resolution before merging
Require status checks to pass before merging

🐲 Workflows Hardening

I fell down when I saw all that it was necessary to know to secure workflows with GitHub actions 😲.

You must pay attention to the permissions granted to your jobs / GITHUB_TOKEN
Ensure your GitHub Actions are pinned to a SHA
Hardening the runner (see the StepSecurity HardenRunner)
Probably a lot of other stuff I haven't had time to see yet 😆

Fortunately there is a great free online tool that help you by doing all the hard work (it will open a pull-request and automatically fix issues).

The tool was created by StepSecurity. I had the opportunity to talk with the CEO and they listen to the maintainers which is really cool.
Thanks to them ❤️!

Configure Dependabot

It is recommended to use Dependabot for updating your dependencies and GitHub actions (yes, it also supports updating workflows in a secure way 😍).

You only need to add a .github/dependabot.yml config file. Personally I recommend a weekly interval (with a lot of projects daily is a bit horrible).

version: 2
updates:
  - package-ecosystem: github-actions
    directory: /
    schedule:
      interval: weekly

  - package-ecosystem: npm
    directory: /
    schedule:
      interval: weekly

The StepSecurity tool we have seen in the previous chapter is also capable of doing it 🚀.

Also, think to enable Dependabot alerts in the Security tab. This will allow the bot to open pull-request to fix known vulnerabilities by looking at your dependencies (referenced in package.json or others).

🔬 Adding CodeQL scanning

To enhance security even more you can add a SAST tool like CodeQL. Like scorecard it will report security scanning alert but for your codebase.

Here an example:

A great way to make sure that newly added code does not contain vulnerabilities that were obvious to detect.

👀 Note that once again StepSecurity can set up the workflow for you.

📜 Enable Security advisories (and others)

Github Security tab as a lot of cool features that help you maintain the security of your project. If you have followed all my previous chapters, most of them should be enabled now.

Make sure to also enable Secret scanning alerts.

For an organization many of these parameters can be forced on all repositories. Go to Settings > Code security and analysis. You will have the options to enable/disable all.

💡 OpenSSF Best Pratices program

Previously known as CII-Best-Practices, this program indicates that the project uses a set of security-focused best development practices for open source software.

So I registered my first project on the website. It was a good surprise because it allowed me to question the quality of my documentation and tests 😬.

Seeing the different levels and questions really helps you think about what you're missing (and possibly learn about the concepts you don't know about yet.. Like SBOM).