Best practices to keep your projects secure on GitHub | Hacker News Reader

Best practices to keep your projects secure on GitHub

github.blog

81 pointstodsacerdoti34 comments

Article doesn't talk about much, just a bit on dependencies apparently from someone focused on supply chain security at Github.

At previous role, the more we looked at some of the technical controls around security within github itself, and had a number of security concerns. There's alot of nuance which is hard to go through and comment on, but the defaults and controls caused us lots of concern.

Here's a good writeup for anyone interested: https://cycode.com/blog/github-actions-vulnerabilities/

Thanks for your comment! I'm Justin Hutchings, the author of that blog, and you're right that it was pretty narrowly focused on dependencies. We've been making a concerted effort to post about a number of security topics lately to provide best practices for users, everything from coordinated vulnerability disclosure, to how to protect from supply chain risks.

You can find all of our security related blogs here: https://github.blog/category/security/

And thanks for sharing that blog, I'll pass it along to my colleagues in the Actions team.

Article is all about dependencies. And it only mentions JavaScript. So maybe a better topic would be: "How to use GitHub dependency tool to secure your Javascript project"

It looks like they support other package ecosystems as well: https://docs.github.com/en/code-security/supply-chain-securi...

That said, the article does indeed seem to focus entirely on dependencies.

I’ve noticed Dependabot isn’t always even the greatest for JS projects. There are popular front-end frameworks such as Angular or React. When it makes PRs for currency updates, it seems unaware that it should update all packages for a particular framework or update @types imports when it updates a package import.

Hi from the Dependabot team! We're working on a fix for the Typescript @types problem that should be available very soon.

On the topic of security, I am surprised there aren’t more safeguards for marketplace actions. I work in a larger organization and see that folks very much want to pull in actions that solve an immediate need without any type of vetting process. These actions are part of your build pipeline and can pose a substantial security threat.

Dependabot does not currently scan for outdated or vulnerable marketplace actions. It’s difficult for Enterprise Orgs to ensure only vetted actions are used. I think this area of GitHub is ripe for security and governance improvements.

So if you are concerned about this, I'd suggest looking at the following:

* OpenSSF Scorecard Action - https://github.com/ossf/scorecard#scorecards-github-action

* Step Security Harden Action - https://github.com/step-security/harden-runner

I realize that this means trusting these providers but they seem at least tacitly blessed by GitHub. https://docs.github.com/en/actions/security-guides/security-...

Thanks, those are great resources!

> It’s difficult for Enterprise Orgs to ensure only vetted actions are used.

You can already to this

1. Visit Settings > Actions > General Actions Permissions > Policies

2. Select "Allow non-org actions and reusable workflows"

You can then allow GitHub authored actions, verified publish actions, and OR provide an explicit allow list of actions.

I maintain a somewhat popular action and advise people to specify a commit if they use my action, but they want to just depend on v1 and trust me to never screw up. They don’t know me. Why do they think I’m not going to sell out to the first person who offers me a six pack to merge their code?

From what I can tell, there appears to be two camps.

1) Do not update dependencies (because updating to the latest version just because is silly) 2) Update dependencies (because security)

Personally, I fall into the second group (with caveats). I've found that Dependabot helps with the tedious work of updating versions by hand but at the same time provides a check so that I manually approve. This seems to work out to be a decent balance. I've also moved away from using :latest or @v2 etc. and switched to using commit hashes/image digests. Once again, Dependabot is helpful for tracking changes/updates once you switch over.

The one annoying thing is that Dependabot does not always trigger on a regular basis (once a day) but I've found that bumping .github/dependabot.yml reliably triggers it.

> Do not update dependencies (because updating to the latest version just because is silly)

That's quite the straw man; I seriously doubt that anybody is saying you shouldn't update because it's "silly". Blindly pulling updates is how you get compromised by supply chain attacks.

Not naming names but certainly I've encountered open source projects that reject updating until the last possible second (end of life, security vulnerability etc.)

That can be a function of effort, too; updates can be disruptive, and not everyone has the CI+testing infrastructure to handle it without significant manual work. There's a reason LTS distros are a thing.

> 1) Do not update dependencies

We regularly ding companies that don't update dependencies. No offense, but how do developers sleep at night having their application littered with known vulnerabilities?

One argument, if the vulnerabilities don't affect you for whatever reason, it probably doesn't matter much. Lots of vulns these days have a fair load of caveats attached, and if they don't apply, one could argue upgrading is not required.

Note: I'm not taking a stance on if I agree or not with this argument.

Fair. But do most companies know whether the 638 child dependencies on <insert JS library here> affect them or not?

LOL! only 638? That might be low :)

If the application is not exposed to public internet - who cares ?

TBH most best practices preach for security by obscurity.

If you talk to any good vulnerabilities researcher - they will tell you what to really look out for.

"We're not internet-facing, so we're not at risk, so we're not concerned with security." Standard misconception. I once worked with a team running a large Hadoop cluster. Everything in a private network. Nothing internet-facing. No risk, right? Well, a Python library they were importing got compromised and was using all their nodes to mine Monero. Oops! The cluster had been running for weeks. The only reason anyone knew about it was the performance of the cluster was terrible; all the CPUs were maxed, yet no jobs were running.

This example is a borderline case. This means that not only they got hacked but also pip repo they were using.

Which means that their provider also did not run any dependency scans.

Tho if they fetched that from github open source repo -> yup thats just incompetence.

On the other hand, how do developers sleep at night after updating their dependencies as it will now be littered with new unknown vulnerabilities.

The biggest correlated constant for bugs is that more lines of code = more bugs. As dependencies get updated they add more new features that I probably don't care about which adds more lines of code and therefore more bugs and security vulnerabilities.

I appreciate there is a balance between the two, but in my experience updating dependencies has broken things a lot more often than not updating things has broken things, and when that happens I find it a bit of a ridiculous idea that the maintainer has somehow made their product "more secure"(something that is usually a low dev priority) while at the same time introducing new bugs with the new features (something which is a higher dev priority) and they didn't even get that right.

> (something that is usually a low dev priority)

I guess you just proved my point. Thanks.

I figure if a dependency is good enough for a new project it's good enough for an existing one as well. Either way, it needs to be vetted.

Dependencies must not be seen as "a blackbox someone else have built and distribute" but as part of your project, only developed by someone else. If you are the leader of your project it's your duty to review code from all developers participating to the project you are leading.

That way means you give a bit of trust to anyone, in the end we all work for a purpose, rouge agents are rare in any community, but not more than a bit, so updating is a must, not doing it means having someone who work for nothing, but with checks.

If that's overburden it's because actual IT development model, separate stuff for anything instead of an operating-system-environment-framework with a unique language (like ALL from the past) and a single application formed by tons of individual functions/methods/modules (again like ALL from the past) and such issue can't be solved keeping up the actual paradigm.

It’s also easy to stick with #1 and leave pinned to specific versions and only update for security reasons.

This used to be a pain so automatically updating was an easy way to stay up to date and reduce risk. But now with dependabot, I can pin to specific versions and leave it there forever, until dependabot detects the vulnerability and submits a PR.

If you only have a limited number of dependencies and whose maintainers have a good culture of documenting their changes, then there’s the middle ground of checking the release notes/changelogs and only updating for relevant security fixes, and for other updates at your own discretion.

Dependabot was created with the philosophy that staying up to date all the time is the best strategy. The main reason for that is because if you wait to update until there's a CVE, there's a chance that you'll be so far out of date that you'll have to sort out breaking changes in your dependencies when there's urgency.

It's not a perfect strategy, since there's non-zero risk that the latest version was hijacked by a malicious user, but the chances of a hijacked dependency are much lower than the chances of relying on something with a known vulnerability.

Many popular Python libraries are available as Debian packages. Replacing pip/virtualenv dependencies with their distro-packaged equivalents firmly ties your projects to your distro and comes with other issues, but could also mean nearly automated updates for security patches.

Advantages: 1. Security patches for free with distro package updates. 2. More consistency of dependency versions across projects. 3. Dependencies won't fall too far behind. 4. Major upgrades only need to happen with new distro release.

Disadvantages: 1. Less control over dependency versions - can't lock to specific versions. May be forced to upgrade when security patches drop. 2. Not getting the very latest versions - your distro e.g. Debian Stable is often a bit behind. 3. Having to upgrade everything at once with a new distro release. 4. Can't run apps with different versions of dependency on same VM. 5. App will be closely tied to a particular release of your distro.

Mitigations of disadvantages: 1. Distros like Debian are pretty good about fixing security issues without affecting functionality/APIs. 2. If you like "boring" tech more than bleeding-edge this may not be a problem. You'd be insulated from version churn, while a major distro's install numbers will hopefully bring stability. 1,2. You can still use virtualenv for certain dependencies if you absolutely have to have the latest version or lock at an old version. 3. Distros like Debian keep their old releases around for awhile and the upgrade window is pretty long. 4. If you run apps in own their own VMs that removes a major need for virtualenv in the first place.

Another disadvantage: the specific package you want might not be packaged by your distro, and may not be compatible with the versions of dependencies that your distro does package.

...don't let them be scanned by HackerRank folks.

Love the Dependabot Alerts page which scans for vulnerabilities. We use Sonarcube and Dependabot to apply static code analysis. Anyone has an idea if this is enough or some other tips?

Speaking of NPM deps, another mitigation is setting:

    ignore-scripts=true

As previously discussed, https://blog.uidrafter.com/getting-rid-of-npm-scripts

Reply on news.ycombinator.com