作者 | strategyofsecurity.com

譯者 | 明知山

策劃 | Tina

本文主要是關於應用程序安全性戰略趨勢、它們的影響以及如何最大限度地利用我們所面臨的變化。

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

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

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

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

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

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

代碼內部和外部的攻擊模式變化；

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

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

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

保護數據而不僅僅是代碼；

認證授權的變革進展；

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

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

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

讓我們開始吧。

1

融合讓開發人員對開發以外的東西也負起責任

影響

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

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

工具正在變得越來越好，讓這些工作負載變得可管理——甚至可能是有利的。在安全性方面，許多新產品都是可組合的，它們為開發人員提供瞭一組原語和工作流來構建安全性，而不是為他們提供一刀刀的產品。

Persona 就是一個很好的例子，它是一組構建模塊，開發人員可以用它們為客戶構建特定的身份驗證工作流。另一個是 Panther，開發人員可以用它基於一組日志管理和警報原語來構建高度定制的 SIEM。

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

想法

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

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

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

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

2

發生在應用程序之外的攻擊

影響

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

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

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

想法

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

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

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

3

基本的 Web 應用程序攻擊仍占入侵總數的 26.1%

影響

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

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

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

想法

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

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

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

4

應用程序安全測試正在變得對開發人員友好

影響

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

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

一些公司，比如 Veracode 和 Snyk，已經在這方面處於領先地位。這兩傢公司都有可能在未來五年內通過 IPO 獲得回報。他們的成功 (以及龐大的開發者基礎) 印證瞭軟件開發可以同時提高速度和安全性的觀點——這兩個目標並不是互斥的。

想法

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

Podjarny 還討論瞭對應用程序安全性進行去中心化的想法。傳統的模式是讓信息安全團隊完全負責應用程序安全測試。但隨著軟件繼續吞噬世界，公司編寫越來越多的代碼，這種做法自然成為瞭瓶頸。現代應用程序安全工具提供瞭去中心化的可能性，並有助於將安全性轉變為工程團隊和安全團隊之間的共同責任。

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

5

軟件供應鏈安全不再隱匿於水面之下

影響

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

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

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

想法

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

請關註這一領域的新興公司。正如我之前所說的，救兵正在路上。Chainguard 公司最近獲得瞭一筆融資，它的經驗豐富的團隊正在開發一款創新的產品。

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

6

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

影響

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

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

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

想法

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

解決辦法之一是使用秘鑰管理服務。現在已經有一些不錯的產品，包括 CyberArk Conjur、HashiCorp Vault 和 1Password Secrets Automation。GitHub 也在 Actions 工作流中建立瞭基本的秘鑰管理權限。

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

7

保護數據和保護代碼同樣重要

影響

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

隱私法規也為人為錯誤帶來瞭懲戒。這提升瞭數據保護標準，確保隻有需要訪問權限的人才能訪問數據。如果可以避免，就不應該讓開發團隊過多地訪問生產數據。

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

想法

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

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

8

我們正處於認證和授權的黃金時代

影響

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

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

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

想法

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

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

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

9

安全性高度依賴於第三方

影響

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

當然，潛在風險和影響的程度和規模因服務而異。雲服務的漏洞會對整個科技行業造成宏觀風險和影響，Mailchimp 之類的服務則處於中位。他們有很多客戶，但在最近的案例中，隻出現瞭少數被攻擊的情況。

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

我們仍然對安全負有重大責任，盡管在一定程度上超出瞭我們的可控范圍。關鍵在於我們要意識到這一趨勢已經發展到何種程度，以及我們對第三方的依賴程度。我們需要承認現實，這樣才能確保采取正確的步驟來保護自己。

想法

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

將確保安全視為購買第三方服務的組成部分。在使用服務之前對安全進行評估要比在將其深深嵌入到應用程序中之後進行評估要容易得多。或者更糟的是，在第三方服務被攻擊後，你要承擔後果。

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

10

對於很多用戶來說，安全是一個特性

影響

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

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

想法

實施信任和安全流程，即使是最基本的措施，有總比沒有好。但如果你的客戶有更高的期望，你就應該準備構建更健壯的特性。

圍繞安全和隱私拓展公司透明度的界限。像 Trustpage 和 Cinder 這樣的公司正在構建一種新的信任和透明產品，如果實施得當，它就是一種可以讓你的公司和產品變得與眾不同的戰略優勢。

https://strategyofsecurity.com/what-developers-need-to-know-about-the-strategy-of-security/