Securing a GitHub repo is a ton of work(codeofhonor.substack.com)
codeofhonor.substack.com
Securing a GitHub repo is a ton of work
https://codeofhonor.substack.com/p/securing-a-github-repo-is-a-ton-of
9 comments
So much advice these days is "do what you're supposed to do instead of being lazy and it works out!".
bombolo(2)
More of a rant than anything. I spend a lot of time doing this and there are so many little things you could harden a little bit.
Kind of a rabbithole of energy!
Kind of a rabbithole of energy!
A significantly complex Github repo with CI, complex permissions, Git hooks all over, is pretty much its own software system that you have to manage, just like server management via Ansible or what-have-you.
Github does a great job at implementing sane defaults but I understand the author's point - there can be a lot to do and you usually don't know you're even supposed to worry about this until way later when security auditors file like 9001 reports about your repo settings.
Github does a great job at implementing sane defaults but I understand the author's point - there can be a lot to do and you usually don't know you're even supposed to worry about this until way later when security auditors file like 9001 reports about your repo settings.
I learned yesterday that you can use Terraform to configure GitLab: https://registry.terraform.io/providers/gitlabhq/gitlab/late...
You can use it for GitHub too.
https://registry.terraform.io/providers/integrations/github/...
https://registry.terraform.io/providers/integrations/github/...
Thanks for understanding. Security engineering is growing so complex. I don't know how major corps on the scale of Boeing ever achieve compliance. And even then, they have a whole market of different compliance standards to comply with.
Phew.
Phew.
> I don't know how major corps on the scale of Boeing ever achieve compliance.
It's not that hard. They just remove all of your agency as a user. You can push commits, open branches & pull requests, and merge if 2 people approve it. And that's it.
Want to merge? Restricted. Make a new repo? Restricted. Use a GitHub Action? Restricted. CODEOWNERS? Restricted. Branch filters? Restricted. Forks? Restricted. Releases, packages, artifacts, security, insights, settings, webhooks, environments, pages, wiki, issues? Restricted. Access a repo you aren't a member of? Restricted. Protected tags, dependency graph, dependabot, code scanning, secret scanning, deploy keys, secrets, github apps, oauth, notifications? Restricted. Stars? Restricted. And your SSO token expires every hour.
Can't get hacked if you can't do any work!
It's not that hard. They just remove all of your agency as a user. You can push commits, open branches & pull requests, and merge if 2 people approve it. And that's it.
Want to merge? Restricted. Make a new repo? Restricted. Use a GitHub Action? Restricted. CODEOWNERS? Restricted. Branch filters? Restricted. Forks? Restricted. Releases, packages, artifacts, security, insights, settings, webhooks, environments, pages, wiki, issues? Restricted. Access a repo you aren't a member of? Restricted. Protected tags, dependency graph, dependabot, code scanning, secret scanning, deploy keys, secrets, github apps, oauth, notifications? Restricted. Stars? Restricted. And your SSO token expires every hour.
Can't get hacked if you can't do any work!
When working on open source software and collaborating via public GitHub, you can almost forget that git is a distributed version control system.
But in the restricted corporate setups you describe, git's distributed nature shines.
They can lock down internal GitHub as much as they want to, but that won't keep you from making local commits, or exchanging commits directly with your coworkers while developing.
But in the restricted corporate setups you describe, git's distributed nature shines.
They can lock down internal GitHub as much as they want to, but that won't keep you from making local commits, or exchanging commits directly with your coworkers while developing.
Won't have to worry about compliance if you are forced to comply every hour /s
> I don't know how major corps on the scale of Boeing ever achieve compliance.
Boring, repetitive software development processes that prioritizes closing potential holes vs. speed of development. When you stop to think about it, explains quite a bit of why big companies are so slow to release?
Boring, repetitive software development processes that prioritizes closing potential holes vs. speed of development. When you stop to think about it, explains quite a bit of why big companies are so slow to release?
eeyup, Witness!
Many of these have nothing to do with Git or GitHub in particular (dependabot, storing live credentials in the codebase...).
It'd be nicer if you managed to focus on the part of the Git/GitHub story: though, as a rant, it's perfectly fine :)
It'd be nicer if you managed to focus on the part of the Git/GitHub story: though, as a rant, it's perfectly fine :)
I've found StepSecurity's tooling helpful in getting my repos locked down.
* https://app.stepsecurity.io/securerepo * https://app.stepsecurity.io/
It also helps to go through the GitHub options to lock things down. Also, configure Dependabot to update "github-actions"
No affiliation. Just a happy user.
* https://app.stepsecurity.io/securerepo * https://app.stepsecurity.io/
It also helps to go through the GitHub options to lock things down. Also, configure Dependabot to update "github-actions"
No affiliation. Just a happy user.
Not really. Just another substack think piece.
Complete with the living modal upsell popup ala Medium. Will people ever learn? (No, no they won't)
Complete with the living modal upsell popup ala Medium. Will people ever learn? (No, no they won't)
Yes, we replaced Medium spams with Substack spams.
Too much work to set up their own little blog, I guess.
Too much work to set up their own little blog, I guess.
I wouldnt be surprised if it wasnt more about discoverability.
Lotsa folks are tired to play The Google SEO Game and thus just give up on hosting their own content.
If they care enough about their posts to sell themselves, then its on their own interests to own the publishing platform.
I guess we should be happy that at least aren't articles published as tweets.
I guess we should be happy that at least aren't articles published as tweets.
> A crap link is one that's only superficially interesting. Stories on HN don't have to be about hacking, because good hackers aren't only interested in hacking, but they do have to be deeply interesting.
I'd say this link violates the rules. It says absolutely nothing new, it is shallow, has a popup.
I'd say this link violates the rules. It says absolutely nothing new, it is shallow, has a popup.
GitHub does a pretty good job requiring oauth or ssh key authentication, and the new finely-grained personal access are awesome, I just switched all my apps to use more locked down PATs.
The far you reach from GitHub's ecosystem, that's where most of the vulnerabilities are.
Repo-specific deploy keys, read-only keys and branch protection are my "pro" security hardening steps.
Shoving all secrets in ENV isn't a clear improvement either. Sure, most CI services attempt to mask them, but it's trivially to extract the secrets. For GitHub, you have to approve incoming first-time PRs, but it's a huge vector someone determined can exploit.
The far you reach from GitHub's ecosystem, that's where most of the vulnerabilities are.
Repo-specific deploy keys, read-only keys and branch protection are my "pro" security hardening steps.
Shoving all secrets in ENV isn't a clear improvement either. Sure, most CI services attempt to mask them, but it's trivially to extract the secrets. For GitHub, you have to approve incoming first-time PRs, but it's a huge vector someone determined can exploit.
Doesn't really seem like "a ton of work".