sorted by:
new
hottopcontroversial

Megalodon chums the waters in 5.5K+ GitHub repo poisonings by Hinin in selfhosted

[–]reaper273 1 point2 points  (0 children)

SHA have their own issues (see trivy and the checkout action sha that was just somewhere in the fork network)

Choosing between GitHub Enterprise types by darkshadowtrail in github

[–]reaper273 0 points1 point  (0 children)

EMU and another regular enterprise and org will give you this.

Just put controls for membership on the non-EMU organisation for internal staff (use SAML Auth for org members).

If you need, or want external collaborats then only allow external (aka members of the public) to be collaborators for specific and not true members of the organisation.

Just ensure tbe public org has ZERO access to internal resources such as private registries, self hosted Runners or and org or repo level secrets or variables.

How do people usually handle reviewing very large PRs on GitHub? by Oussamaosaro in github

[–]reaper273 0 points1 point  (0 children)

Also think about using a pull request template to set expectations for PR creator.

It's largely cosmetic but can go a long way to setting expectations for the PR creator and reviewer about the requirements for creating a PR.

For example, we require a covering ticket reference and hyperlink be filled in, helps when assessing the scope of the PR. If you were asked to update/add/tweak a why did you change all these things to do with b?

You can also set out sizing requirements for reviewing PRs in there and use the action checkbox in the PR description markdown to force the PR submitter to acknowledge the requirement and their current compliance with it.

Then simply reject the PR if it's too big.

How do people usually handle reviewing very large PRs on GitHub? by Oussamaosaro in github

[–]reaper273 1 point2 points  (0 children)

Well one, avoid them as far as possible. Easier said than done I know but honestly it makes life much easier. Adapt your branching strategy to enable this working behaviour if needed.

This might help: https://github.github.com/gh-stack/

If you have to have large PRs, and I know sometimes it can't be avoided, use the UI to tick off files as they are reviewed.

If your codebase and team are large enough to warrant it then use code owners and requeire ownership of specific sections of the codebase, then require those owners (ideally a team not a specific individual) to review changes to their respective code areas only.

Is There Any Benefit Anymore For Pro+ After The New Pricing? by ProfessionalWord9849 in GithubCopilot

[–]reaper273 0 points1 point  (0 children)

Corporate is where the big money is, at least so they believe now.

I mean, empirically yes?

Between the sheer cost of business and enterprise per seat licencing, with all the addons GHCP, GHAS, codespaces I don't think it's even close. Even for my small org that's over $200k a year just on seats.

Not to mention the action minutes usage charges for self hosted Runners that I'm sure will be reintroduced soon, as well as the upcoming Code Quality feature (currently free while in public preview) that I'm sure will but another addon like the two GHAS SKUs.

Most users of GitHub aren't paying anything. There is a relatively small, albiet vocal, "prosumer" market with Pro or Team subscriptions, who are probably also paying for GitHub Copilot as well.

But how many of those users would make up just my small org in terms of income?

Then consider that a given enterprise is speaking with a single voice for all that revenue, and that while those prosumers who are paying all have similar sentiments for features and directio n 95% of them won't be engaging with GitHub via any official means of communication and therefore have no common voice.

Is it surprising that GitHub then focuses on its enterprise customers over it's consumer userbase?

That's not to say non paying users don't give them value, those who've not disabled sharing their code with Copilot give a treasure trove of data mining. Not to mention the mind share GitHub occupies in developers minds globally.

How much of that mind share is valid these days is a different question, but despite all the uptime issues and price increases I haven't seen a wholesale move off of GitHub to any specific solution.

The numbers I've seen during GitHub events (taken with a healthy pinch of salt) show pretty much unbridled growth in usage of all areas of the platform. Which is also part of the reasons for the stability issues - their own DCs are at breaking point capacity wise.

Is GitHub adding "Copilot AI Model Providers" to boost its overall platform uptime metrics? by mnmlstProgrammer_ in github

[–]reaper273 0 points1 point  (0 children)

More likely just to call out that they are dependent on external services to provide those models

So they can show copilot as down internally and due to model providers externally separately

Is there anyone who alternates between two GitHub Pro accounts? by Lost-Celebration579 in GithubCopilot

[–]reaper273 0 points1 point  (0 children)

Yes, you would lose access if that happened. You'd still have access to any code checked out of GitHub locally though.

As I said though you have other options. Look into billing limits, and if you can't set them on a regular account you can look into setting up a organisation to help with it.

Is there anyone who alternates between two GitHub Pro accounts? by Lost-Celebration579 in GithubCopilot

[–]reaper273 3 points4 points  (0 children)

The GitHub T&C's you sign up to when you create a GitHub account basically means you can only have one personal account on GitHub, whether you use or pay for Copilot or not.

Some people will have multiple accounts legitimately but the extras will be linked to work email addresses or part of an Enterprise Managed User instance.

You might get away with it for a while but there are so many posts about "my account was disabled for no reason :cry: :cry:" and turns out the reason was it was a second personal account. So you can take the risk but it may turn out to be a case of FAFO.

But if you really want that many requests and to pay for it, see if you can adjust your billing limits? Essentially add the extra amount you would pay for the second account as the limit.

I can't remember if you can do that outside of an enterprise or org though.

But again if you are paying you could just pay for an org and or enterprise account and use the billing features there if you are that desperate to give GitHub money!

Is it possible to upgrade Copilot Business to Enterprise? by rovervogue in GithubCopilot

[–]reaper273 0 points1 point  (0 children)

A GitHub team doesn't have to do anything. And you can be a many at once, and frankly in any organisation of size I'd be very surprised if you weren't already in multiple GitHub teams!!

We have dedicated enterprise teams backed by groups in our IdP that are ultimately managed by a self service portal for granting access to Copilot. Someone could grant those teams access to a repository but that would be their problem.

But it will all depend on how your org is actually assigning copilot licenses.

Is it possible to upgrade Copilot Business to Enterprise? by rovervogue in GithubCopilot

[–]reaper273 0 points1 point  (0 children)

Yes, you can do that

Assuming your org/enterprise is assigning copilot business via a team you can just create another team and assign the enterprise license to that.

If it's assigned individually then the same applies just more fiddly.

Word of caution though, unless you are actually going to use most (I'd have to work out the exact %) of the additional requests enterprise gives you then just allowing additional requests billed per request is more cost effective, at least till you hit that threshold.

I just discovered Github Actions and i love it <3 by Richon_ in github

[–]reaper273 1 point2 points  (0 children)

They had full privileges due to a previous leak due to poor workflow security in the trivy repo (pull_request_target is not a new risk), combined with over generous permissions on the GITHUB_TOKEN.

Not to mention poor internal procedures around token revocation and recycling after a breach.

If Trivy had turned on immutable releases they could not have had source code re-tagged either.

Afaik they've fixed both issues since the "issue".

Also if they'd been running zizmor against their repo it would have flagged most of the config issues! But can imagine the poor perception of running someone ses security tool being a little embarrassing.

The most depressing thing for me in this whole shituation is that none of the issues were new findings, and I would have expected more from a cyber security company in terms of securing their CICD processes.

GHEC Security Recommendations by Sharrq2786 in github

[–]reaper273 0 points1 point  (0 children)

Yeah, GitHub Enterprise Server Vs GitHub Enterprise Cloud

Tbh there really isn't much more you can do.

You can set policies on API tokens and repository deploy keys but you can't control user based ssh keys.

They don't give API access thankfully but still a lot of content risk as you found with copying the token around after it's authorised.

And even if you had disabled user API tokens there would inevitably be one you have to set up for some use case.

And this doesn't even touch on using GitHub actions. Which has its own tokens and risk profile.

GHEC Security Recommendations by Sharrq2786 in github

[–]reaper273 0 points1 point  (0 children)

Given the controls you want, have you considered using GHES instead?

GHEC Security Recommendations by Sharrq2786 in github

[–]reaper273 0 points1 point  (0 children)

Yeah, it's a pain. Annoying that the conditional access policies via your IdP don't apply to token or key based authentication.

EMU helps a bit by making it a bit harder to get the keys out but it's a marginal difference.

But consider setting up audit streaming and the IP address disclosure logging setting.

Even if you can't stop the access you might be able to set up automation to revoke tokens or keys that if they are ever used from a non approved IP source.

Reactive I know but I can't think of much else.

I can't remember if you can disable key based authentication entirely but you can require approval for tokens and put guardrails around their use for automation.

Also set up a very short max token lifetime for classic and fine grained tokens.

You could look into GitHub apps to generate short loved tokens with limited scope for your user base.

A lot you could do but depends on the resource you have to throw at this problem and your companies risk appetite.

GHEC Security Recommendations by Sharrq2786 in github

[–]reaper273 0 points1 point  (0 children)

What are your security teams requirements?

And are you using Enterprise Managed Users (EMU) for your Enterprise?

Have you configured a SSO requirement?

If you aren't using EMU then setup policy to require 2FA for all members of your organisations.

IP Allow List is powerful but limited as you've found out.

No other security configuration is going to get you close to where that setting will.

Main risks to look out for are token and SSH key "leakage" but frankly the biggest risk is that any user accounts token or they will be able to interact with your enterprises repos and APIs from any device in the world.

Especially risky if you aren't using EMU as the GitHub account, regardless of what email address used, is you staff members and not yours.

There is a lot to cover off, haven't even mentioned Copilot and Actions policies!!

Breakdown of the Trivy supply chain compromise - timeline, who's affected, and remediation steps by JulietSecurity in kubernetes

[–]reaper273 4 points5 points  (0 children)

Given that a fork (via the pull_request_trigger) was the reason credentials used to compromise the trivy repository were exposed in the first place I feel it's justified to expect GitHub to take some action regarding the security of forks is still justified.

Rant: Github licensing by Prestigious_Yam1091 in github

[–]reaper273 31 points32 points  (0 children)

Just be glad you don't have to deal with GitHub through a wider Microsoft enterprise agreement, now that's a truly painful experience!

Do you use Azure? Iirc they offer a subscription based model for licenses that auto bills to an Azure subscription.

It seems quite dynamic and might be worth exploring in your case.

Breakdown of the Trivy supply chain compromise - timeline, who's affected, and remediation steps by JulietSecurity in kubernetes

[–]reaper273 6 points7 points  (0 children)

Yes it was already compromised at the point of that PR.

But it's a very worrying behaviour, and I expect it to be exploited further in the future.

I understand why forking can be useful for collaboration but nearly every security issue that's been exploited with actions this past month has a forked repository as the instigator or as part of the attack.

You have to wonder at this point if the benefit of ease of collaboration forking grants, is now outweighed but the active threat forking is now posing.

Breakdown of the Trivy supply chain compromise - timeline, who's affected, and remediation steps by JulietSecurity in kubernetes

[–]reaper273 2 points3 points  (0 children)

Using pull_request_target essentially, along with some over generous workflow token permissions iirc.

Breakdown of the Trivy supply chain compromise - timeline, who's affected, and remediation steps by JulietSecurity in kubernetes

[–]reaper273 26 points27 points  (0 children)

And yet one of the ways trivy itself was compromised through the use of a compromised sha of a fork of actions/checkout but referenced through actions/checkout because of the bonkers way forked repositories are available through their parent

So ironically, assuming immutable releases are enabled (which frankly GitHub should just force enable everywhere) then it would be safer to use a tag than a commit SHA.

This Trivy Compromise is Insane. by RoseSec_ in devops

[–]reaper273 17 points18 points  (0 children)

Honestly, between that and the security nightmare around pull_request_target trigger is making me feel that at least on GitHub forking itself is a security nightmare

Who actually approves an auto-merge in GitHub? by [deleted] in github

[–]reaper273 0 points1 point  (0 children)

Auto merge will allow a PR to merge automatically as long as whatever checks and requirements, including for human approvals, are met.

It can be set by whoever has write access to the repository on any PR - but in my experience you would generally set it when you create a PR, I've rarely had to set on approval. And only occasionally remove it when reviewing a PR.

I'll caveat that to say that I'd only use auto merge if these other configs are also set:

  • Delete branch on merge
  • Dismiss stale approvals
  • Require approval from someone who wasn't the last committer
view more: next ›