Most Stupid Password 2019

No .     Password .                                         Count .
----------------------------------------------------

1.

12345

2812220

2.

123456

2485216

3.

123456789

1052268

4.

test1

993756

5.

password

830846

6.

12345678

512560

7.

zinch

483443

8.

g_czechout

372278

9.

asdf

359520

10.

qwerty

348762

11.

1234567890

329341

12.

1234567

261610

13.

Aa123456.

212903

14.

iloveyou

171657

15.

1234

169683

16.

abc123

150977

17.

111111

148079

18.

123123

145365

19.

dubsmash

144104

20.

test

139624

21.

princess

122658

22.

qwertyuiop

116273

23.

sunshine

107202

24.

BvtTest123

106991

25.

11111

104395

26.

ashley

94557

27.

00000

92927

28.

000000

92330

29.

password1

92009

30.

monkey

86404

31.

livetest

83677

32.

55555

83004

33.

soccer

80159

34.

charlie

78914

35.

asdfghjkl

77360

36.

654321

76498

37.

family

76007

38.

michael

71035

39.

123321

69727

40.

football

68495

41.

baseball

67981

42.

q1w2e3r4t5y6

66586

43.

nicole

64992

44.

jessica

63498

45.

purple

62709

46.

shadow

62592

47.

hannah

62394

48.

chocolate

62325

49.

michelle

61873

50.

daniel

61643

51.

maggie

61445

52.

qwerty123

59782

53.

hello

59125

54.

112233

58745

55.

jordan

58698

56.

tigger

57167

57.

666666

56801

58.

987654321

56653

59.

superman

56113

60.

12345678910

55414

61.

summer

55403

62.

1q2w3e4r5t

55318

63.

fitness

55095

64.

bailey

54405

65.

zxcvbnm

53307

66.

fuckyou

52997

67.

121212

52684

68.

buster

51495

69.

butterfly

51413

70.

dragon

50640

71.

jennifer

50602

72.

amanda

50560

73.

justin

50294

74.

cookie

49712

75.

basketball

49556

76.

shopping

49085

77.

pepper

48564

78.

joshua

48230

79.

hunter

47430

80.

ginger

47404

81.

matthew

47207

82.

abcd1234

47064

83.

taylor

46375

84.

samantha

46353

85.

whatever

46339

86.

andrew

46083

87.

1qaz2wsx3edc

45643

88.

thomas

45317

89.

jasmine

45190

90.

animoto

44940

91.

madison

44183

92.

0987654321

44175

93.

54321

43912

94.

flower

43696

95.

Password

43430

96.

maria

43177

97.

babygirl

43037

98.

lovely

42897

99.

sophie

42889

100.

Chegg123

42542

101.

computer

42531

102.

qwe123

42478

103.

anthony

42427

104.

1q2w3e4r

42242

105.

peanut

42143

106.

bubbles

42142

107.

asdasd

42096

108.

qwert

41948

109.

1qaz2wsx

41840

110.

pakistan

41798

111.

123qwe

41602

112.

liverpool

41272

113.

elizabeth

41268

114.

harley

41084

115.

chelsea

40499

116.

familia

39996

117.

yellow

39726

118.

william

39702

119.

george

39270

120.

7777777

39071

121.

loveme

38797

122.

123abc

38501

123.

letmein

38353

124.

oliver

38269

125.

batman

37973

126.

cheese

37956

127.

banana

37910

128.

testing

37881

129.

secret

37784

130.

angel

37764

131.

friends

37741

132.

jackson

37731

133.

aaaaaa

37568

134.

softball

37556

135.

chicken

37250

136.

lauren

37151

137.

andrea

36940

138.

welcome

36723

139.

asdfgh

36597

140.

robert

35654

141.

orange

35594

142.

Testing1

35389

143.

pokemon

35293

144.

555555

35128

145.

melissa

35045

146.

morgan

34829

147.

123123123

34721

148.

qazwsx

34436

149.

diamond

34422

150.

brandon

34227

151.

jesus

34220

152.

mickey

34180

153.

olivia

34110

154.

changeme

33940

155.

danielle

33781

156.

victoria

33770

157.

gabriel

33679

158.

123456a

33562

159.

0.00000000

33417

160.

loveyou

33306

161.

hockey

33091

162.

freedom

33047

163.

azerty

32881

164.

snoopy

32792

165.

skinny

32682

166.

myheritage

32619

167.

qwerty1

32560

168.

159753

32365

169.

forever

32115

170.

iloveu

32043

171.

killer

31879

172.

joseph

31852

173.

master

31667

174.

mustang

31619

175.

hellokitty

31458

176.

school

30905

177.

Password1

30871

178.

patrick

30821

179.

blink182

30756

180.

tinkerbell

30739

181.

rainbow

30726

182.

nathan

30489

183.

cooper

30457

184.

onedirection

30388

185.

alexander

30078

186.

jordan23

29874

187.

lol123

29832

188.

jasper

29813

189.

junior

29502

190.

q1w2e3r4

29368

191.

222222

29362

192.

11111111

29291

193.

benjamin

29288

194.

jonathan

29279

195.

passw0rd

29267

196.

0123456789

29110

197.

a123456

29103

198.

samsung

29073

199.

123

29068

200.

love123

29064

コードを保護することが重要です

Equifaxのような重要な企業から機密データが漏洩すると、何百万人もの消費者がすぐに自分たちが被害者であることに気付きました。ストーリーは、常に劇的なデータと脆弱性を隠そうとする企業に関するものです。ただし、データ侵害はセキュリティ障害の結果です。

このような深刻なセキュリティ侵害の本当の理由は何ですか？

多くの場合、機密データは安全でないソースコードを通じて漏洩します。これは物語の中の物語であり、この魅力的な物語はめったに語られません。このような障害は、Uberなどの最も広く最も馴染みのある企業内でも発生することがよくあります。セキュリティ障害はOneLoginのようなセキュリティ会社内でも発生しますが、これらの障害が発生する理由はほとんどありません。

多くの場合、機密データは安全でないソースコードを通じて漏洩します。これは物語の中の物語であり、この魅力的な物語はめったに語られません。

これは、ソースコードの脆弱性が高度に技術的であるためです。これからわか​​るように、これは「技術的なコンポーネントが多すぎる」ため、回避できない問題です。

しかし、セキュリティ障害の原因についてこれ以上悪質な理由は聞いていません。ソフトウェアが重要なセキュリティ機能を欠いていることを会社が明らかにした場合、彼らはすぐに顧客の信頼を失います。その結果、ヤフーやその他の企業は何年もの間意図的にセキュリティ侵害を隠してきました。

これらのセキュリティホールの根本原因はソースコードそのものであることがわかります。この記事では、GitやApache Subversionなどのソースコードリポジトリのセキュリティホールについて説明します。また、ソースコードのスキャンなど、さまざまなソリューションについても説明します。最近のセキュリティ障害から始めて、共通点を見つけましょう。





ニュースイベント


2016年末時点で、合計5,700万人のUberユーザーとドライバーが、最近の史上最大のデータ侵害の被害者でした。 1 2人のハッカーが、電話番号、名前、メールアドレスなどの個人情報を盗みました。さらに悪いことに、同社は1年以上にわたって隠蔽した。隠蔽請求の解決には、1億4800万ドルの費用がかかります。



この話はあまりにも一般的です。 「Uber」で発生している同じことを任意の組織または会社に変換すると、同じストーリーが表示されます。そのような話は、私たち自身のウェブベースのセキュリティ予防策を増やすことを私たちに思い出させ続けます。

企業は強力なパスワード作成を強化することで自信を高めようとしますが、一部は強力なパスワードジェネレータを使用します。より厳格な手段には、2要素認証または多要素認証の使用が含まれます。従来のハードウェアトークンまたはキーフォブに加えて、これにはSMSを介して電子メールアドレスに送信される動的なPINコードも含まれる場合があります。このようにセキュリティが強化されているのに、なぜUberや他の企業の何百万人もの消費者のプライバシーが侵害されていると聞き続けるのはなぜですか？



ばかげて本当の答えは、悪役はしばしば何もしないということです。最も破壊的な「ハック」は、インデックス化可能なウェブディレクトリまたはAmazon S3バケットにある暗号化されていないファイルでパスワードを誤って発見するよりもはるかに賢いだけです。これがUberで起こったことであり、バージョン管理プラットフォームの脆弱性とGitやSubversionのようなコードリポジトリを介して攻撃者がログイン資格情報にアクセスする方法を詳しく見ていきます。



たとえば、消費者信用報告機関Equifaxの違反など、1億4800万人以上の消費者に影響を与えた別の重大な違反を考えてみましょう。

Equifaxに対する大規模な攻撃は、分散コンピューティングアプリケーション用の別の一般的な開発ツールであるApache Strutsを利用しました。 Apacheは、高品質で人気のあるオープンソース開発者ツールを作成することで知られています。ただし、Apache Strutsには多くの既知のセキュリティ問題があります。現在、開発者フォーラムには、既知のセキュリティ問題に関する72の投稿があります！これらのセキュリティ脆弱性の範囲は中程度とはほど遠く、企業の電子商取引プラットフォームを弱める可能性のあるサービス拒否攻撃およびリモートコード実行攻撃を対象としています。



これは、最も明白な質問の1つを示唆しています。ApacheStrutsにセキュリティ上の問題があることがわかっている場合、Equifaxはなぜそれを使用するのですか？一般に、Equifaxはこれらのセキュリティ問題を利用する前に知っていたと言われていますが、Equifaxはそれらを解決するための意図的なアクションを実行しませんでした。なんで？このような一般的なソフトウェアで既知のエラーと攻撃ベクトルを処理する問題を理解するには、問題の技術的な側面を探る必要があります。



データセキュリティのみに重点を置いている企業も例外ではありません。たとえば、サイバーセキュリティに特化した企業であるOneLoginが攻撃されました。この特定のストーリーは、APIキーとOAuthトークンの盗難という目的に最も近いものです。

OneLoginは攻撃の詳細を開示しませんでしたが、さらなる侵入からの保護に関する顧客への推奨事項は、侵入の潜在的なポイントを間接的に明らかにしました。

開発者が自動ログインに使用するログイン認証情報（APIキーとOAuthトークン）は通常、Shell Script 5に暗号化されずに保存され、ログファイルに表示されることもあります。



しかし、同社はこの特定の問題を解決する上で大きな課題に直面しています。開発者とアジャイルチームは、認証資格情報を完全に保護することなく自動化することが困難な合理化された継続的な展開パイプラインを切望しています。これは完全に行うことができますが、十分な注意と絶え間ないレビューが必要です。これらのセキュリティホールが存在する理由と理由から始めましょう。

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

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

當像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/

CI / CD 概念介紹

在快速的開發循環中，持續驗證系統開發結果 ，分割成小部分地儘早確認，期望開發產出能符合原始需求，或依據產出進行快速修正。 簡單來說就是儘量減少手動人力，將一些日常工作交給自動化工具。例如：環境建置、單元測試、日誌紀錄、產品部署。

持續整合 (CI) 的目的

1. 降低風險。
2. 減少人工手動的繁複程序。
3. 可隨時產生一版可部署的版本。
4. 增加系統透明度。
5. 建立團隊信心。

什麼是持續性整合(CI)呢？持續性整合的目的為：針對軟體系統每個變動，能持續且自動地進行驗證。此驗證可能包含了：

• 建置 (build)
• 測試 (test)
• 程式碼分析 (source code analysis)
• 其他相關工作 (自動部署)

驗證完成後，進一步可以進行CD工作，整合自動化發佈或部署 (Continuous Delivery / Continuous Deployment) 。透過此流程可以確保軟體品質，不會因為一個錯誤變動而產生錯誤結果或崩潰(Crash)。此流程中的各類工具，也會產生一些回饋給開發者或其他角色，包含網頁/報表等等，用來追蹤並改善軟體潛藏的問題。

Source : Cisco

CI/CD 分別指 持續整合(Continuous Integration, CI)、持續部署inuous Delivery, CD)、持續交付(Continuous Deployment, CD)，後者負責範圍包括前者的內容。

在筆者看來，CI/CD 比較像是三個不同階段的任務，只有完成了前一個階段，才能進入下一個階段。

第一階段、持續整合(Continuous Integration, CI)

曾經團隊協同開發過的人，應該都有遇到在提交時，為了解決程式碼衝突，結果花上更多的時間在處理衝突的程式碼。

尤其提交間隔越久的開發者，處理程式碼的衝突，就越困難。而且還可能造成團隊的成員重複解決相同程式區塊的衝突。整合的時間越晚，整合的難度與失敗的機率就越高。

持續整合的目的，利用頻繁地提交新功能的變更，觸發自動化建置和測試，確保最新版本的軟體是可運行的。

• 版本控制: 持續整合最重要的一步，可以說，沒有版控，就沒有 CI/CD。
• 建置: 確保提交的程式碼是否可以執行的。
• 自動化測試 確保功能正常與軟體品質。
• 程式碼分析: 檢查 code style 或程式的穩健度。

第二階段、持續部署(Continuous Delivery, CD)

完成整合的階段後，接下來就是部署的階段。

不管是為了測試、驗收或上線，都一定需要進行軟體的部置。但是往往部署環境的差異，造成驗收或上線時的兵荒馬亂。

持續部署的目的，就是要快速而自動的部署，任何版本的軟體到不同的環境。為此，須採用同一個包裝好的套件 (package)，以達到 簡化組態管理(configuration management) 與 減少部署所需的時間。

另外，因為採用同一 package 進行部署的因素，必需將其組態 / 設定外部化 (configuraiton externalization)。簡單點講，就是不要將設定寫死 (hard-coded) 在程式碼。

• 發佈
• 手動測試

第三階段、持續交付(Continuous Deployment, CD)

持續交付的目標，就是 儘快將最新版本的軟體，交付到最終使用者(end-user)手中。

為達到持續交付，必需先行建立 持續整合 跟 持續部署 的機制。

持續整合的精神

持續整合是 CI/CD 最重要的一點，如果提交的程式有問題，造成整合失敗。對於發生失敗的這種情況，團隊內的成員，需要在一開始就要溝通清楚，取得共識。

對於上面提到，提交造成整合失敗的情況，常見的做法有……

• 每次提交之前，先在本機執行建置與單元測試，作為整合前的額外驗證措施。
• 造成提交失敗的人，要負責修訂錯誤。
• 建置有錯的情況下，禁止其他新功能的提交。
• 測試失敗的情況下，需立即找出問題，確保測試通過，以維持程式品質。

持續整合需要團隊內，所有成員的一同努力與堅持，才能達到良好的效果。

source:

至於實作 .....

先降, 下次再談 , 先去按摩了