Why secrets like API keys in Git are such a problem(blog.gitguardian.com)
blog.gitguardian.com
Why secrets like API keys in Git are such a problem
https://blog.gitguardian.com/secrets-credentials-api-git/
3 comments
My perspective on this is that it conflates two valid concerns, and comes to a valid proposed solution. However I criticize this solution, because it doesn't actually address the underlying issues, which I think it conflates:
* popular source code repository tools present unnecessary risks for closed-source environments
* source code repository tools don't have fine-grained access controls
One issue is that github specifically is ill-suited for the purpose of closed-source, proprietary, company-controlled source-code. The FTC analysis about Uber that's linked in this blog post, articulates this: "Uber granted its engineers access to Uber’s GitHub repositories through engineers’ individual GitHub accounts, which engineers generally accessed through personal email addresses."
Few other company tools are inherently used with personal accounts. Few other company tools so flagrantly violate isolation of tenants. Few other tools make it so goddamn easy to accidentally publish private information. The idea that company source code should reside on the same platform as open-source code is insane from a security perspective. The idea that there's a public API to crawl all repositories (that were made public) on the same platform where many companies are keeping their proprietary code is even more insane. Github is caught between two identities: Their open-source past, and their popularity with smb and enterprise customers.
I always notice this complete disaster when managing access and adding a contributor to the repository, and the search-space from which I can select a contributor is EVERYONE EVER REGISTERED ON GITHUB. How is this supposed to be a tool being used by companies the size of Uber. You're one wrong click away from giving people outside of your organization access to your source-code. The answer can't be "well let's just not put the really sensitive things in there and call it a day."
Would I be comfortable adding my credit card numbers to the company repository? No, but the issue is access control, not security. If you put a password in a company managed password manager where all team members can access this item, and then subsequently move it to a private vault, you better change that password. A version control system just amplifies this risk (due to its history,) it doesn't inherently present it in a way that other shared systems don't.
It seems bizarre, the degree to which companies are fine with this absolutely inappropriate tooling for the required security.
* popular source code repository tools present unnecessary risks for closed-source environments
* source code repository tools don't have fine-grained access controls
One issue is that github specifically is ill-suited for the purpose of closed-source, proprietary, company-controlled source-code. The FTC analysis about Uber that's linked in this blog post, articulates this: "Uber granted its engineers access to Uber’s GitHub repositories through engineers’ individual GitHub accounts, which engineers generally accessed through personal email addresses."
Few other company tools are inherently used with personal accounts. Few other company tools so flagrantly violate isolation of tenants. Few other tools make it so goddamn easy to accidentally publish private information. The idea that company source code should reside on the same platform as open-source code is insane from a security perspective. The idea that there's a public API to crawl all repositories (that were made public) on the same platform where many companies are keeping their proprietary code is even more insane. Github is caught between two identities: Their open-source past, and their popularity with smb and enterprise customers.
I always notice this complete disaster when managing access and adding a contributor to the repository, and the search-space from which I can select a contributor is EVERYONE EVER REGISTERED ON GITHUB. How is this supposed to be a tool being used by companies the size of Uber. You're one wrong click away from giving people outside of your organization access to your source-code. The answer can't be "well let's just not put the really sensitive things in there and call it a day."
Would I be comfortable adding my credit card numbers to the company repository? No, but the issue is access control, not security. If you put a password in a company managed password manager where all team members can access this item, and then subsequently move it to a private vault, you better change that password. A version control system just amplifies this risk (due to its history,) it doesn't inherently present it in a way that other shared systems don't.
It seems bizarre, the degree to which companies are fine with this absolutely inappropriate tooling for the required security.
I think that you are missing a scenario: private (but not necessarily closed source) deployments of open source code.
Even if those deployments to AWS or other cloud environments are only for testing purposes as part of the normal development process of the open source code, there are still opportunities for secrets to leak, and would be even if the cloud platform itself were open source.
Even if those deployments to AWS or other cloud environments are only for testing purposes as part of the normal development process of the open source code, there are still opportunities for secrets to leak, and would be even if the cloud platform itself were open source.
Even if those deployments to AWS or other cloud environments are only for testing purposes as part of the normal development process of the open source code, there are still opportunities for secrets to leak, and would be even if the cloud platform itself were open source.