靜態應用程式安全測試

靜態應用程式安全測試（Static application security testing）簡稱SAST，是透過審查程式原始碼來識別漏洞，提昇軟體安全性的作法。早在電腦問世時，就已有靜態程式分析的作法。自從1998年起，SQL注入的攻擊方式開始出現在公眾的討論中，而網路應用程式整合了JavaScript及Adobe Flash Player，因此從90年代末開始，用靜態程式分析進行安全測試的作法也開始普及。

靜態應用程式安全測試的作法和動態應用程式安全測試（DAST）的黑盒測試工具不同，DAST是針對應用程式的功能，而SAST是白盒測試，著重在應用程式的程式碼本身。
SAST工具會掃描應用程式以及其元件的程式碼，確認其軟體及架構中是否有安全漏洞。
靜態分析工具約可偵測到50%程式的安全漏洞。

在软件开发过程中，靜態應用程式安全測試可以在開發過程的早期，在程式碼階段進行，也可以在所有的程式碼及軟體元件放在一致的測試環境時再測試。此一技術也用在軟體品質保證上，不過會產生許多的假警報，因此也讓軟體開發者不願導入此一測試

SAST工具可以整合到開發流程中，幫助開發團隊，讓他們主要專注在開發及交付對應需求規格的軟體。SAST工具像其他的安全工具一様，著重在減少應用程式無法正常運作的風險，也避免應用程式中儲存的隱私資料不會被破壞或是洩漏。

簡介
應用程式的安全測試可以分為三種：除了靜態應用程式安全測試（SAST）外，還有動態應用程式安全測試（DAST），以及合併上述兩者的互動式應用程式安全測試（IAST）。

靜態分析工具會以語法來檢查程式碼，在原始碼中依固定模式或是公式來確認。理論上，靜態分析工具也可以檢查編釋後的程式。其技術是以程式的instrumentation為基礎，會比對編釋後的元件以及元件的原始碼，以識別問題。
靜態分析可以人工進行，像是為了代码审查或是為了不同目的（包括軟體安全）的，但相當花時間。

SAST工具的準確度會受到分析的範圍，識別漏洞的技術而定。以下是幾種不同層次的分析：
 函式層級：一連串的指令。
 檔案層級或是類層級：可擴展的程式模板。
 應用程式層級：一個程式或是一組的程式。

分析的範圍會決定其準確度，以及用上下文資訊偵測漏洞的能力。

在函式層級的常見技術，是創建控制資料流動程式的抽象語法樹。

從1990年代後期開始，商業模式的變化也讓軟體開發開始轉向元件化，開發團隊的組織和流程也促使這樣的轉變。隨著資料流在應用程式的各元件之間（或是各應用程式之問）流動，就需要在呼叫程式時加入特定程序來「消毒」，也要避免程式中的資料被污染。

網頁應用程式的興起，更突顯了測試的重要性。Verizon Data Breach 2016年指出，40%的資料泄露是和網頁應用程式的漏洞有關。網路安全的威脅有來自外部的，目前也開始關注內部的威脅。Clearswift Insider Threat Index（CITI）指出，2015年的問卷的回覆者中，有92%在過去一年內曾遭受過IT事件或是網路安全事件，而有72%的資料外泄是由公司或組織內部人士發起。Lee Hadlington將內部威脅分為三類：惡意、意外及未蓄意。手機軟體的爆炸性成長，因此需要在開發早期加入應用程式的安全機制，以減少惡意程式碼的散佈。
優點
漏洞在在軟體開發生命週期中的越早期進行修正，所花的成本越小。在開發階段修正的成本約是測試階段修正成本的十分之一，是量產階段修正成本的百分之一。
不論是在程式碼層次或是應用程式層次的SAST工具，都會自動執行，不需要與其互動。若將SAST工具整合在CI/CD（持續整合/持續發佈）流程內, 在SAST工具識別到嚴重的漏洞時，可以自動停止整合流程。

SAST工具會掃描所有的程式碼，程式碼的覆蓋率是100%。而DAST（動態應用程式安全測試）工具覆蓋了執行到的部份，應用程式中可能有些部份不會掃描到，也有可能在組態檔案中有些不安全的組態。

SAST工具會有品質測試或是架構測試的副加功能，軟體品質和安全性之間有直接的相關性。若軟體品質不好，其安全性也不會好。
缺點
即使軟體開發者都對SAST工具的使用有正面的回應，在導入時仍有許多不同的挑戰。

若是使用敏捷軟體開發，開發者一開始會注重在產品特徵以及產品交付，不會一開始就考慮安全性，因此早期導入SAST工具會出現許多的錯誤。

用SAST工具掃描較大的程式，可能會有上百個甚至成千個的漏洞警告，SAST工具會產生許多是偽陽性的假警報，增加分析的時間，並且降低程式設計師對此工具的信任。若有些漏洞的上下文是工具偵測不到的，那此一問題就更加嚴重了。

相關條目
安全測試
Lint
互動式應用程式安全測試
參考資料

分類:安全測試
Category:静态程序分析