一文掌握軟件安全必備技術 SAST
上一篇文章中，我們討論了軟件供應鏈的概念并了解到近年來軟件供應鏈安全事件層出不窮。為了保障軟件供應鏈安全，我們需要了解網絡安全領域中的一些主要技術。本篇文章將介紹其中一個重要技術——SAST。
當開發軟件時，我們必須同時考慮開發生命周期中的安全性和源代碼功能。人為錯誤是難免的，因此任何企業都會盡可能使用 SAST 工具，以最大限度地減少進入最終應用程序的代碼錯誤數量，并保護應用程序免受未來的網絡攻擊。?
讓我們一起看看 SAST 技術究竟是什么，從長遠來看，它如何幫助您的應用程序更安全，以及它如何影響企業網絡保護。
什么是 SAST？
靜態應用程序安全測試（Static Application Security Testing），也稱為靜態分析，它通過直接查看應用程序的源代碼發現各種安全漏洞，以避免企業損失。SAST 工具和掃描程序基本都是在應用程序代碼完全編譯之前使用，因此也可以將它們稱為“白盒”工具。
一般而言， SAST 技術在軟件開發周期的早期就被使用，并且可以在不運行代碼的情況下進行測試，這讓開發團隊得以在最終確定各種代碼特性和功能之前使用此類掃描工具。因此，被發現的任何安全問題都可以得到及時解決。任何漏洞都會在開發的早期被發現，所以應用程序的“破綻”或安全問題都難逃“法眼”。
實時反饋
一些 SAST 工具可以在開發人員編寫代碼時提供實時反饋，并且能夠在代碼傳遞到開發周期的下一階段之前修復各種問題。在掃描階段，SAST 掃描程序可以準確地指出應用程序架構代碼存在問題的位置。這讓有經驗的程序員解決問題時信手拈來，避免了花費數天或數周的時間研究代碼來識別漏洞的來源。
此外，大多數 SAST 技術允許開發人員自定義報告，這些報告可以通過第三方 dashboard 或其他應用程序導出和跟蹤。因此與其他類型的應用程序掃描技術相比，SAST 掃描工具在處理漏洞的解決方案要容易上手得多。但是在整個開發過程中，SAST 掃描工具必須在應用程序上運行多次。這要求開發人員將SAST工具的使用與開發生命周期和排期集成，而避免他們因為代碼中內置的安全漏洞而偏離開發軌道。
總之，SAST 工具可以幫助企業在開發階段保護其應用程序。如果使用得當，SAST 工具可以確保您的企業永遠不會啟動具有明顯安全問題或配置問題的應用程序。
SAST 的優勢
與 DAST 及其他類似技術相比，SAST 掃描程序和工具有很多優勢。
快速掃描
與許多其他應用程序安全工具相比，SAST 掃描程序可以在相對較短的時間內分析100%的應用程序代碼庫。實際上一些更高級的工具可以在短短幾分鐘內掃描多達數百萬行代碼。
這也讓開發人員能夠將 SAST 掃描與開發周期的其余部分無縫集成，從而無需將這部分任務安排到開發日程中，或在源代碼中花費大量時間查找安全漏洞。
SAST 工具比人工更準確
在閱讀數百萬行代碼時，與人工相比，機器總是更善于捕捉錯誤。實際 SAST 掃描程序更能夠自動識別某些漏洞，比如跨站腳本攻擊，緩沖區溢出和 SQL 注入漏洞，比人工更可靠、更高效。此外，能夠在開發周期中更快地識別和處理安全漏洞。
總之，企業能夠將人力轉移到編程或其他任務上，而不是進行耗時耗力的安全檢查。
實時報告
與 DAST 和其他工具相反，SAST 掃描程序會準確告訴您應用程序源代碼中的問題所在，讓您更及時解決問題。您和您的團隊從而不必花費大量時間去查找問題以及定位檢測到的安全漏洞的來源。
事實上，優秀的SAST掃描工具甚至會在程序員編寫代碼時直接顯示應用程序代碼庫中的問題。SAST掃描程序會在小錯誤被其他代碼掩蓋并變得難以檢測之前捕獲它們，從而減少整體開發時間。
多種編程語言和開發平臺兼容性
SAST 工具并不像 DAST 工具那樣通用，降低 SAST 掃描程序的使用門檻，能夠讓大多數主流編程語言和平臺得以使用適配的高質量掃描工具。因此，開發人員在開發過程中應該較容易為其應用程序找到合適的 SAST 掃描套件或漏洞檢測工具。
SAST 的短板
雖然 SAST 工具確實有很多優點，但同時也需要注意相應短板，避免使用錯誤的工具。
較高的誤報風險
關于 SAST 工具和掃描報告，開發人員需要單獨查看每個標記的錯誤或漏洞。因為 SAST 工具的誤報率相對較高，有問題的掃描程序可能會將代碼的特定部分標記為錯誤。這無疑會降低開發速度。
報告有效期短
由于 SAST 工具僅生成靜態報告，因此這些報告也很快過期，特別是當與開發周期快或復雜性不斷增長的應用程序一起使用時。您需要在整個應用程序的開發周期中多次運行SAST掃描，來去捕獲無意中創建或忽略的新代碼錯誤以及安全漏洞。
此外，如果在開發周期的尾聲運行 SAST 掃描，則與該工具類型的初衷沖突，因為您將不得不返回到應用程序的代碼中，并且可能需要對代碼體系結構進行大幅度更改，以修復任何檢測到的問題。
未對運行漏洞進行分析
使用 SAST 工具時，應用程序需要處于靜止狀態或處于非活動狀態。正在運行或完全部署的應用程序，無法使用 SAST 掃描程序進行徹底檢查，換言之，這類工具不適合識別潛在黑客在實際攻擊期間可能試圖利用的某些類型的安全漏洞。
由此可以看出，SAST 掃描程序并不擅長發現復雜的安全漏洞，這些漏洞僅在應用程序通過其自己的代碼運行并同時與其他應用程序交互時才會出現。因此，某些漏洞（如不安全的反序列化）對于 SAST 工具來說很難檢測到。
不同編程語言需要特定工具
雖然大多數主流編程語言和開發平臺都有一個 SAST 掃描工具，但不同語言需要特定的掃描工具。?如果企業在使用多種語言開發不同應用程序，那么將需要多個 SAST 工具來單獨處理每個應用程序。這個過程耗時耗財。
SAST 和 DAST 之間的差異
動態應用程序安全測試（Dynamic Application Security Testing）在很多方面都與 SAST 技術相對應。實際這兩種類型的安全工具都強大且有效，但兩者都無法捕捉全部可能存在的安全漏洞。兩者應相互結合使用，以確保應用程序的整體安全性。
DAST 工具在掃描應用程序的安全漏洞時采用由外向內的方法。通過輸入特定的 URL（或 URL 列表），操作員可以使用 DAST 掃描程序檢查安全漏洞，并部署多個虛擬網絡攻擊來測試應用程序。?一旦檢測到缺陷，就可以生成報告以通知安全團隊潛在的問題。
DAST 工具無法告知開發人員錯誤出現的位置或原因。因此，開發人員必須查看代碼并利用其安全專業知識來辨別問題是什么以及如何解決它。這與 SAST 工具形成鮮明對比，SAST 工具能夠指出可能導致問題的任何有問題的代碼。
何時使用 SAST 工具？
DAST 工具可以在已部署或已完成的應用程序上運行。它們主要用于在軟件開發生命周期結束時查找安全漏洞，并且通常在早期開發會話中完成多次 SAST 掃描之后。這意味著檢測 DAST 漏洞花費的成本和時間都比 SAST 錯誤更多，但在完全部署之前發現這些漏洞依舊十分重要。
DAST 也很有用，因為它們可以發現動態和復雜的安全漏洞，并且在應用程序運行時進行分析，同時與網絡中的其他應用程序進行交互。這是 SAST 工具在掃描應用程序的靜態源代碼時根本無法做到的。
此外，DAST 工具通常具有讀取多種應用程序語言或開發平臺的能力。因此，單個 DAST 工具有時可以為整個企業提供服務，其中包含多個正在開發或即將部署的應用程序。
如何優雅地使用 SAST 工具？
高效運用 SAST，請記住以下步驟：
首先，選擇一個工具，并根據您使用的編程語言進行完善
確保該工具可以理解軟件使用的任何底層框架
創建掃描基礎架構并部署工具，最終確定許可要求
設置訪問控制，并保護部署工具所需的資源
根據需求修改 SAST 掃描工具附帶的控件
針對特定的安全漏洞來編寫新規則
載入任何應用程序和設置優先級前先掃描高風險應用程序
分析掃描結果，單獨檢查每個報告避免誤報
制定一個時間表，定期在軟件開發生命周期中運行 SAST工具，以最大限度地提高其效率
SAST 工具精選
優秀的 SAST 工具數不勝數。以下是我們精選的可能適合您的企業的 SAST 工具。
Veracode 靜態分析
此工具支持 SAST 功能、DAST 分析，以及軟件成分分析。這是一個一站式工具，無論使用什么語言或平臺，都可以處理您的所有安全和滲透測試需求。
此應用程序甚至包括 API 訪問，因此您可以根據需求自定義軟件。默認情況下，包括幫助您修復安全漏洞的專業提示。可以說是為開發人員量身定制的工具。
AppScan
這種 SAST 掃描技術允許組織實施可擴展的安全測試策略。如果您的企業將在未來幾年內快速增長，這對企業至關重要。該工具允許測試移動端、網頁端和開源軟件，并為多應用和多用戶部署提供各種管理和報告工具。這是一個非常靈活的工具，提供相對較低的誤報率和數據保護功能。唯一的缺點是其界面不那么直觀。
總 結
總之，SAST 技術是在部署之前測試應用程序的重要組成部分，也是確保為企業提供高質量軟件的重要工具。當與 DAST 技術結合使用時，SAST 工具能夠保護應用程序免受攻擊，并在部署后更好地促進整體應用程序運行。轉載自 SEAL安全
時至今日，絕大多數的開發者并不是從零開始進行軟件開發，而是在創建軟件時依賴第三方資源。通過使用預先構建的庫和開源組件，工程師們可以加快開發進程并且降低生產成本，從而快速將產品推向市場。
因此，企業需要意識到軟件并不完全在他們的掌控之中。那么是哪些流程、組件和工具構成了你所部署的軟件呢？
什么是軟件供應鏈？
“供應鏈”這一術語通常用于制造業，是指制作和分發一個產品的人員和流程。例如，一家造飛機的公司會自己制造一些部件，也會從其他公司購買和組裝部件。他們根據設計規格組裝零件，然后對新飛機進行測試。通過測試后，新飛機會被交付到航空公司和飛行員手中。
現代軟件的開發流程與此類似：一個軟件是由多個組件組成，涉及到多個開發人員、團隊和某家公司的內部與外部系統。并且像飛機一樣，軟件也需要通過壓力測試。
因此，我們將軟件供應鏈定義為在軟件開發中所涉及到的組件、開發流程以及投入生產和最終軟件產品分發的過程。
軟件供應鏈由什么構成？
上文中我們已經討論了軟件供應鏈的定義。構成軟件的諸多組件中，有部分依賴項并非由你的團隊開發：
硬件和基礎架構
操作系統
編譯器和編輯器
驅動和依賴項
開源腳本和打包好的軟件
代碼倉庫引擎、測試套件以及CI/CD工具
云服務和數據中心
同時，供應鏈會包含公司外部的人員配置，比如外包公司、咨詢師以及供應商等。因此，軟件供應鏈安全的首要關注點是將風險管理和網絡安全原則相結合，這一做法可以檢測到第三方組件給軟件帶來的風險，并將其最小化。
軟件供應鏈管理
在大型軟件的開發過程中會涉及到成千上百個組件、多個團隊的協同合作，因此會遇到諸多安全問題。進而可見性、明確的規范以及根據軟件開發進度進行持續的改善對于大型軟件開發至關重要。
1. 軟件材料清單
撰寫一份優秀的文檔絕非易事，但列出代碼中的第三方成分列表則是必須的，這可以讓開發人員對軟件中可能存在的風險有基本的了解。通過這一列表，能夠清楚地知道最新的安全新聞是否與軟件中的組件相關。
這些列表被稱為軟件材料清單，或 SBOM（另一個取自制造業的術語），它們由官方發布并且計算機可以直接對其進行處理。這些清單里詳細說明了軟件中的各種組件和依賴項。
除了可見性這一優勢外，構建這份清單還能夠與客戶建立信任，證明企業具備安全意識以及確保許可證的合規性。基于此，你不需要向客戶開放所有源代碼，同時可以根據需要與客戶分享他們所需要的信息。
2. 信息訪問管理（IAM）和數據治理
目前，軟件開發還是一個高度線性且類似于生產線的碎片化過程。現在，企業們正試圖消除這一障礙，并跨團隊整合工作流程，即 DevOps。開發和運維之間的合并意味著團隊之間的協作將持續增加，目前這樣的整合已在業界取得初步成效。
在急速變化的環境中，避免數據泄露或敏感信息的丟失比以往任何時候都更加重要。為了保護數據，公司需要實施強有力的 IAM 策略和數據治理程序。部分企業甚至采用 DevSecOps 的方式來確保協作中的安全性。
首當其沖：軟件供應鏈是惡意攻擊的首要目標
因為軟件由第三方組件構成，因此對軟件的攻擊已經轉移到對供應鏈的攻擊。針對 SolarWinds 的攻擊事件是絕佳佐證——通過對多個組件實施攻擊進入該公司的網絡和應用程序監控平臺，從而對使用該系統的 30000 多個組織造成影響。在進入系統之后，攻擊者將惡意代碼插入該公司的軟件中。當 SolarWinds 向其客戶發送更新時，無意中授予了對客戶賬戶的后門訪問權限，這使得黑客不僅可以訪問屬于 SolarWinds 的系統，還可以訪問每個安裝該更新的公司的系統。
針對開源項目的攻擊呈上升趨勢
研究顯示，黑客正積極瞄準開源組件以伺機進入軟件供應鏈。在過去的12個月內，針對開源工具的網絡攻擊增加了650%。
Sonatype在《2021年軟件供應鏈的現狀》報告中指出，傳統軟件供應鏈攻擊集中在公開披露的漏洞。在過去3年里攻擊者已經改變了攻擊策略并且頻繁向連接全球供應鏈的開源項目注入惡意代碼。
換言之，他們的目標是“上游”組件，或者是分發軟件工作流程和更新的服務。這會影響到大量位于下游的終端用戶，最終會牽涉到多家組織。
破壞軟件更新成為主要攻擊手段
通過破壞已經廣泛傳播的軟件更新，攻擊者可以獲取大量的系統訪問權限。例如，許多公司每月會定期發布新的安全補丁，這些補丁會被成千上百萬的開發者下載用于開發他們的項目或應用于 CI/CD 流水線中。如果攻擊者可以操縱其中一個更新，那么他們就可以輕松地獲取部署了該補丁的系統的訪問權限。
如何保障軟件供應鏈安全？
1. 快速響應漏洞
傳統軟件供應鏈攻擊仍然是一個令人擔憂的問題，公司在漏洞披露后處理漏洞的窗口期越來越窄。在漏洞出現后未能及時更新其應用程序的企業很有可能會輸給競爭對手。因此，IT團隊必須利用SCA測試工具來發現第三方代碼中的漏洞，并提出補丁和更新等修復措施。根據 Veracode 近期的《軟件安全狀況：開源軟件版本》報告發現，92%的庫缺陷都可以通過更新來修復。
2. 保持高度的供應鏈可見性
發現漏洞僅僅是成功的一半。在了解安全問題之后，開發者需要更新使用了該代碼的軟件，這需要保持對整個軟件供應鏈有高度的可見性。為了使你的應用程序的依賴關系有完整的可見性，你需要問自己一些問題：
開發生命周期的每一步都涉及什么？
外包員工是否擁有代碼權限？
誰安裝了軟件更新并且是如何安裝的？
企業應該審計其所有的應用程序以及授予內部和外部各方的訪問權限。理想情況下，這一切應該是有據可查的，并且是自動化的，所以當一個漏洞發生時，你可以迅速找出擁有該訪問權限的人員。
3. 組件黑名單機制
及時的溝通是防止攻擊的關鍵。一旦開發人員和社區成員發現有害的組件，這些項目就不能進入生產。團隊可以標記出問題組件，并建立一個框架來跟蹤和防止它們重新進入軟件開發流程中。
4. 更新和監控代碼
當代碼停止更新或處于 EOL（end-of-life）階段時，就無法將其留在應用程序中。因此，必須保證軟件所采用的組件代碼仍然被社區廣泛使用并且有技術支持。
將過時的代碼留在應用程序中會導致漏洞，進而影響整個軟件供應鏈。因此，一旦你得知某個代碼庫或項目要關閉或停止維護，就必須將其移除或使用替代項目。
5. 確保特權訪問管理的安全
一旦攻擊者獲得系統訪問權限，他們將會試圖通過網絡橫向移動來找到特權賬戶。一旦成功，他們將使用該賬戶來訪問敏感數據或控制其他系統。
因此，安全團隊應該密切監控特權賬戶的異常活動——密碼變更、登錄活動以及權限更改等，并且應該及時響應。假設一個域名管理員賬戶多次嘗試輸入錯誤的密碼，那么安全團隊應該立即開始進行調查并且鎖定該賬號，直到他們確定這只是一次合法的行為。
管理員應該采用最小權限原則——只有在必要時才應授予高等級的訪問權限。系統管理員應該使用自動化和配置管理工具來控制和監控賬戶管理。這就使得人為干預的空間大大縮小了。
總 結
企業必須意識到現在他們時刻生活在網絡攻擊的威脅中，這是當前環境下的全新挑戰。而軟件供應鏈一旦遭遇攻擊，將會為企業帶來重大的損失。要避免此類攻擊，需要企業安全團隊了解整個軟件供應鏈，審計軟件所依賴的第三方，掃描軟件組件的漏洞，并且有一個強有力、可執行的軟件供應鏈管理計劃。
參考鏈接：
State of Software Security v11: Open Source Edition
https://info.veracode.com/fy22-state-of-so...Software Supply Chain Management: An Introduction
https://www.sonatype.com/resources/softwar...2021 State of the Software Supply Chain Report
https://www.sonatype.com/resources/state-o...
