Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Best practices to keep your projects secure on GitHub

github.blog

Post reply on HN
Print view View original

11–20 of 35 posts

Re: Best practices to keep your projects secure on GitHub

#11

Post by mbesto »

newman314 wrote: post #8

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…

> 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?

Re: Best practices to keep your projects secure on GitHub

#12

Post by newman314 »

yjftsjthsd-h wrote: post #9
newman314 wrote: post #8

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…

> 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.)

Re: Best practices to keep your projects secure on GitHub

#13

Post by cebert »

newman314 wrote: post #10
cebert wrote: post #5

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. I…

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!

Re: Best practices to keep your projects secure on GitHub

#14

Post by notreallyserio »

newman314 wrote: post #8

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…

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.

Re: Best practices to keep your projects secure on GitHub

#15

Post by yjftsjthsd-h »

newman314 wrote: post #12
yjftsjthsd-h wrote: post #9

Earlier quoted context omitted.

> 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.

Re: Best practices to keep your projects secure on GitHub

#16

Post by kkfx »

newman314 wrote: post #8

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…

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.

Re: Best practices to keep your projects secure on GitHub

#17

Post by twistedpair »

cebert wrote: post #5

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. I…

> 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.

Re: Best practices to keep your projects secure on GitHub

#18

Post by zie »

mbesto wrote: post #11
newman314 wrote: post #8

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…

> 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.

Re: Best practices to keep your projects secure on GitHub

#19

Post by prepend »

newman314 wrote: post #8

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…

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.

Re: Best practices to keep your projects secure on GitHub

#20

Post by jefurii »

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.

Post reply on HN