Open source education over restriction #173
Replies: 17 comments 8 replies
-
|
Thomas Steenbergen (EPAM / TODO SC) replied:+ I have had similar discussions with organizations where their security team wanting to do the same, mostly high compliance environments such as financial services or automotive companies but in those cases there were valid legal arguments. Still one of my arguments in a discussion with them was:
I proposed an alternative solution to prevent accidental pushes to any external Git repository - use a local script that automatically rewrites the remote URLs of any external Git repo - the core concept is described in https://medium.com/@pranavgore09/prevent-accidental-git-push-in-a-simple-step-55545d7821a5. Next, you deploy another script that on git push forces the engineer to review the diff and confirm its correctness before pushing it. I admit my alternative is technically a bit more complex than just adding a rule to the DLP agent but it does enables all your use cases whilst still satisfying the risk your security team is trying to address. |
Beta Was this translation helpful? Give feedback.
-
|
Mats Wichmann replied: indeed, what will likely happen is people using personal accounts on personal equipment to push to external repos, because they still want to work on them. Yes of course this will almost certainly be "against policy" but you're effectively risking activity moving to a harder-to-detect form. |
Beta Was this translation helpful? Give feedback.
-
|
Justin Abrahms (he/they; eBay) replied: Also, developers have dotfiles hosted in version control. |
Beta Was this translation helpful? Give feedback.
-
|
Jeff Billimek (The Home Depot) replied: Indeed, yeah we added dotfiles to the list which is an important one. And I agree with you that talent retention/recruitment isn't something security folks care about (but should). |
Beta Was this translation helpful? Give feedback.
-
|
Jordan Harband replied: such a policy will guarantee that one only hires and retains engineers that don't understand open source, which will dramatically weaken the org’s security stance. |
Beta Was this translation helpful? Give feedback.
-
|
Miguel Lorenzo Amarelle replied: Can you mark company repos as internal ? |
Beta Was this translation helpful? Give feedback.
-
|
Jeff replied: Yeah we're an EMU org and all our repos are either internal or private. |
Beta Was this translation helpful? Give feedback.
-
|
Phoebe [DigitalOcean] replied: very interested in this thread and am curious what an EMU org is? |
Beta Was this translation helpful? Give feedback.
-
|
Jeff replied: Aha I can speak to that! For Github Enterprise Cloud (i.e. your enterprise on github.com), there is a special configuration by which you can set your enterprise to use 'enterprise managed users' which are essentially special github users directly mapped to your IDP provider (e.g. AzureAD) These users do not have any sort of write access, while logged in to their EMU github account, to any other org/repo outside of your enterprise - no issues, no stars, no PRs, etc. I'm probably glossing over some important things but that's the gist of it. There are some not-so-awesome things about using EMU accounts for folks who need to participate in opensource outside of their enterprise. Basically, you need to log into your 'personal' regular github.com account in order to participate in spaces outside of your enterprise. Generally speaking you can achieve this via different browser sessions or different github ssh identities |
Beta Was this translation helpful? Give feedback.
-
|
Justin Abrahms (he/they; eBay) replied: We do a different thing with our github identities. We have SSO setup so you log into github w/ your personal account (or account created only for this purpose). Then you SSO in, and that gives lets you join github.com/ebay org. |
Beta Was this translation helpful? Give feedback.
-
|
Kevin P. Fleming replied: I worked for a company that considered doing this, and the end result was tat any DLP-based technique for this would be extremely fragile. The reason is that the GitHub web UI itself uses the same HTTP verbs (POST, etc.) as Git push operations do, and that UI's application-layer protocol is neither documented nor stable. As a result, any technique which is based on reverse-engineering the HTTP transactions to decide which ones to block will fail with both false positives and false negatives, and the frustration felt by the company's employees will be significant. |
Beta Was this translation helpful? Give feedback.
-
|
Justin Abrahms (he/they; eBay) replied: |
Beta Was this translation helpful? Give feedback.
-
|
Philippe Ombredanne (ScanCode) replied: I second Thomas Steenbergen (EPAM / TODO SC) wrt. to education over restriction. As an example of the problem with restrictions, I know a company that was blocking access to the FFmpeg web site such that their developers could not download it. The rationale (originating from legal and not security folks) was that using FFmpeg in their software products could possibly void some of the company's patents that FFmpeg may be reading on. The results was that every developer was effectively using their home and personal network to access FFmpeg which was overall producing rather un-intended effects and not reinforcing their overall patent posture. If you want to restrict, the only thing that I think may partially work could be to NOT use GH for proprietary things at all, establish a strong firewalling policy and deploy tools and processes to copy over code developed strictly internally to public orgs and repos only after vetting. That's been historically the ways of some very large tech orgs with tools such as https://github.com/google/copybara/ .... this is likely demanding significant to huge investments in resources, code and cash. And likely to be a significant contribution to work prevention with all the caveats listed by others above. |
Beta Was this translation helpful? Give feedback.
-
|
jeffwilcox replied: We continue to get slammed with accidental disclosure at our company, but we have to try and trust in some way. It's a tough one. Shadow IT is frustrating... |
Beta Was this translation helpful? Give feedback.
-
|
Justin Rackliffe (Fidelity Investments) replied: And remember TLS 1.3 starts breaking down a lot of the MITM controls if they do host validation (see apple.com endpoints as an example. Another approach is to talk about the risks and how source code is viewed internally. now dotfiles and secrets become a bigger concern, but that should be the same internally and externally and need alternatives like secret on demand. reframing the confidentiality of much of the code to a less sensitive (but still internal) classification can help with contextualizing the risk of a disclosure. there will always be sensitive code and that “accidental” push could happen, but if you move the controls from a trawling approach to lines focused on specific concerns the noise level goes way down and the efficacy of the control improves. |
Beta Was this translation helpful? Give feedback.
-
|
Mats Wichmann replied: That's one of the factors in the 12-Factor App model - no config in code, now no way to accidentally check in credentials and other secrets (although personally, I don't like their solution, I've seen too many things fail over the years because different deploys/developers have different env vars - in the old old days it used to be the bane of folks trying to move a tested script into a crontab entry. But that complaint is a different story...) |
Beta Was this translation helpful? Give feedback.
-
|
Lucas Gonze replied: One of my clients has a policy comparable to the one we’re discussing. It does burn a lot of time needlessly, but it certainly does prevent accidental pushes from a closed proprietary account to an open account. The key is that it’s not to prevent malicious republishing, only the accidental kind. To push accidentally you’d first have to create the repo in your public github account. That would be very much a conscious action. You couldn’t stumble into it. Jeff, I would make that argument to your security engineers. It’s not possible to accidentally push a repo. You can only do it on purpose. |
Beta Was this translation helpful? Give feedback.
-
|
Miguel Lorenzo Amarelle replied: The only case I see is cloning a project from repo A (open source project) I push to repo B in my organization and work with it to create a internal app. One developer forks A from GitHub because want to contribute and push all B commits by accident . |
Beta Was this translation helpful? Give feedback.
-
|
Jordan Harband replied: that seems pretty difficult to do by accident tho and good architecture design would likely avoid hardcoding secrets and config values, and instead modify the forked project to be configurable, and have the actual configuration itself live in a separate repo, no? |
Beta Was this translation helpful? Give feedback.
-
|
Lucas Gonze replied: Does Github have any kind of content controls? Anything along the lines of content ID? |
Beta Was this translation helpful? Give feedback.
-
|
Justin Rackliffe (Fidelity Investments) replied: |
Beta Was this translation helpful? Give feedback.
-
|
Justin Abrahms (he/they; eBay) replied: They also have a thing which amounts to "give us the format of your secrets and we'll make sure you don't push them" for github enterprise things. |
Beta Was this translation helpful? Give feedback.
-
|
Mats Wichmann replied: They do have some kind of checker - I was part of an abandoned project that they started hassling us about last year for having secrets checked in. There was some contributed piece that had something that looked like a particular type of secret, intentionally phony, but it triggered nonetheless, I don't know if github's own check or matching one of those company-submitted templates. |
Beta Was this translation helpful? Give feedback.
-
|
Mats Wichmann replied: They do have some kind of checker - I was part of an abandoned project that they started hassling us about last year for having secrets checked in. There was some contributed piece that had something that looked like a particular type of secret, intentionally phony, but it triggered nonetheless, I don't know if github's own check or matching one of those company-submitted templates. |
Beta Was this translation helpful? Give feedback.
-
|
To be honest I don't know if it's even possible to prevent that kind of thing. To be fair I don't know how you could avoid a bad actor to do such thing easily since some expert could certainly tweak the security of the device in order to bypass any of our preventive mesure... I would say that you should maybe :
maybe other possibilities :
However, I'm 100% sur that if a developer want to leak information he could do it with ease. In all cases so it's certainly good to perform some prevention and monitoring but that's will never stop bad actor. At least if you modify git in order to provide your own version of the command line you could insure that's impossible for them to do a mistake without wanting to leak intentionally the information. And I hope this should be enough to prevent it since that's will be a strong argument during a judgement to ask for the maximum punishment. Like you say : And for that point 1 and 2 should be more than enough. By the way a tool based on git and could prevent unintentional commit to a repository is certainly highly valuable for a lot of company, so it's certainly possible to monitize such tool too. Personally I haven't find a solution for this kind of concern online... And like other say this will really be fragile since people will be able to perform the task from github UI. Maybe you can create a Mirror website for github and allowing user to use it only, so you can block the direct use of github.com and other website and force people inside your organization to pass through to your website and UI so you can allow them to only fork or download project but not to push source code using the UI. Using git Hooks to prevent the user to perform unintentional commit using a whitelistTo restrict users from committing to only a specified whitelist of repositories, you can create a server-side Git hook that runs before each commit and checks whether the changes being committed are within the allowed repositories. Documentation : https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks Why server-side pre-receive hook over Github action for our usecaseThe main difference between doing it server-side using a pre-receive hook and using a GitHub action is the level at which the check is performed. When you use a pre-receive hook, the check is performed on the server-side, which means that the commit is rejected before it even reaches the server. This can be useful if you want to prevent certain types of changes from ever entering your repository, but it requires you to have administrative access to the server. On the other hand, when you use a GitHub action, the check is performed on the client-side, which means that the commit is allowed to be pushed to the server but the action will run and fail if the commit does not meet the specified requirements. This can be useful if you want to provide more specific feedback to the user about why their commit was rejected and it also allows for a more granular control over the workflow of your repository. In general, the choice of whether to use a server-side pre-receive hook or a client-side GitHub action will depend on your specific use case and requirements. Server sideI think it's possible to do it using Git Hooks. Specifically, you can use a pre-receive hook to check whether the changes being committed are within the specified whitelist and reject the commit if they are not.
Here's an example command that you can use to obtain the list of modified files: git diff-index --cached --name-status HEADThis command outputs a list of modified files and their status, which you can parse to check the paths of the modified files. The output of this command is in the format: Where Should also be coupled with a check for the remote url to do it in a pre-commit hook, you can use the
Note that this is just one example of how to restrict commits to a specified whitelist, and you may need to modify the script to fit your specific needs. Additionally, you may also want to consider adding a client-side hook to prevent users from even attempting to commit changes outside of the whitelist. And it's require executable right too : Client sideTo add a client-side hook in order to prevent users from even attempting to commit changes outside of the whitelist. You can create a pre-commit hook script that runs locally on the user's machine. This hook script will be triggered whenever the user runs the git commit command, and can check whether the changes being committed are within the specified whitelist. To do it you will need to do a change on git inside
# To enable this hook, rename this file to "pre-commit".
By the way the file should be the same than the server-side version #!/bin/bash
# Specify the path to the file containing the whitelist of allowed repository paths
whitelist_file=".allowed_repos"
# Read the whitelist of allowed repository paths from the file
whitelist=()
while read -r line; do
whitelist+=("$line")
done < "$whitelist_file"
# Loop through the modified files and check their paths
while read old_revision new_revision file_path; do
# Check if the file path is within an allowed repository path
allowed=false
for path in "${whitelist[@]}"; do
if [[ "$file_path" == "$path"* ]]; then
allowed=true
break
fi
done
if ! $allowed; then
echo "ERROR: You are only allowed to commit changes to the following repositories: ${whitelist[@]}"
exit 1
fi
done < <(git diff-index --cached --name-status HEAD)
# Specify the path to the file containing allowed remote repository URLs
allowed_urls_file=".allowed-urls"
# Read the whitelist of allowed repository paths from the file
allowed_urls=()
while read -r line; do
allowed_urls+=("$line")
done < "$allowed_urls_file"
# Get the URL of the remote repository being pushed to
remote_url=$(git remote show origin | grep "Push URL" | awk '{print $3}')
# Read the list of allowed URLs from the file and check if the remote repository is allowed
for url in "${allowed_urls[@]}"; do
if [[ "$remote_url" == "$url" ]]; then
exit 0 # Allowed URL found, exit with success
fi
done
# If we reach this point, the remote repository is not allowed
echo "You are not allowed to push changes to this repository."
exit 1
The idea is to do this change on the version of git that the user can download on him device. This script is similar to the server-side pre-commit hook script, but it runs locally on the user's machine. When the user runs the git commit command, this script will be triggered and will check whether the changes being committed are within the specified whitelist of repositories. Note that this client-side hook will only be effective if users do not modify or disable it. Therefore, it's important to communicate to your team that this hook is in place and why it's important for your development process. Also this could be modified to match more url using prevent commit from a private repository to a public repositoryclient sideThere is also similar method to prevent commit from a private repository to a public repository for example : #!/bin/bash
# Get the Git remote URL of the repository where the file is coming from
remote_url=$(git config --get remote.origin.url)
# Check if the remote URL is a private repository
if [[ "$remote_url" == "[email protected]:mycompany"* ]]; then
# Check if the current repository is a public repository
if [[ $(git config core.bare) == "false" && $(git config core.sharedrepository) != "1" ]]; then
echo "ERROR: You cannot commit files from a private repository to a public repository"
exit 1
fi
fi
server sideyou can use a pre-receive hook that checks whether a file being pushed to the server is coming from a private repository.
#!/bin/bash
# Loop through the modified files and check if they are coming from a private repository
while read old_revision new_revision ref_name; do
for file_path in $(git diff --name-only $old_revision $new_revision); do
# Check if the file is coming from a private repository
if git log --format=%h -- $file_path | grep -q private-repo.git; then
# Check if the commit is being pushed to a public repository
if [[ $(git config core.bare) == "true" || $(git config core.sharedrepository) != "0" ]]; then
echo "ERROR: You cannot push changes to a public repository when the modified file is coming from a private repository"
exit 1
fi
fi
done
doneThis code will checks if a file being pushed is coming from a private repository by searching the Git log history for the file path and checking if it contains the name of the private repository. If the file is coming from a private repository and the commit is being pushed to a public repository (i.e., a bare repository or a shared repository), the hook will reject the commit.
This is what I find about the subject, hope this could help |
Beta Was this translation helpful? Give feedback.
-
Question raised via TODO Slack Channel
Question for some other OSPO folks who may have dealt with a similar situation in their company:
Our security folks want to implement a change to a DLP agent on our company-issued computers to block our engineers from creating new repos on github.com or even doing pushes to repos on github.com that aren't in a list of 'allowed' orgs/repos (i.e. all of our existing enterprise orgs/repos). The theory is that this will prevent accidental exfiltration of company proprietary source code to public spaces or spaces on github.com not controlled by our company.
Obviously, I strongly disagree with this approach, and we're looking for legitimate use cases where this activity should still be executed. What we've come up with so far is:
Am I missing any other use cases?
Beta Was this translation helpful? Give feedback.
All reactions