生成式 AI對資安的威脅與機遇

課程概要

分析生成式 AI 在資安領域的應用，以及近期相關資安事件，並探討如何有效利用 AI 增強安全性，同時應對其帶來的新挑戰。

課程大綱

1. 生成式 AI 在資安中的應用與挑戰

生成式 AI 的基本概念

生成式 AI 在資安中的具體應用

生成式 AI 帶來的潛在風險與挑戰

2. 近期生成式 AI 相關的資安事件

近期生成式 AI 資安事件概述

事件分析與影響評估

從事件中學到的教訓

3. 應對生成式 AI 帶來的新挑戰與增強資安的策略

生成式 AI 資安風險管理策略

利用 AI 增強資安的技術與方法

未來發展趨勢與應對措施

3. 結論

資訊安全守則 - 2022/08/08

• 使用防毒軟體並定期更新病毒碼及掃毒。
• 時時修補作業系統、應用軟體的安全性更新。
• 勿使用太簡單或易被猜測之密碼，並請定期更新密碼。
• 重要的資料，應定時做好離線備份(最好備份到其他電腦系統、雲端儲存或自備隨身硬碟等)。
• 不下載/安裝/執行來路不明的程式。
• 勿開啟、點閱來路不明的電子郵件及隨便點選郵件內的連結及開啟可疑郵件附檔。

TP公司資通安全推動小組設置要點

TP公司資通安全推動小組設置要點

中華民國109年2月17日昕字第10902170002函頒

一、TP公司（以下簡稱本公司）為配合資通安全管理法施行，積極推動本公司資通安全政策及資通安全維護作業，特設TP公司資通安全推動小組（以下簡稱本小組）。

二、本小組置召集人一人，由本公司 總經理(資通安全長)兼任，負責推動、協調及督導本公司資通安全管理業務；執行秘書一人，由本公司 副總經理兼任，承召集人之命，綜理本小組有關業務；本小組委員由本公司單位主管擔任委員。
本小組職掌如下：

(一)資通安全管理政策及目標之核定。

(二)資通安全維護計畫之核定。

(三)資通安全維護計畫實施情形之核定。

(四)資通安全責任等級之核定。

(五)其他資通安全事項之核定。

三、本小組下設行政營運管理分組、業務發展管理分組、產品開發管理分組三個分組，主、協辦單位及職掌如下：

(一)行政營運管理分組：
規劃與推動本公司行政營運管理相關業務，主辦單位為本公司管理處，其職掌如下：

1.資通安全政策及目標之規劃。

2.資通安全維護計畫之規劃及執行。

3.資通安全維護計畫實施情形之督導。

4.資通安全事件之檢討及監督。

5.資通安全責任等級之審查。

6資通安全稽核計畫之規劃及執行。

7.資通安全稽核結果之管考。

8.其他資通安全事項之規劃與推動。

(二)業務發展管理分組：
規劃與推動本公司轄管業務發展管理之資通安全相關業務，主辦單位為本公司業務處，其職掌如下：

1.資通安全政策及目標之規劃。

2.資通安全維護計畫之規劃。

3.資通安全維護計畫實施情形之督導。

4.資通安全事件之檢討及監督。

5.資通安全責任等級之審查。

6.資通安全稽核計畫之規劃及執行。

7.資通安全稽核結果之管考。

8.關鍵基礎設施提供者指定程序之規劃及辦理。

9.關鍵基礎設施之資通系統防護基準之規劃。

10.其他資通安全事項之規劃與推動。

(三)產品開發管理：
規劃與推動本公司業務發展管理相關業務，主辦單位為本公司產品開發管理處，其職掌如下：

1.資通安全政策及目標之規劃。

2.資通安全維護計畫之規劃。

3.資通安全維護計畫實施情形之督導。

4.資通安全事件之檢討及監督。

5.資通安全責任等級之審查。

6.資通安全稽核計畫之規劃。

7.資通安全稽核結果之管考。

8.其他資通安全事項之規劃與推動。

四、本小組每年召開會議二次；必要時，得召開臨時會議。
前項會議由召集人召集之，並擔任主席；如召集人因事不能出席時，由執行秘書代理之。

五、本小組幕僚作業由本公司資訊處負責辦理，各分組之幕僚作業由各分組主辦單位負責辦理。

六、本小組執行業務所需經費，由本公司編列預算支應。

TP公司資通安全政策

TP公司資通安全政策

中華民國109年2月17日昕字第10902170001函頒

一、目的
為增進TP公司(以下簡稱本公司)資通訊作業安全及穩定之運作，提供可信賴之資通訊服務與產品，確保資訊資產之機密性、完整性及可用性，並順利推展本公司各項業務，以符合資通安全管理法及其子法之規範，特制定TP公司資通安全政策(以下簡稱本政策)做為本公司資通安全管理最高指導方針。

二、範圍
本政策適用於本公司同仁、接觸本公司業務資訊或提供服務之廠商及第三方人員。

三、目標

(一)確保本公司業務相關資訊之機密性，保障公司機密與客戶資料。

(二)確保本公司業務相關資訊之完整性及可用性，提高行政效能與品質。

(三)配合本公司及本政策之推動，提昇資通安全防護能力。

(四)符合國家法令與本公司之規範，達成業務持續運作之目標。

四、策略

(一)應考量相關法律規章及營運要求，評估資通訊作業安全需求，建立相關程序，以確保資訊資產之機密性、完整性及可用性。

(二)建立本公司資通安全組織並訂定分工權責，以利推行資通安全作業。

(三)依資通安全責任等級分級辦法之規定執行各項應辦事項。

(四)建立資通安全事件通報應變機制，以確保資安事件妥善回應、控制及處理。

(五)定期執行資通安全稽核作業，以確保資通安全管理落實執行。

五、審查
本政策由資安長核定，每年至少評估兩次，或於組織有重大變更時（如組織調整、業務重大異動等）重新評估。依評估結果、相關法令、技術及業務等最新發展現況，予以適當修訂。

2020 資訊安全要求

為建立資安防護機制，引導產業建立資安防護認知與制度，以保障我國製造業重要生產資訊，並提升製造業資安防護能量，本計畫資訊安全要求如下。
先期顧問規劃案：
須盤點提案廠商與供應鏈間之資訊安全之現況，包含網路、應用及設備層的軟硬體，並進行問題分析與提出最佳調整方案之建議，需含教育訓練、機制建立、系統導入、導入後查驗、資安架構圖等規劃。
系統建置導入案：
須盤點提案廠商與供應鏈間之資訊安全之現況，包含網路、應用及設備層的軟硬體，並進行問題分析與提出最佳調整方案之建議，需含教育訓練、機制建立、軟硬體系統採購、系統導入、導入後查驗、資安架構圖，且建置及導入35%以上應為國內業者產品及服務，計畫驗收至少須達壹、必要要求之條件。並另敘明：

1. 資訊安全組織：請指派公司之專責人員負責資訊安全計畫、執行、查核及改善，並由管理階層指派高階人員負責協調專案資源。
2. 資訊安全計畫：請規劃資訊安全風險評估，可透過但不限於第三方單位執行原始碼檢測、黑箱檢測、滲透測試等，並針對重大威脅及脆弱性必須規劃資安防護解決方案。

壹、 必要要求

一、 企業網路層之安全要求

1. 企業網路層、監控層及管理層之間，以及各層對外網路，採用資安防護設備，強化網路管控。
   1.1. 各層之間與各層對外網路應使用資安防護設備，包含但不限於IPS、VPN、URL Filter及APT偵測等。
2. 針對USB 裝置進行管理與惡意程式掃描。
   2.1. 各層對外網路應使用資安防護設備，功能包含但不限於IPS、VPN、URL Filter及APT偵測等。USB裝置除了不應提供自動執行功能外，設備開機時亦不可由USB裝置啟動。
   2.2. 未經單位允許之USB設備及存放於該設備之程式與資料不應被啟動，且需定期針對設備進行惡意程式掃描。
3. 具備日誌與稽核機制，且須存查至少N+0.5年。
   3.1. 須具備事件記錄功能，確實記錄系統運作行為，得以提供發生異常時之事件檢視、查核未授權或異常的操作。其內容須包含完整時間戳記、使用者身份及操作行為等，且須至少保存N+0.5年之紀錄供後續查閱之用。
4. 各網路、系統、設備於上線前，須經過弱點掃描確認，不可存在高風險等級之安全弱點。
5. 行動應用App須符合「行動應用App基本資安規範」之安全要求，並經合格實驗室測試通過。
6. 影像監控系統須符合「影像監控系統資安標準」之安全要求，並經合格實驗室測試通過。

二、 監控與管理層資訊安全要求

1. 各個主機安裝資訊安全防護軟體。
   1.1. 各個主機應安裝資訊安全防護軟體，包含但不限於防毒軟體與惡意程式防護軟體。
2. 採用白名單管控方式如下：
   2.1. 建立作業系統控管執行程式白名單
   2.2. 建立連線控管白名單
3. 具備日誌與稽核機制，且存查至少N+0.5年。
   3.1. 須具備事件記錄功能，確實記錄系統運作行為，得以提供發生異常時之事件檢視、查核未授權或異常的操作。其內容須包含完整時間戳記、使用者身份及操作行為等，且須至少保存N+0.5年之紀錄供後續查閱之用。
4. 建立安全的軟/韌體與組態更新機制。
   4.1. 更新方式
   4.1.1. 離線手動更新
   更新檔須加密保護以確保機密，且須採用FIPS 140-2 Annex A所核可之加密演算法，抑或是須於產品之身份鑑別因子、加解密用之金鑰(不含非對稱加解密用之公鑰)及敏感性資料，不應出現於軟/韌體之程式碼與安裝檔內其它檔案中。
   4.1.2. 線上更新須驗證下載來源，且其更新路徑須通過安全通道，且安全通道須使用SSL/TLS，同時金鑰交換協議應支援前向安全功能(Forward Secrecy)。
   4.2. 更新前必須驗證軟/韌體之正確性及完整性的功能。
   4.3. 支援備援更新功能，即發生更新失敗時，系統能回復正常運作。

三、 控制層資訊安全要求

建立軟/韌體與組態更新機制。

四、 實體層資訊安全要求

1. 遵循國際通用規範或原廠規格的通訊協定存取資料。
   1.1. 自行發展之通訊協定與實作恐造成後續維護之困難性，稽核人員將查核受稽單位選擇之理由及日後維護之能力，並確認相關設計資料之保存機制。

五、 備份機制要求

1. 程式碼與設定檔須定期備份。
   1.1. 開發過程應遵循安全開發流程。
   1.2. 根據資安政策制定備份流程與週期。
2. 資料分級後，重要資料定期備份。
   2.3. 依據資料用途進行風險評估，並設定風險等級。
   2.4. 風險等級高之重要資料，應依據資安政策定期進行備份。

六、 加解密認證安全建議

1. 若使用密碼管理，須有以下機制：
   • 更改初始密碼
   • 要求密碼強度
   • 密碼失效鎖定機制
   • 密碼加密保存
   • 密碼定期更改
     1.1. 以密碼進行身分鑑別已被認定為不安全之作法，宜避免繼續使用密碼鑑別。若情非得已，應述明理由，且規劃長期汰換計畫，短期應另有控制措施，以避免密碼遭竊外洩，造成身分鑑別功能喪失之風險。

貳、中階要求(非必要項目，由提案廠商視需要導入)

一、 企業網路層之安全要求

1. 在企業網路層安全防護架構或措施，參考如下：
   • IPS (介於IT與OT環境)
   • Secure Tunnel VPN (介於IT與OT環境)
   • 裝置網路能見度管理(介於IT與OT環境)
   • IP白名單(介於IT與OT環境)
   • 惡意程式掃描
   • 垃圾郵件掃描
   • URL過濾
   • APT偵測
   • 重要的資料視設備之環境及安全要求等級決定各種資料加密演算法強度及金鑰儲存方式
   • 針對外部伺服器請採用Webtrust SSL憑證
   • 伺服器端受資安防護設備保護
   • 系統特權帳號管理，特權帳號僅授予執行業務及職務所必要為限
   • 系統特權帳號存取，系統均留有完整紀錄
   • 提供自動異常偵測機制，發送告警通知，並產出稽核報表
   • 智慧手機具有足夠的演算能力，登入採用雙因子認證機制
2. 企業網路層與其他廠區之網路連線，參考如下：
   • 資料傳輸建立安全的加密通道
   • 遠端連線應透過加密通道，登入系統採用安全的身分鑑別機制
   • 避免使用專屬網路協定，若有其必要且不可取代性，請另行表述
   • 僅開放網路連線必要之服務與連接埠，其餘皆關閉

二、 監控與管理層資訊安全要求

1. 建立校時機制。
2. 須建置NTP伺服器，維持設備時間一致性與系統日誌時間正確性，以確保鐘訊同步。
3. 建立防毒軟體版本及病毒碼更新機制。
   3.1. 防毒軟體與病毒碼更新機制應包含版本檢查更新、確認更新來源、安裝更新、移除已安裝更新及更新失敗回復，共5個流程。
4. 採標準的安全加解密機制。
   4.1. 加解密機制應採用尚未被破解且已具強固加密等級之加密技術，可參考FIPS 140-2 Annex A所核可之加密演算法。
5. 建作之機制立當監控管理設備遺失或脫管時，可立即阻斷與防止再操作。
   5.1. 建立信任監控管理裝置列表與雙重認證註冊機制，以白名單方式進行設備存取管控。
   5.2. 設置各別裝置可存取位址來源之管制措施。
   5.3. 設備註冊後預建議載入代理軟體(Agent)，可透過遠端派送命令或更新至受管制設備，使其可鎖定、註銷及移除相關監控內容與功能。

三、 實體層資訊安全要求

1. 若透過外加模組方式存取資料，請提供所採用的通訊協定及設備認證相關資料。
   1.1. 通訊方法通常可透過外加模組方式添加新通訊方式。稽核人員將確認受稽單位選用外加模組之設計能力、維護能力與第三方供應商管理能力，並稽核受稽單位是否理解其通訊堆疊之實作方式與內建之協定、是否開啟適當之通訊加密功能、是否具備軟韌體更新機制與是否存有硬體後門，並確認廠商其產品安全應變機制，以界定受稽單位其資安規劃能力可達到中階要求，高於行業水準。

四、 加解密認證安全建議

1. 針對資訊系統的重要性進行分級。
   1.1. 利用威脅建模方法論，盤點風險，分類系統等級，並產生應對措施與投入資源。
   1.2. 資訊系統之重要性應以業務目標相互契合，將資安問題作為一個商業風險問題而非技術問題，並取得關係人上下一致共識。
   1.3. 由於無法完全遏止所有資安事件發生，建議受稽單位能明智地接受一些風險，利用持續觀測之數據證明，部分風險是可接受的，且不致造成業務發展之阻礙。稽核人員將查核受稽單位之各項管制作為。
   1.4. 以CIS controls top 20為查核基準，並查核是否有用預設值直接上線使用情事發生。
2. 關鍵系統採用尚未被破解且具強健加密等級的加密技術。
   2.1. 關鍵系統其身分鑑別、資料倉儲與通訊傳輸應該利用強建等級之密碼學技術搭配管制措施加以保護，強健性以美國NIST、德國BSI或ECRYPT-CSA最新建議皆可接受，須建立與時俱進之機制，提出如何與世界密碼如何與世界密碼研究進度保持同步(如sha1碰撞該如何應變)之說明。
3. 一般系統採用適當安全等級之加密技術。
   3.1. 一般系統雖不影響業務目標，但也應考慮成本效益比相當合適之加密技術與管制措施，以確保身分鑑別、資料倉儲與通訊傳輸三項功能安全。

參、進階要求(非必要項目，由提案廠商視需要導入)

一、 企業網路層之安全要求

1. 定期執行滲透測試。
   1.1. 企業網路層的資訊設備應定期執行滲透測試，以提升安全性，建議至少半年執行乙次。滲透測試執行後若發現漏洞，必須執行漏洞修補，並出示相關紀錄或報告，以確保企業網路層之資訊設備安全。
   1.2. 各網路、系統於上線後，應定期(至少每半年)執行弱點掃描，可存在高風險等級之安全弱點。
   1.3. 各網路、系統於上線後，應定期(至少每年)須經過第三方單位滲透測試確認，不可存在高風險等級之安全弱點。

二、 監控與管理層資訊安全要求

1. 採用工控協定防火牆進行指令過濾或進行流量偵測分析(如：Port Mirror)。
   1.1. 工控協定防火牆應能支援各種多元化的通訊協定標準，以確保工控指令或資料封包之合法性。
2. 若設備採用金鑰管控，請導入金鑰管理機制。
   2.1. 金鑰管理機制的基本條件至少須完成金鑰生命週期之每個功能項。
3. 工控協定防火牆於上線前，須經過第三方單位滲透測試。
   3.1. 不可存在高風險等級之安全弱點。
   3.2. 針對中風險等級之安全弱點，須提出補償措施。

三、 控制層資訊安全要求

1. 應建立軟/韌體安全更新機制。
   1.1. 建立安全更新機制，以確保軟/韌體完整性，可達到系統安全啟動與安全功能檢查，防止被植入惡意程式。

四、 加解密認證安全建議

1. 安全要求較高的設備或服務，採用雙因子認證、生物識別等功能。
   1.1. 採雙因子、生物識別等憑證方式可避免人為選擇密碼之缺失。原則上不允許未經外界檢驗而自行實作之機制，特別是認證套件與整合實作。
2. 導入安全的金鑰管理機制(包含金鑰產生、儲存、使用、備份、銷毀、更新、復原及稽核等，且金鑰具備可供稽核的安全存放及使用歷程紀錄的機制)，避免被竊取或盜用。
   2.1. 若未採業界認可之金鑰管理產品，而採自行開發方式，則受稽單位應提出其設計與實作之安全性證明，至少包含密鑰、證書、協議參數配置、加密套件參數配置、伺服器架構與參數配置，搭配常見實作之問題(如證書校驗缺陷、隨機數生成方式、降級攻擊、截斷攻擊、部署弱點、協議攻擊、性能下降與DoS攻擊)應具安全性之實作與管理。
3. 若採用對稱式金鑰，請另採用非對稱金鑰加以保護。
   3.1. 對稱式金鑰缺點在於雙方共享同一密鑰，故無法用於身分鑑別與不可否認性，須另有機制進行保護。受稽單位應提出完整之設計機制與風險論述，同時實作過程與細節可被檢驗，至少包含密鑰、證書、協議參數配置、加密套件參數配置、伺服器架構與參數配置，搭配常見實作之問題(如證書校驗缺陷、隨機數生成方式、降級攻擊、截斷攻擊、部署弱點、協議攻擊、性能下降與DoS攻擊)應具安全性之實作與管理
4. 軟/軔體更新時使用電子簽章技術以驗證資料的正確性與完整性。
   4.1該電子簽章技術應用於軟/韌體更新應具備完善機制，包含可信任根、被檢驗過之演算法實作等。原則上，不接受未經外界檢驗而自行實作之機制，特別是加密套件與整合實作。

如何保護你的的程式源碼 ?

• 保護代碼這件事挺重要的

當像Equifax這樣的重要公司的敏感數據洩露成為頭條新聞時，數百萬的消費者立即意識到他們現在是受害者。 故事總是關於竊取的數據以及公司試圖掩蓋漏洞的戲劇性事件。 但是數據洩露是安全失敗的結果。 

如此嚴重的安全漏洞的真正原因是什麼？


通常，敏感數據會通過不安全的源代碼來洩露。 這就是故事中的故事，這個引人入勝的故事很少講。 即使在最大和最熟悉的公司（如Uber）內，此類故障也經常發生。 安全性故障甚至發生在OneLogin等專門從事安全性的公司內部，但是我們很少聽到為什麼會發生這些故障。

通常，敏感數據會通過不安全的源代碼來洩露。 這就是故事中的故事，這個引人入勝的故事很少講。

之所以如此，部分是因為源代碼漏洞是高度技術性的。 正如我們將看到的，這是我們無法避免的一個問題，因為它是“技術性成分太多”。
但是，我們沒有聽到有關安全失敗原因的更為惡毒的原因：如果公司透露其軟件缺乏重要的安全功能，那麼他們很快就會失去客戶的信心。 因此，雅虎和其他公司多年來一直故意隱瞞安全漏洞。
我們將發現這些安全漏洞的根源是源代碼本身。 在本文中，我們將探討源代碼存儲庫（如Git和Apache Subversion）的安全漏洞。 我們還將討論包括源代碼掃描在內的各種解決方案。 讓我們從一些最近的安全性故障開始，並找出共同點。

• 新聞事件

2016年底，總共有5700萬Uber用戶和駕駛員成為近期歷史上最大的數據洩露事件之一的受害者。1兩名黑客利用個人信息（包括電話號碼，姓名和電子郵件地址）偷走了。 然而，更糟糕的是，該公司掩蓋了超過一年的時間。 解決與掩蓋相關的索賠將使Uber損失1.48億美元。

這個故事太普遍了。 把相同發生在“ Uber”上轉換到任何組織或公司，會看到相同的故事。這樣的故事不斷提醒我們增加基於Web的自身安全預防措施。

公司尋求通過加強強大的密碼創建來增強信心；有些甚至使用強大的密碼生成器。 更嚴厲的措施包括使用兩因素甚至多因素身份驗證。 除了傳統的硬件令牌或密鑰卡以外，這可能還涉及通過SMS發送到您的電子郵件地址的動態PIN碼。 鑑於這種增強的安全性，為什麼我們繼續聽到Uber和其他公司的數百萬消費者的隱私受到損害？

荒謬而又真實的答案是，壞演員常常不做任何事情。 最具破壞力的“黑客”僅比意外發現未加密文件中的密碼要聰明得多，該文件位於可索引的Web目錄或Amazon S3 Bucket中！ 這就是Uber發生的情況，我們將更深入地研究攻擊者如何通過版本控制平台和Git和Subversion等代碼存儲庫中的漏洞來訪問登錄憑據。

以另一個影響超過1.48億消費者的重大違規事件為例：對消費者信貸報告機構Equifax的違規行為。

對Equifax的大規模攻擊利用了另一種流行的針對分佈式計算應用程序的開發工具Apache Struts。 Apache以生產高質量且廣受歡迎的開源開發人員工具而聞名。 但是，Apache Struts有很多已知的安全問題。 當前，一個開發人員論壇維護著72個已知的安全問題的帖子(issue)！ 這些安全漏洞的範圍遠非中等，它涵蓋了拒絕服務和遠程代碼執行攻擊，這些攻擊可能削弱企業電子商務平台。

這提示了一個最明顯的問題：如果Apache Struts已知安全問題，為什麼Equifax使用它？ 人們普遍說，Equifax在利用這些安全問題之前就已經知道了這些安全問題，但是Equifax並未採取任何有意採取的行動來解決這些問題。 為什麼？ 要了解在此類常用軟件中處理已知錯誤和攻擊媒介的問題，我們必須探索問題的技術方面。

即使僅關注數據安全性的公司也不例外。 例如，一家以網絡安全為中心的公司OneLogin遭到了攻擊。 這個特定的故事與我們此處的預期目的最接近：盜竊API密鑰和OAuth令牌。

儘管OneLogin沒有透露攻擊的詳細信息，但是他們向客戶提出的關於保護進一步入侵的建議間接揭示了潛在的入侵點。

開發人員用於自動登錄的登錄憑據（API密鑰和OAuth令牌）通常未加密存儲在Shell腳本5中，甚至可能顯示在日誌文件中。

但是公司在解決這個特定問題時面臨著巨大的挑戰：開發人員和敏捷團隊渴望精簡的連續部署管道在必須完全確保身份驗證憑據安全的情況下很難自動進行。 可以完全做到這一點，但是需要全神貫注並不斷進行審查。 讓我們從如何以及為什麼存在這些安全漏洞開始。

一切從代碼開始

在最近的一項研究中，美國國土安全部指出90％的安全漏洞是由於代碼中的漏洞而發生的。這個簡單而有影響力的統計數據應該足以促使從開發人員到CISO的每個人都開始考慮評估自己與代碼有關的安全性實踐。要查找的第一個也是最重要的地方是代碼存儲庫內。

隨著採用和使用量的增加，源代碼存儲庫（“ repos”）逐漸被人們所理解，但是從歷史上看，它們僅主要由從事大型企業級軟件應用程序的開發人員所佔用。

這些是共享的開發人員資源。因為只有開發人員每天都在回購中工作，所以提交的源代碼不受對其他開發，測試和QA領域施加的審查。但這正是安全漏洞開始出現的地方。

另一個地方是整個版本控制。在一個複雜的Web應用程序中，多個開發人員可以在一個模塊上工作，領導者需要能夠快速測試和回滾新興代碼的便利。此功能由Apache Subversion等版本控制應用程序提供。回購和版本控制應用程序都容易出現漏洞。

普通的安全問題，例如SQL注入或跨站點腳本（XSS），是二維的，非技術人員可以通過簡單的測試方法甚至最基本的漏洞掃描工具來識別。 測試人員可以運行在Cucumber上編寫的回歸測試套件，然後報告問題，而無需了解從倉庫中觸發測試的自動生成腳本的內容，其中某些腳本實際上包含秘密訪問密鑰和令牌。

在腳本化CI管道中使用此類憑據的各種方式僅受開發人員的創造力限制。 通常，持續集成和部署（CI / CD）涉及到盡可能簡化和自動化的過程，但是掃描代碼，集成和部署過程本身並不是凡人的直接任務。

相反，必須對腳本生成的漏洞進行掃描，而不是由人員而是由機器進行漏洞掃描。 並且它們必須足夠智能才能在第一個CI觸發之前啟動。 Jenkins是一種流行的開發人員工具，它可以檢測編碼員何時向應用程序提交（“提交”）更改。 然後，Jenkins觸發一個測試套件，如果成功，它將繼續自動部署該應用程序的成功版本。 這些是CI / CD中的一些步驟，CI / CD現在是一種流行的向用戶分發新軟件的方式。

但是...

為什麼CI和CD是安全失敗的深淵？

為了實現真正的自動化開發流程，開發人員必須編寫腳本，編寫從代碼更改到應用程序部署的一系列事件。 這意味著對Web應用程序所做的任何更改都會觸發一組新的測試套件，以驗證代碼更改不會破壞應用程序的另一部分。 可以想像，要自動化Web應用程序測試，必須要有一個虛擬用戶，登錄一個帳戶，然後執行普通用戶會做的事情-可能使用新的帳戶和地址購買電視。 當我們具有前面描述的所有安全功能（例如動態PIN身份驗證）時，機器人如何登錄帳戶？ 這通常就像將明文憑證粘貼到文件中一樣簡單，甚至可能使最老練的系統管理員和開發工程師都感到恐懼。

當開發人員（通常是QA工程師）編寫自動CI管道的腳本時，他們實際上是在腳本中輸入虛擬用戶的登錄憑據。 這些腳本未經編譯或加密； 它們是在瀏覽器和服務器上執行的純文本腳本。 自動化腳本通常保存到Apache Subversion和Git之類的存儲庫中，或者在頑皮的情況下，保存在開放式Web服務器或公共GitHub本身上的可索引存儲庫中。 它們在回滾期間觸發，並通過部署管道釋放。 在提交觸發新的構建之前，必須由源代碼掃描程序檢測到這些安全漏洞。 只有這樣才能防止黑客將注意力集中在這些腳本的內容上。 經常訪問的協議，組件和庫的流程鬆懈會導致源代碼漏洞。

還記得我們的Uber示例嗎？ 他們和其他公司一樣，“經常不小心將憑據保存在上載到GitHub的源代碼中。”但這並不是偶然的，有時出於方便或開發速度的考慮，這是慣例。 擺脫不良習慣或魯ck自動化的唯一方法是自動對其進行自動掃描。

• 人為因素

令人驚訝的是，分佈式計算平台中出現的安全故障不是錯誤。 他們是疏忽大意的疏忽，提供了與未知方的聯繫。 開發人員在此失敗過程中的錯誤是一種預期。

傳統上，開發人員認為錯誤是在運行的應用程序中發生的，而不是回購中的腳本。 不安全的編碼實踐源於開發過程中的行為和習慣，這可能導致代碼中的漏洞。

如前所述，回購和版本控制平台嚴格來說是編碼人員的領域。

同樣，測試人員和質量檢查工程師通常不會將構建腳本視為正在開發的網絡應用程序的一部分。 這種觀念必須改變，但是還必須有一個增強安全性的改進平台。

• 兩位英雄之戰：安全與效率

Devops和敏捷方法非常重視極速的速度和效率，以至於開發人員承受著將快捷方式編寫腳本到軟件構建中的壓力。 當然，這會導致無法預料的後果。

如果兩個或兩個以上的開發人員在代碼的一個分支上工作，他們通常會傾向於共享憑據以簡化可見性。 儘管降低交付速度的壓力是不切實際的，但很有可能實現實施開發人員代碼安全性實踐的回購和版本控制系統。

不幸的是，不存在安全的開發人員工具。 如今，安全已被“強化”，而不是集成在其中。 由於開發人員希望快速發展，並且不希望通過附加的安全步驟來減慢速度，因此他們固有地發現在快速創新和高需求的環境中保持對安全性意識不佳的想法。

毫無疑問，公司的實質是其源代碼。新的自動傳遞管道現在暴露了一種新形式的安全漏洞。隨著任何新技術的出現，出現了一系列新的威脅。通過Web應用程序交付核心產品的企業必須將源代碼安全性視為最高優先事項。對源代碼的靜態分析可以在將應用程序部署到生產之前或在打包和交付構建之前，識別專有和開放源代碼中的漏洞。然後，檢測漏洞的基於安全的版本控制和存儲庫平台可能會中斷新版本的自動部署，直到問題得到糾正或權威團隊負責人對發行版進行身份驗證和批准為止。預防那些導致災難性的Equifax和Uber破壞的安全故障，在交付到生產中時值得一時。基於安全的開發人員工具必須在下一代編碼標準中發揮作用。

預防那些導致災難性的Equifax和Uber破壞的安全故障，暫時停產交付是非常值得的。
 基於安全的開發人員工具必須在下一代編碼標準中發揮作用。

僅此一步就可以阻止幾乎所有惡意的更改源代碼的企圖，並且可以在未經授權的訪問發生之前減輕未經授權的訪問。 最佳的基本安全實踐之一是不斷監視構建腳本是否存在潛在的安全漏洞。 自動化的源代碼清單可以完成此任務。 需要具有源代碼掃描程序的功能，該功能可以跟踪版本控制系統中的所有新分支，並在輸入密鑰和令牌時顯示警報。 如今，一些公司對公開掃描這些密鑰，然後禁用它們或通知用戶感興趣。 甚至有些人甚至為用戶提供了執行此操作的工具，例如Amazon Web Services的AWSLabs GitHub帳戶。

• 解決安全難題

1.代碼掃描

確實，當今Git回購中還需要的一項關鍵安全功能是能夠智能掃描所有源代碼並識別開發人員添加的訪問密鑰和密碼的功能。 當開發人員將秘密訪問密鑰和密碼編碼為源代碼時，估計會啟用75％的安全漏洞。

我們需要一個自動系統，該系統可以檢測腳本中的密鑰和密碼輸入並提醒團隊負責人進行審查。

** 代碼掃描器很重要

安全功能。 它可以檢測腳本中的密鑰和密碼輸入，並提醒團隊負責人進行審查。

開發人員當前使用的一種增強安全性的方法是將登錄憑據分離到“包含”文件中，以便從登錄腳本中刪除Oauth的密碼以及其他秘密密鑰和令牌。但是，這種方法取決於個人開發人員的習慣，並且破壞了協作問責制的概念。我們已經表明，鼓勵速度的devop做法也激發了編碼人員使用快捷方式的安全性。實現自動漏洞掃描和分析的平台是下一代標准開發人員安全工具，將包含在改進的存儲庫和版本控制平台中。自動化漏洞掃描使整個開發人員或敏捷團隊中的代碼安全性民主化。

基於安全的分佈式應用程序開發平台必須自動實施策略實施。換句話說，與Jenkins檢測到代碼更改的方式相同，源代碼安全系統應檢測敏感憑證或私有數據的輸入。這樣的系統將嚴格控制和審核誰有權訪問和更新源代碼。該系統將向團隊負責人提供受保護的分支機構和用戶報告，以進行緊急響應。

該系統應該具有關鍵字陷阱，並且像防病毒程序一樣工作，以在提交之前和任何觸發生成的提交之前捕獲憑據條目。

2.合規

與安全的開發人員做法並行的是採用企業級標準。 符合標準的認證對於當今Web應用程序開發的成功至關重要。 提供存儲庫和版本控制的基於雲的分佈式軟件開發平台應嚴格遵守安全服務組織控制（SOC）2審核。 此類合規性可以進一步確保健壯的源代碼安全性。 理想情況下，具有版本控制的基於安全的開發人員平台的安全協議應符合全面的審核和認證標準，以驗證合規性是質量保證和客戶隱私保護的重要層。

隱私保護框架(The Privacy Shield Framework)是由美國商務部和歐盟委員會設計的，旨在為公司提供一種在將個人數據從歐盟轉移到美國以支持跨大西洋商業時遵守數據保護要求的方式。

遵守SOC 2審核可確保客戶和合作夥伴充分利用公司的信息安全措施，並維持當今特定的雲安全要求。 源代碼安全性和數據保密性是SOC 2審核合規性不可或缺的部分。

與SOC 2認證並存的是確保隱私的幾個其他合規性標準，所有這些都應視為對源代碼安全性和總體雲數據隱私性進行驗證所必需的。 在基於雲的電子商務支付和數據安全網絡中，用於隱私實踐的PCI Level 3和Privacy Shield最重要。

雲安全聯盟STAR自我評估同樣向所有分支機構和客戶保證，基於Web的企業將維持最高標準的隱私和源代碼安全性。

數據本地化在許多轄區中也很重要，因為它可以使數據保持最接近組織的性能和控制力。 由於合規性法規（特別是GDPR）的興起，歐盟雲將特別有利於關注數據隱私，數據保護和數據本地化偏好的國際客戶。

3.使用軟件包管理保護開源軟件包

程序包是代碼和腳本的集合，這些代碼和腳本以編程方式在特定應用程序的構建中相互包含。 最終，這就是構建現代Web應用程序的方式。 它是包裝的組裝。 軟件包通常由客戶下載並集成到新的軟件產品中。 這樣的代碼包通常包含安全問題。 企業無法手動掃描其開發人員使用的每個程序包中的所有代碼，因此必須從自動漏洞掃描和審核系統中獲得巨大收益。 這樣的掃描器將充當哨兵，以保護企業免受各種創新但危險的創新的攻擊：身份驗證憑據的腳本編寫。

安全軟件包管理器對於識別源代碼中的安全漏洞至關重要。 借助MyGet等通用安全軟件包管理器，領導者可以在devops生命週期中連續控制和審核所有軟件包。 可以使用已知代碼漏洞的行業標準數據庫對所有主要語言的軟件包進行掃描，以檢查是否存在安全漏洞和漏洞。 由於開發人員工具和平台的複雜性，這種任務並非微不足道。

例如，當今使用的常見編碼語言列表很多，包括Java，.NET Framework語言（如C＃），客戶端語言（包括JavaScript）以及令人困惑的JS庫（如React，Vue，AngularJS和jQuery）。 服務器端語言包括Node.js，Ruby，Python，Perl，當然還有PHP。

基於安全性的開發人員版本控制和存儲庫平台必須具有識別和提供所有這些語言的安全漏洞警報的功能。 對於每一個，還有無數競爭的開發人員IDE和工作室。 這些現在已經發展成為低代碼平台和自動編程客戶端，這將不可避免地使該領域變得更加複雜。 代碼分析和靜態掃描是第一道防線。

• 以安全為中心的開發人員工具的新領域

如今，開發人員仍在編寫Selenium腳本，以自動進行身份驗證，以便在具有虛擬用戶的Docker容器和VM上測試新版本的應用程序。在最簡單的情況下，將密碼直接寫入未加密的文件中，以進行新的測試和發布版本。 這構成了一個頻繁且重要的安全漏洞。我們剛剛了解到，一個不安全的Docker映像註冊表公開了Aeroflot核心Web應用程序的全部源代碼。 正如我們所看到的，諸如容器化之類的完全由開發人員居住的領域現在正強烈要求進行審查，以避免災難性的數據丟失。

自動化漏洞源代碼掃描等功能現在必須成為企業應用程序開發中的標準功能。

處於壓力之下的開發人員可能會忘記：可能有40個腳本批量運行，從而構成了一個構建。例如，該批處理可以一次全部上傳到由詹金斯觸發的存儲庫。有權訪問該存儲庫的任何人都可以獲取包含身份驗證憑據的腳本！這曾經是僅限開發人員的區域。

開發人員分享帖子，以了解如何在不熟悉的情況下執行某些操作（通常會尋找捷徑）。一篇文章說明了一種使用Selenium為測試案例編寫登錄腳本的簡單方法。另一篇文章告誡開發人員這樣做！這是一個人人享有的免費區域，充滿風險。這是幾乎沒有安全保障的邊界。

持續集成交付的自動化流水線的瘋狂新領域迅速發展，並著重於速度和創新。在這種富有創造力的氛圍中，需要更加強調版本管理和存儲庫中的安全性。現在存在著以安全為中心的開發人員平台，該平台可實現所有版本控制和存儲庫工具，但具有至關重要的安全性。自動化漏洞源代碼掃描等功能現在必須成為企業應用程序開發中的標準功能。

參考文件

https://medium.com/@MentorMate/svn-git-out-of-here-how-to-choose-your-version-control-system10b44750a75c 

https://www.csoonline.com/article/2610857/security/protect-your-source-code-before-it-s-too-late.html 

https://techbeacon.com/5-ways-security-testing-teams-can-tackle-new-source-code-attacks

https://qxf2.com/blog/dont-hardcode-usernames-and-passwords-in-your-test-scripts/