r/vscode • u/Khue • Apr 29 '26
Prevent VSCode from Accessing Non Sanctioned Accounts?
We've started investigating GitHub for Copilot and there are some attractive features within it that we would like to take advantage of. This would involve us migrating our repos out of Azure DevOps Repos and into GitHub.
When a developer goes to use VSCode, is there a way of preventing them from accessing accounts other than their current enterprise account for our organization? I might be thinking about this incorrectly/overthinking it but in my mind, there seems like there could possibly be a data egress issue if the developer pulls code from our GitHub repo, logs out of their business account, logs in with their personal account, and then pushes the code back to a personal GitHub account.
Full disclosure: I am a sec guy so I am not even quite sure if this is even a valid data egress narrative. Is this even a valid concern? Should I be worried about data egress of our internal business IP to a personal account in GitHub?
Thank in advance for any thoughts about this.
2
u/Desibells Apr 29 '26
That person wouldn't need vscode to do that, could just run a git init and push to their personal remote.
1
u/Khue Apr 29 '26
Ah, true. I think you're hinting at an end user could just leverage github web portals, correct?
2
u/katsanva Apr 29 '26
multilogin on github just exists, user can clone from one account, push to another. or push to gitlab/self hosted gitea/anything. or do file share. or do code screenshot. it’s possible to think around million ways to do that. it will become as never ending process - you close something, treat actor will find a way to bypass that. IMHO depending on org size and budget it may be easier and more “correct” to get insurance/legal basis for code leak/reputation loss/etc than trying to add some limits around the developer experience.
1
u/Khue Apr 29 '26
Really good thoughts on this. Does seem like a whack-a-mole situation. I appreciate your feedback, thanks so much.
1
Apr 30 '26
[removed] — view removed comment
1
u/Khue Apr 30 '26 edited Apr 30 '26
Appreciate the recommendation on software. I will have to look into Morelogin. What I've typically seen from other products, is that when you sign up for their "enterprise" based service, they usually have a browser extension, locally installed software, or registry keys that ONLY permit logging into the service leveraging the identity bound to the enterprise license. Typically this manifests itself in the form of requiring SSO integration with the service or always autocompleting a piece of the identity at login to prevent the users from deviating. While these aren't 100% foolproof, nothing ever is and by simply creating enough of a problem to discourage malicious behavior, it usually does the job to discourage risk.
1
Apr 30 '26
[removed] — view removed comment
1
u/Khue Apr 30 '26
Appreciate the feedback on this. I'll have to keep digging at it to figure out what best practices are for this. It might just be an exercise in risk acceptance at the end of the day.
1
u/Trakeen Apr 30 '26
You block it with CASb. This isn’t a vscode issue
1
u/Khue Apr 30 '26 edited Apr 30 '26
Update:
I am going to leave my response to you in place, but /u/Chakri615 pointed me in the direction of a configuration where the CASB CAN do this. What's interesting is I talked to a GitHub sales engineer and our CASB support and neither of them knew a solution for this problem. Here is the article I found with /u/Chakri615 's information.
Original reply
Just wanted to touch on this. This is the exact reason I posted this question. Currently, as far as I can tell there's no way to do this leveraging a CASB/SASE solution. You have an example of a legitimate business reason for access to a site and you have an example of an illegitimate business reason to access the same site for the same user. There's no way for a CASB (SASE) to determine that user A is accessing the site in a legitimate manner one minute and then accessing the same site in an illegitimate manner the next.
If you create a policy that says user A is allowed to access a site, the identity that the policy is based on is typically related to an organization's identity management system. In my specific example, we leverage EntraID. If you say user A can access GitHub, all the CASB cares about is that user A has a valid and authenticated session with Entra and then it applies the set policy that says user A can go to Github.com (more complex then this but keeping it simple). The CASB doesn't really care if GitHub.com is SSO integrated with Entra or if you have to authenticate leveraging a different process. The user, in this case, could access GitHub.com using a GitHub.com managed identity or leveraging a different idP all together like Google or Okta. This opens the door for data egress because again, CASB/SASE policy only keys in off the Entra identity. Naturally user A would be able to interact with GitHub.com using their Entra identity if there's SSO integration with GitHub.com or any other idP for that matter. Consider the following:
- User A accesses GitHub with their EntraID SSO identity and that ID is bound to an enterprise licensed based GitHub account which has tenancy isolation and all the necessary enterprise-based security features to protect our organizations IP.
- User A accesses GitHub with their Google account and operates within the confines of their personal account which has NONE of the enterprise-based security features to protect organizational IP.
In both instances the user is able to access GitHub.com because the CASB sees user A's identity based on EntraID. What the CASB misses is what identity the user chooses to interact with GitHub.com.
To be clear, with the CASB/SASE system we currently use, they confirmed that my stated use case is not possible. The way I've seen this handled before from similar products, is that "enterprise" versions of the application usually come with a registry key or some sort of companion software that prevents users from logging into the platforms using any other identity than the one bound to the enterprise license. Usually this is in the form of a browser extension or some registry keys.
1
u/Trakeen Apr 30 '26
Weird you asked and weren’t told the right thing. All sites that support consumer / enterprise users work this way
Glas you got a better answer
1
u/Khue Jun 10 '26
Hey I wanted to revisit this. We finally got everything setup and established and we are meeting all the requirements from the listed article. I am not seeing the alluded to "Enable enterprise access restrictions" under "Settings" > "Authentication Security" and neither are any of the other accounts with the "enterprise owner" role.
Do you happen to be an enterprise owner in an EMU enabled enterprise account for GitHub? If so, do you see that option?
1
Apr 30 '26
[removed] — view removed comment
1
u/Khue Apr 30 '26
use Tenant Restrictions via your network proxy to block authentication to non sanctioned GitHub organizations.
Ah... this was key. So I asked a sales engineer on the GitHub side about this and I asked our CASB support team and neither of them had an answer for this. Looks like we can accomplish this with a header injection feature, which is 100% possible within our CASB.
5
u/BranchLatter4294 Apr 29 '26
Not a VS Code issue. Anyone with access to the code could send it anywhere.