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

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

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

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

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

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

DevSecOps 和開發(fā)團隊應用安全責任的融合；

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

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

軟件供應鏈安全的興起成為人們關注的焦點；

風險最大但人們卻不怎么討論的秘鑰管理；

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

認證授權的變革進展；

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

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

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

讓我們開始吧。

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

影響

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

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

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

Persona 就是一個很好的例子，它是一組構建模塊，開發(fā)人員可以用它們?yōu)榭蛻魳嫿ㄌ囟ǖ纳矸蒡炞C工作流。另一個是 Panther，開發(fā)人員可以用它基于一組日志管理和警報原語來構建高度定制的 SIEM。

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

想法

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

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

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

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

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

影響

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

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

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

想法

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

考慮使用 DoS 緩解策略和自動化程序管理等服務。雖然攻擊無法完全消除，但可以降低其影響。像 Cloudflare 這樣的服務通常可以降低大型攻擊造成的危害，為我們的應用程序添加這一層保護是值得的。

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

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

影響

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

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

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

想法

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

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

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

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

影響

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

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

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

想法

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

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

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

5、軟件供應鏈安全不再隱匿于水面之下

影響

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

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

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

想法

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

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

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

6、秘鑰管理是最大的風險，但沒有人關注

影響

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

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

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

想法

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

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

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

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

影響

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

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

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

想法

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

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

8、我們正處于認證和授權的黃金時代

影響

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

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

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

想法

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

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

最后，驗證進行外部授權是否可行，但要小心謹慎。將授權交給第三方的風險比使用第三方標準身份認證機制的風險要大得多。但是，這總比在構建自己的授權機制時犯錯要好。

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

影響

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

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

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

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

想法

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

將確保安全視為購買第三方服務的組成部分。在使用服務之前對安全進行評估要比在將其深深嵌入到應用程序中之后進行評估要容易得多?；蛘吒愕氖牵诘谌椒毡还艉?，你要承擔后果。

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

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

影響

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

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

想法

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