本文主要關(guān)于應(yīng)用程序、業(yè)務(wù)系統(tǒng)開發(fā)安全性戰(zhàn)略趨勢、它們的影響以及如何最大限度地利用我們所面臨的變化。

應(yīng)用程序安全性正在發(fā)生巨大的變化，變化的速度如此之快，以至于 10 年前進(jìn)入軟件開發(fā)領(lǐng)域的人都幾乎無法看清楚當(dāng)前的狀態(tài)。

對于開發(fā)人員來說，快速變化是一顆難以下咽的苦果。開發(fā)人員時刻面臨著多方面的變化：新技術(shù)和框架、編程語言、工具、流程，等等。要與軟件開發(fā)核心主題保持與時俱進(jìn)是很困難的，更不用說像應(yīng)用程序安全性這樣的主題了。

關(guān)于應(yīng)用程序安全性的主要趨勢，有一件事我很清楚：好消息多于壞消息。我并沒有低估了壞消息，實際上壞消息也有很多，但這枚硬幣還有另外一面。

挑戰(zhàn)為我們創(chuàng)造了機會。如果我們從大的角度來看，應(yīng)用程序安全性正在為我們創(chuàng)造機會。有戰(zhàn)略頭腦的軟件開發(fā)人員在解決問題和利用機會方面做得非常出色。本文將討論一些這方面的東西。

在本文中，我們將介紹一些趨勢：

DevSecOps 和開發(fā)團(tuán)隊?wèi)?yīng)用安全責(zé)任的融合；

代碼內(nèi)部和外部的攻擊模式變化；

對開發(fā)人員友好的應(yīng)用程序安全性測試；

軟件供應(yīng)鏈安全的興起成為人們關(guān)注的焦點；

風(fēng)險最大但人們卻不怎么討論的秘鑰管理；

保護(hù)數(shù)據(jù)而不僅僅是代碼；

認(rèn)證授權(quán)的變革進(jìn)展；

第三方對安全的依賴和影響；

改變用戶對安全性的期望。

這是一篇涉及面很廣的文章，幾乎涵蓋了應(yīng)用程序安全的每一個領(lǐng)域。由于本文涉及的范圍很廣，因此本文的結(jié)構(gòu)與典型的以公司為中心的分析略有不同。本文的目標(biāo)是涵蓋更多的領(lǐng)域，同時也將提供一些實用的想法。

讓我們開始吧。

1、融合讓開發(fā)人員對開發(fā)以外的東西也負(fù)起責(zé)任

影響

開發(fā)、安全性和運營的融合等于是將所有東西都直接轉(zhuǎn)移到開發(fā)人員身上。傳統(tǒng)上，軟件開發(fā)是關(guān)于編寫、測試和部署代碼?，F(xiàn)在，DevSecOps(更重要的是它背后的流程和工具) 正在把更多的責(zé)任和控制權(quán)轉(zhuǎn)移給開發(fā)人員。開發(fā)人員除了負(fù)責(zé)代碼的部分，現(xiàn)在也要對基礎(chǔ)設(shè)施、安全性等方面負(fù)責(zé)。

從表面上看，責(zé)任的增加看起來像是一件壞事。或許確實如此，但更重要的是要知道其中的原因。當(dāng)你仔細(xì)地觀察一個這個趨勢，你會發(fā)現(xiàn)，是工具的改進(jìn)促成了這種轉(zhuǎn)變。

工具正在變得越來越好，讓這些工作負(fù)載變得可管理——甚至可能是有利的。在安全性方面，許多新產(chǎn)品都是可組合的，它們?yōu)殚_發(fā)人員提供了一組原語和工作流來構(gòu)建安全性，而不是為他們提供一刀刀的產(chǎn)品。

Persona 就是一個很好的例子，它是一組構(gòu)建模塊，開發(fā)人員可以用它們?yōu)榭蛻魳?gòu)建特定的身份驗證工作流。另一個是 Panther，開發(fā)人員可以用它基于一組日志管理和警報原語來構(gòu)建高度定制的 SIEM。

有遠(yuǎn)見的安全軟件公司將繼續(xù)構(gòu)建對開發(fā)者友好的工具。預(yù)計未來還會出現(xiàn)更多這樣的東西。

想法

開發(fā)與安全性的融合將繼續(xù)下去，所以請擁抱它吧。隨著新模式 (和新產(chǎn)品) 的普及，這一趨勢將會加速。

正如 Eleanor Roosevelt 所說的：“自由伴隨著責(zé)任。”傳統(tǒng)的安全觀念通常是購買 (理論上) 能夠解決一系列安全問題的產(chǎn)品，而融合和可組合性扭轉(zhuǎn)了這一局面。

現(xiàn)在，我們有了一套很好的工具，我們可以用它們來為我們的安全問題構(gòu)建解決方案。這是一個很好的轉(zhuǎn)變，但很多人還沒有準(zhǔn)備好。

最后，開發(fā)團(tuán)隊?wèi)?yīng)該有意識地采用開發(fā)過程和工具，不要讓安全團(tuán)隊強加給你們這些，而應(yīng)該在達(dá)成共識的基礎(chǔ)上開展合作。這一趨勢為重新定義開發(fā)和安全之間的關(guān)系 (以及選擇世界級的工具) 帶來了一個機會窗口，所以要充分利用它。

2、發(fā)生在應(yīng)用程序之外的攻擊

影響

攻擊者的目標(biāo)是你的客戶和金錢，而利用應(yīng)用程序只是實現(xiàn)這一目標(biāo)的眾多途徑之一。不幸的是，攻擊者總是在尋找新的和創(chuàng)造性的方法來實現(xiàn)他們的邪惡動機。攻擊你的應(yīng)用程序是一種可靠的方法，但最近的一些攻擊已經(jīng)滲透到軟件工程的鄰近領(lǐng)域。

例如，針對 DevOps 管道的攻擊已經(jīng)造成了包括 SolarWinds 在內(nèi)的重大漏洞。InfoSec 社區(qū)非常重視代碼安全，盡管如此，像 SolarWinds 這樣的例子告訴我們，我工程流程的其他部分也正在成為攻擊目標(biāo)。

攻擊可能來自各個方面，即使能夠避免泄露，也會產(chǎn)生運營上的影響。Verizon 發(fā)布的 2021 年數(shù)據(jù)泄露調(diào)查報告顯示，拒絕服務(wù) (DoS) 攻擊導(dǎo)致了不成比例的事故 (但數(shù)據(jù)泄露不是很多)。不幸的是，我們現(xiàn)在需要留心遵循這種模式的穩(wěn)定的攻擊流 (甚至是巨大的峰值)。

想法

將你的安全意識擴展到代碼之外。攻擊者正在尋找他們所能找到的任何方法來攻擊你。我們必須調(diào)整自己的心態(tài)，將代碼之外的區(qū)域納入安全模型范圍。

考慮使用 DoS 緩解策略和自動化程序管理等服務(wù)。雖然攻擊無法完全消除，但可以降低其影響。像 Cloudflare 這樣的服務(wù)通?？梢越档痛笮凸粼斐傻奈：?，為我們的應(yīng)用程序添加這一層保護(hù)是值得的。

將你的 DevOps 管道納入威脅建?；顒?。CI/CD 工具、工件存儲庫和管道的其他部分現(xiàn)在都是需要保護(hù)的目標(biāo)，就像我們的代碼和基礎(chǔ)設(shè)施一樣。

3、基本的 Web 應(yīng)用程序攻擊仍占入侵總數(shù)的 26.1%

影響

Verizon 的 DBIR 報告顯示，Web 應(yīng)用程序攻擊是第二常見的攻擊模式 (社會工程位居第一，百分比為 33.6%)。攻擊者關(guān)注的不只是應(yīng)用程序，但應(yīng)用程序仍然會受到攻擊，并以驚人的速度造成泄露。

“憑證填充”攻擊的上升趨勢正在形成一種新的攻擊模式。Verizon 的 DBIR 報告顯示，憑證填充 (約占 80%) 導(dǎo)致的事故遠(yuǎn)多于漏洞利用 (約占 20%)?？紤]到漏洞利用的可見程度和教育程度，這樣的比例讓許多人感到意外。

從過程和治理的角度來看，漏洞管理程序正在與應(yīng)用程序安全性和風(fēng)險管理融合在一起。過去，這些領(lǐng)域是分開對待的，漏洞管理側(cè)重于打補丁，風(fēng)險管理側(cè)重于審計和合規(guī)性。但現(xiàn)在公司一般采用基于風(fēng)險的方法進(jìn)行漏洞管理，并在整個過程中管理應(yīng)用程序安全漏洞。

想法

不止于手動測試和一次性靜態(tài)代碼掃描?，F(xiàn)如今，在快速的迭代式軟件開發(fā)過程中，基于時間點的掃描或人工評審無法跟上應(yīng)用程序代碼的變化速度。最理想的情況是在寫代碼時就做好保護(hù)。正如我們接下來將要討論的，工具方面的一些改進(jìn)為迭代式且對開發(fā)人員友好的開發(fā)方法帶來了可能性。

使用服務(wù)來檢測和防御憑證填充攻擊。這種攻擊模式仍然是針對應(yīng)用程序的攻擊，盡管它使用的方法與傳統(tǒng)的漏洞利用不同。我們必須預(yù)料到對應(yīng)用程序進(jìn)行的憑證填充攻擊會持續(xù)不斷，包括在發(fā)生新的憑證泄露時偶爾會激增的攻擊數(shù)量。

采用基于優(yōu)先級和風(fēng)險的方法來糾正漏洞。盡管我們很想關(guān)閉所有的漏洞，但目前來看，要讓大多數(shù)公司在實踐當(dāng)中做到這樣是不切實際的?；陲L(fēng)險的方法使糾正漏洞更易于管理。

4、應(yīng)用程序安全測試正在變得對開發(fā)人員友好

影響

組織 (和產(chǎn)品) 終于開始迎合開發(fā)人員的需求。對于任何一個有經(jīng)驗的軟件開發(fā)人員來說，這都是一個漫長的過程。盡管應(yīng)用程序安全工單、延遲發(fā)布和最后時刻漏洞修復(fù)的痛苦記憶還沒有完全消去，但已經(jīng)取得了很大的進(jìn)展。

主要的想法是在開發(fā)過程中將應(yīng)用程序安全性測試向前移，并在開發(fā)和提交代碼時執(zhí)行代碼掃描。“左移”這個詞有點被過度使用，但其基本思想還是不錯的。就像編寫自動化測試并獲得實時反饋一樣，你也可以用類似的方式運行自動化安全測試。

一些公司，已經(jīng)在這方面處于領(lǐng)先地位。這兩家公司都有可能在未來五年內(nèi)通過 IPO 獲得回報。他們的成功 (以及龐大的開發(fā)者基礎(chǔ)) 印證了軟件開發(fā)可以同時提高速度和安全性的觀點——這兩個目標(biāo)并不是互斥的。

想法

有遠(yuǎn)見的工程團(tuán)隊癡迷于可以簡化編寫安全代碼的過程。正如 Snyk 的創(chuàng)始人 Guy Podjarny 最近在一個“Human Layer Security”播客中所討論的：“你不得不去操心一些事情，而你操的心比這些事情給你造成的負(fù)擔(dān)要多得多。”這句話簡明扼要地定義了一些產(chǎn)品（比如 Snyk）的價值。如果我們?yōu)殚_發(fā)人員簡化安全性實施過程，他們就更有可能接受它。

Podjarny 還討論了對應(yīng)用程序安全性進(jìn)行去中心化的想法。傳統(tǒng)的模式是讓信息安全團(tuán)隊完全負(fù)責(zé)應(yīng)用程序安全測試。但隨著軟件繼續(xù)吞噬世界，公司編寫越來越多的代碼，這種做法自然成為了瓶頸?，F(xiàn)代應(yīng)用程序安全工具提供了去中心化的可能性，并有助于將安全性轉(zhuǎn)變?yōu)楣こ虉F(tuán)隊和安全團(tuán)隊之間的共同責(zé)任。

最后，在現(xiàn)代應(yīng)用程序安全平臺上進(jìn)行投入。這一領(lǐng)域的主要進(jìn)展是提供了眾多工具，它們的采用成本出人意料地低，尤其是考慮到它們對公司安全狀況的影響。

5、軟件供應(yīng)鏈安全不再隱匿于水面之下

影響

Log4j(Log4Shell)、NPM 庫 (colors/faker) 和其他引人注目的漏洞讓軟件供應(yīng)鏈安全在 2021 年受到了人們的關(guān)注。甚至連美國總統(tǒng)都在談?wù)撍?(并采取行動)。

事后看來，這種趨勢的出現(xiàn)本應(yīng)是顯而易見的。多年來，我們一直在依賴開源軟件包，相對平靜和穩(wěn)定的軟件供應(yīng)鏈安全不會永遠(yuǎn)持續(xù)下去——軟件包成為攻擊載體只是時間問題。

救兵正在路上。在過去兩個季度里，新一代初創(chuàng)企業(yè)籌集了 1060 萬美元資金，其中大部分是種子期融資。從 2021 年的漏洞攻擊中吸取教訓(xùn)并思考采取哪些有效的行動，我們需要一段時間才能形成這種集體共識。不管怎樣，創(chuàng)新和進(jìn)步的步伐都將快速向前移動。

想法

首先，我們必須總結(jié)近期的教訓(xùn)：優(yōu)先查找和修復(fù)應(yīng)用程序中的漏洞。Snyk 或 Github Dependabot 等工具在這方面可以幫得上忙。盡可能自動化地查找易受攻擊的軟件包，然后以更自動化的方式高效地修復(fù)漏洞。

請關(guān)注這一領(lǐng)域的新興公司。正如我之前所說的，救兵正在路上。Chainguard 公司最近獲得了一筆融資，它的經(jīng)驗豐富的團(tuán)隊正在開發(fā)一款創(chuàng)新的產(chǎn)品。

最后，探索一些新興的方法，比如 SLSA 和 Sigstore。這些項目還需要一些時間來演化并成為直接可操作的產(chǎn)品。不管怎樣，花點時間關(guān)注一下最新的進(jìn)展總是值得的，因為當(dāng)它們被主流采用時，你已經(jīng)做好了準(zhǔn)備。

6、秘鑰管理是最大的風(fēng)險，但沒有人關(guān)注

影響

人們討論 (和抱怨) 密碼安全問題，但很少有人花時間討論管理其他類型的秘鑰。API 密鑰、證書和其他非密碼形式的訪問控制被置于聚光燈之外。對很多人來說，它們只是“開發(fā)人員使用的東西”。

在 2021 年的一項 1Password 調(diào)查中，80% 的 IT/DevOps 組織承認(rèn)沒有很好地管理他們的秘鑰。這可不是什么好事。這個問題比你想象的更普遍。在同一項調(diào)查中，65% 的公司表示擁有超過 500 個秘鑰，18% 的公司擁有數(shù)不清的秘鑰。

擁有超過 500 個秘鑰 (或者更多——誰知道呢，對吧？！) 卻沒有很好地管理它們，這種情況顯然是很糟糕的。有了秘鑰，就可以獲取對很多敏感信息的訪問權(quán)限，就像我們最近看到的針對 GitHub 賬戶的令牌攻擊一樣。現(xiàn)在已經(jīng)出現(xiàn)了保護(hù)秘鑰的勢頭，攻擊促使保護(hù)秘鑰的想法變得更加突出。

想法

讓保持秘鑰衛(wèi)生成為工程文化的一部分。如果我們不談?wù)摫Ｗo(hù)和管理秘鑰，就不能指望人們會保證它們的安全。秘鑰需要成為安全討論和行動的一部分。

解決辦法之一是使用秘鑰管理服務(wù)?，F(xiàn)在已經(jīng)有一些不錯的產(chǎn)品，包括 CyberArk Conjur、HashiCorp Vault 和 1Password Secrets Automation。GitHub 也在 Actions 工作流中建立了基本的秘鑰管理權(quán)限。

最后，在產(chǎn)品實施之前有效地發(fā)現(xiàn)秘鑰的“藏身處”，這是很重要的一步。因為你無法保護(hù)你不知道的秘鑰，完全發(fā)現(xiàn)它們比你想象的要困難得多。秘鑰總是被嵌入到源代碼或配置文件中。最好的方法是將秘鑰發(fā)現(xiàn)作為一個項目，坦白交代你的發(fā)現(xiàn)，并保護(hù)好它們。

7、保護(hù)數(shù)據(jù)和保護(hù)代碼同樣重要

影響

很多常見的攻擊模式會繞過應(yīng)用程序，直接攻擊數(shù)據(jù)存儲。我們比以往任何時候都更需要考慮保護(hù)應(yīng)用程序之外的數(shù)據(jù)。Verizon 的 DBIR 報告顯示，攻擊者的目標(biāo)通常是獲取憑證 (用于特權(quán)升級)、個人數(shù)據(jù)、銀行數(shù)據(jù)和內(nèi)部機密數(shù)據(jù)。

隱私法規(guī)也為人為錯誤帶來了懲戒。這提升了數(shù)據(jù)保護(hù)標(biāo)準(zhǔn)，確保只有需要訪問權(quán)限的人才能訪問數(shù)據(jù)。如果可以避免，就不應(yīng)該讓開發(fā)團(tuán)隊過多地訪問生產(chǎn)數(shù)據(jù)。

如今，在設(shè)計應(yīng)用程序時，需要將數(shù)據(jù)安全性納入架構(gòu)的考慮范圍。如何保護(hù)敏感數(shù)據(jù)是整體解決方案的一部分，需要為其設(shè)計隱私保護(hù)。設(shè)計一個應(yīng)用程序已經(jīng)很困難了，但不管怎樣，數(shù)據(jù)保護(hù)仍然是設(shè)計過程不可或缺的一部分。

想法

成為保護(hù)數(shù)據(jù)解決方案的一部分，不要把責(zé)任留給基礎(chǔ)設(shè)施和安全團(tuán)隊。對于開發(fā)團(tuán)隊來說，編寫安全的代碼仍然很重要，但不能以完全忽略數(shù)據(jù)安全為代價。

探索可以幫助開發(fā)人員和數(shù)據(jù)科學(xué)家安全處理敏感數(shù)據(jù)的新興方法和產(chǎn)品。來自 Y Combinator W22 項目的 JumpWire 和 Sarus 這兩家公司正在解決這個問題。還有一篇關(guān)于 Evervault(另一家加密基礎(chǔ)設(shè)施開發(fā)公司) 的文章也很值得一讀。我們離事實上的標(biāo)準(zhǔn)還有很長的路要走，但我對未來充滿希望。

8、我們正處于認(rèn)證和授權(quán)的黃金時代

影響

認(rèn)真對待。目前可供開發(fā)人員使用的身份認(rèn)證和授權(quán)解決方案數(shù)量驚人。它們一天比一天好。像 FusionAuth、Transmit Security、Stytch 等公司已經(jīng)推出了世界級的、對開發(fā)者友好的認(rèn)證產(chǎn)品，使用起來非常簡單。

用戶也越來越熟悉新的身份認(rèn)證因子。我們離完全實現(xiàn)無密碼機制還有很長一段時間，但對于處于不安全環(huán)境的人來說，像魔術(shù)鏈接這樣的升級技術(shù)已經(jīng)開始變得更加可行。這是一個很好的趨勢，因為主流的采用為我們提供了比單獨使用密碼更好的選擇。

最后，外部授權(quán)正在成為新一代產(chǎn)品的選擇。這種趨勢仍然是一個長期的過程，不過已經(jīng)有一批公司正在開發(fā)可以讓這項工作變得更容易的產(chǎn)品。

想法

我想再重申一遍：不要使用自己的身份認(rèn)證機制。你的應(yīng)用程序可能會因為多種原因受到攻擊和破壞。構(gòu)建自己的認(rèn)證機制是在冒不必要的風(fēng)險——這在 2022 年本質(zhì)上是一種反模式?？梢钥紤]使用外部服務(wù)或開源包，如 Devise(Ruby on Rails 社區(qū)在使用)。

在對應(yīng)用程序進(jìn)行身份認(rèn)證時，需要為用戶提供無密碼或多因子身份驗證 (MFA) 選項，使用外部身份認(rèn)證平臺可以更容易實現(xiàn)。用最小的努力為用戶帶來額外的安全好處，這么做是非常值得的。

最后，驗證進(jìn)行外部授權(quán)是否可行，但要小心謹(jǐn)慎。將授權(quán)交給第三方的風(fēng)險比使用第三方標(biāo)準(zhǔn)身份認(rèn)證機制的風(fēng)險要大得多。但是，這總比在構(gòu)建自己的授權(quán)機制時犯錯要好。

9、安全性高度依賴于第三方

影響

在 SaaS 和云計算世界，安全型比以往任何時候都更依賴于第三方。我們將應(yīng)用程序托管在大型的云供應(yīng)商平臺上。從 UI 框架到聊天，再到分析等，都依賴于第三方服務(wù)。我只是建議使用第三方認(rèn)證機制，但現(xiàn)在都糾纏在一起了，安全性之間是互相依賴的。

當(dāng)然，潛在風(fēng)險和影響的程度和規(guī)模因服務(wù)而異。云服務(wù)的漏洞會對整個科技行業(yè)造成宏觀風(fēng)險和影響，Mailchimp 之類的服務(wù)則處于中位。他們有很多客戶，但在最近的案例中，只出現(xiàn)了少數(shù)被攻擊的情況。

其他解決方案的風(fēng)險范圍較小。有些對客戶有潛在的影響 (例如聊天服務(wù)的宕機)，有些只影響到員工。

我們?nèi)匀粚Π踩?fù)有重大責(zé)任，盡管在一定程度上超出了我們的可控范圍。關(guān)鍵在于我們要意識到這一趨勢已經(jīng)發(fā)展到何種程度，以及我們對第三方的依賴程度。我們需要承認(rèn)現(xiàn)實，這樣才能確保采取正確的步驟來保護(hù)自己。

想法

理清楚你的應(yīng)用程序正在使用哪些第三方服務(wù)。這與保護(hù)秘鑰的想法類似——如果你不知道你用了哪些第三方服務(wù)，就無法保護(hù)它們。

將確保安全視為購買第三方服務(wù)的組成部分。在使用服務(wù)之前對安全進(jìn)行評估要比在將其深深嵌入到應(yīng)用程序中之后進(jìn)行評估要容易得多?；蛘吒愕氖?，在第三方服務(wù)被攻擊后，你要承擔(dān)后果。

最后，第三方安全報告 (如 SOC2) 雖然有用，但你也要自己做好準(zhǔn)備。指望審計人員發(fā)現(xiàn)每個安全問題是不現(xiàn)實的。對于很多第三方服務(wù)來說，你的場景也有可能超出其審計范圍。

10、對于很多用戶來說，安全是一個特性

影響

信任和安全正迅速成為產(chǎn)品設(shè)計的重要組成部分。關(guān)于數(shù)據(jù)泄露、選舉安全、社交媒體等事件的新聞頭條不斷出現(xiàn)，將安全、隱私、信任和欺詐等問題暴露在公眾的視野里。

如果一個應(yīng)用程序涉及到用戶生成的內(nèi)容、金錢或敏感數(shù)據(jù)，人們對安全的期望會更高。處理應(yīng)用程序不良事件，或直接阻止它們發(fā)生，這樣的經(jīng)驗對許多人來說都非常重要。

想法

實施信任和安全流程，即使是最基本的措施，有總比沒有好。但如果你的客戶對業(yè)務(wù)系統(tǒng)開發(fā)安全性有更高的期望，你就應(yīng)該準(zhǔn)備構(gòu)建更健壯的特性。圍繞安全和隱私拓展公司透明度的界限，如果實施得當(dāng)，它就是一種可以讓你的公司和產(chǎn)品變得與眾不同的戰(zhàn)略優(yōu)勢。