Они просканировали GitHub

[@Busla]

Давайте зайдём с другой стороны: а что должно быть вместо реального токена, ключа и т.п.? — всё равно в тестах, описании, комментах будет тестовый, отозванный токен, либо его имитация вида ABCD-1234-EF56.

[@zetroot]

Выносить ключи и токены из кода в конфиги, которые подкладывать вручную в bin.
В репозитории конфиг держать без чувствительной информации, заменив токены пустыми строками, например.

[@andToxa]

Всегда было интересно, а кто где хранит боевые ключи и токены до их подкладывания вручную? Есть какие-то общие решения или каждый изобретает свой велосипед?

[@barkalov]

Кажется, нам нужен токен-репозиторий. Нужно только решить, где хранить ключи от него.

[@dartraiden]

В нашем проекте они хранятся в приватном репозитории. В коде можно встретить такое:

#include "../../../miranda-private-keys/Dropbox/secret_key.h"
…
data.AppendFormat("&client_id=%s&client_secret=%s", DROPBOX_APP_KEY, DROPBOX_API_SECRET);

Соответственно, если кто-то посторонний хочет собирать сам, он должен создать у себя локально нужную структуру каталогов и положить токен в secret_key.h:

#define DROPBOX_API_SECRET «abcdefghijklm»

[@zim32]

Можно маунтить директорию с шифрованием. Ключи один раз положил потом просто маунт

[@rework]

Мы обычно их Environment variable выносим.

[@andToxa]

Вопрос был про хранение до выноса в те же environment variables. Про обмен между членами команды.

[@aml]

Если приложение работает в Kubernetes, то можно использовать средства хранения ключей, предоставляемые платформой — Kubernetes Secrets. При этом в репозиториях ключи не хранятся от слова совсем, и один и тот же код, запускаясь в разных средах (dev, staging, prod — кто во что горазд), будет видеть разные ключи в специальном каталоге, видимом из их контейнера.

Если нужно всё по-серьёзному, с аудитом доступа к ключам, то можно использовать Google Cloud Key Management Service. Тогда собственно секреты хранятся на серверах клиентов (Google их даже не знает), но зашифрованными ключами, хранящимися в Google. Такое вот комбо.

[@missingdays]

Мы vault используем

[@missingdays]

Мы vault используем

[@Stas911]

Для AWS есть pre-commit hook — нужно просто не лениться и поставить github.com/awslabs/git-secrets

[@SerJook]

Если open-source приложение устанавливается на компьютер или другое устройство клиента, то какой смысл держать API key в тайне?

[@nochkin]

Если там ключ, который должен знать только клиент и больше никто, то странно было бы выкладывать этот ключ для всего остального мира.

[@DaneSoul]

а 81% так и не были удалены в течении срока наблюдения

Что не обязательно свидетельствует о их уязвимости — отсутствие реакции может быть обусловлено тем что:
1) Ключ изначально был не рабочим (отозван, просто случайный набор букв для примера)
2) Рабочий ключ поменяли после сообщения, а старый просто оставили в репозитории.
3) Это ключ для демо-доступа, который и должен быть всем доступен

[@Gamliel_Fishkin]

Меня удивляют люди, публикующие свой приватный ключ.

Недавно я объяснил то, что должно быть понятно без пояснений:

Полагаю, вам понятен смысл слов «приватный разговор» и «публичное заявление»: содержание приватного разговора не должно стать известно посторонним, содержание же публичного заявления должно стать известно широкому кругу людей. Разница между приватным ключом и публичным ключом такая же: приватный ключ следует спрятать и не показывать никому, а публичный ключ можно опубликовать (эти слова не случайно однокоренные).

Как можно не понимать столь самоочевидные вещи?!

[@Protos]

Уверен вы иногда вслух произносите конфиденциальную информацию, подразумевая что рядом стоящие ничего не понимают о чём идёт речь

[@nochkin]

Меня удивляет то, что это удивляет других. Ведь теория всегда ясна и понятна. На то она и теория.
Но есть ещё практика. И там есть такая штука, которая называется «человеческий фактор», «человеческая ошибка» и банальное «забыл».
Уверен, что многие ключи вышли «в свет» именно по этой причине. Например, если бы этот автор в момент публикации увидел вопрос «are you sure you want to publish your private key?», то он с уверенностью ответил бы отказом.

[@Gamliel_Fishkin]

Почему не называете компанию? Ни один человек не может знать всё, и даже знающий может ненамеренно ошибиться, но в описанной Вами ситуации имеет место воинствующее невежество.

[@Gamliel_Fishkin]

Да, с NDA не поспоришь. Будем надеяться, что исправили (грустно, если нет).