Hacker News new | ask | show | jobs
by twistedpair 1277 days ago
IAM on GitHub needs so much <3. So broad, much ow.

For example, I trialed major security vendor's enterprise product. They required their app be granted Admin on the GitHub org. All they needed to do was create issues, PRs, and read source code for analysis. There are scopes for that.

I was eventually on a call with a principle engineer in this company, who kept saying they needed this permissions, and I kept showing him the API docs that showed that wasn't so. Eventually he said, "well, we won't _use_ all those permissions, so just give them to us anyway, because it's easier this way." Sure, I'll give you the ability to change all my code, add/remove users, drop repos... etc, and trust that some day, when you're hacked, someone will not use those over granted permissions maliciously?

Security is hard. Be careful what permissions you give your 3rd party GitHub integrations.

8 comments

>>"well, we won't _use_ all those permissions, so just give them to us anyway, because it's easier this way."

Devs have been doing that since the dawn on computing. Ohh your App needs to be able to write to a protected folder on windows. Dont document what folder just force the app the run as Admin.

Early Android Apps asked for all the permissions, all the time because of lazy devs

security is hard, and gets in the way of what the devs wnat to do so they just find ways to bypass it

Early Android had pretty coarse permissions IIRC. It wasn't quite "root or nothing" but somewhat closer to that than it is today.
"because of lazy devs" :thinking:
Definitely not because of the pesky product managers and sales teams who want a new feature to sell yesterday to boost their EOY bonus...
Ask them to sign a document accepting all liability in those situations. I think the conversation will quickly change..
"Sorry, we don't accept redlines or riders for accounts that are less than $750k ACV."
> I trialed major security vendor's enterprise product

> just give them to us anyway, because it's easier this way

Wow. The state of security is still sad in our profession, if even major security vendor(s) don't adhere to basic principles like "principle of least privilege".

Heh. Reminds of one of Symantec's "Enterprise" products.

Turned out, if you're logged into the central (on prem) server it has the ability to run commands as root/superuser on any of the connected clients (generally servers themselves).

The commands run this way are _not logged_ and don't show up in any system audit logging.

After we pointed this out as a security problem in itself, they released a new version that _apparently_ had this functionality removed (was in the release notes).

But digging into the new release, they'd just moved the functionality into different binaries and hoped no-one would notice. :(

The mind boggles at what some of these places will try.

"Required functionality..." They're just not telling you who the requirements come from.
It's not just security vendors, it's everyone.

You can't even set up popular software like Tailscale with a github login without it requiring access to your organization's private repositories.

It's like mobile phone permissions in the old days where your calculator needs access to your contacts and location.

I thought technology companies learned this lesson a decade ago, apparently not.

My experience with security vendors is that there's a lot security vendors who check checklist compliance solutions that on paper helps to be compliant but in reality are extremely insecure malwares.
It was only recently that PATs got the ability to be scoped per repo, and even that's still in beta.
But frustratingly fine grained scoping doesn't work for repos part of an Organisation! Like, what!
You need to choose from a drop-down that the token owner is the organization, not you. Then you can create a token for a repo of the org. Your org must opt-in to beta.
Definitely - also its pretty easy to lose track of all things. Started a tool to audit github apps and misc permissions for an org which is currently basic atm but hopefully in the future more checks will be added - 3rd party integrations and apps are up there: https://github.com/crashappsec/github-analyzer. Any issues or feature requests are welcome and hopefully will expand it soon!
I had exactly this same experience with Vercel, and we backed out of using them for our major open source repo as a result.
Ugh. Doesn't raise the trust in their competence of protecting admin access credentials to GitHub. The same mindset leads to "We use just one shared ssh cert, because it is easier. And our VPN solution is a 2nd factor in any case".
Name and shame.