這些資料只公開了5個小時，但是這時間夠長了，足以被不法分子發現。
AWS的一名工程師無意中將與客戶往來的郵件以及「系統登錄信息（包括密碼、AWS密鑰對和私鑰）」發送到了公開的GitHub存儲庫上。
1月13日，信息安全公司UpGuard發現了一個容量為954MB的存儲庫，其中含有用於創建雲服務的AWS資源模板，以及主機名和2019年下半年生成的日誌文件，還有被標為「機密級」的內部亞馬遜培訓資源。
UpGuard今天聲稱：「幾個文檔含有各種雲服務的訪問密鑰。有多個AWS密鑰對，其中包括一個名為『rootkey.csv』的密鑰對，這表明它提供了對用戶AWS帳戶的根訪問權限。其他文件含有第三方提供商所用的一大堆驗證令牌和API密鑰。一家保險公司的一個此類文件含有消息傳遞和電子郵件提供商的密鑰。」
UpGuard繼續說：
除了與計算機系統有關的數據（比如登錄信息、日誌和代碼）外，存儲庫還含有各種文檔，這些文檔明確了所有者的身份及其與AWS之間的關係。
這些文檔包括銀行對帳單、與AWS客戶的往來信件以及包括駕駛執照的身份證明文件。多個文檔包含所有者的全名。全名完全對得起來的LinkedIn個人資料顯示，有個人在工作角色中將AWS列為其僱主，信息與該存儲庫中的數據類型相匹配。存儲庫中的其他文檔包括AWS人員的培訓信息以及被標為「亞馬遜機密」的文檔。
從這些證據來看，UpGuard確信數據源自AWS的一名工程師。
發現信息泄露幾小時後，UpGuard通知了AWS安全團隊，該存儲庫隨即下線。存儲庫公開時間不到5個小時。然而，正如UpGuard引用北卡羅來納州立大學的這篇論文（https://www.ndss-symposium.org/wp-content/uploads/2019/02/ndss2019_04B-3_Meli_paper.pdf）所特別指出的那樣，有多個方法可以通過GitHub的搜索功能迅速發現此類意外事件。
UpGuard說：「你能夠實時發現剛提交的含有機密信息的文件中99%的內容。」這些研究人員認為，「每天都有成千上萬新的獨特機密信息被泄露」。這意味著，即使泄露5個小時，這時間也足以讓犯罪分子獲取機密信息。
為什麼這麼多的機密信息最終出現在GitHub存儲庫中？一個常見的原因是，嘗試一些新想法的開發人員將登錄信息硬編碼到應用程式中，然後在未認真考慮影響或後果的情況下發布了代碼，或者忘了自己發布到公開的存儲庫上。
這個問題非常普遍，GitHub現在有一項令牌掃描服務，該服務會搜索「公開的存儲庫，查找已知的令牌格式，以防止意外提交的登錄信息被欺詐性使用。」
GitHub還建議「應將GitHub發送給你的任何令牌視作公開、已受危及的消息。」
然而就本文這起事件而言，UpGuard特別指出，存儲庫「設計成常規存儲區而不是應用程式代碼，頂層目錄中有許多文件，子目錄沒有明確的約定。」為什麼這出現在GitHub存儲庫中？原因不得而知，有可能是錯誤的腳本，也可能是有人試圖像Dropbox那樣使用GitHub用於交換或備份文件。
UpGuard特別指出：「沒有證據表明該用戶存在惡意行為或最終用戶的任何個人數據已受到影響，一方面是由於UpGuard及時發現了數據，隨後AWS迅速修復了問題。」
GitHub是不是使搜索存儲庫以尋找密碼和訪問令牌變得太容易了？GitHub是不是應該在令牌出現在公共存儲庫中之前而不是之後掃描令牌？是不是應該像微軟似乎已經所做的那樣，對來自內部日誌和支持數據的此類數據加以修改，以防萬一？
亞馬遜發言人告訴我們，那名工程師私下使用了核心存儲庫，聲稱沒有任何客戶數據或公司系統因此泄露。