WPF 安全性策略 – 安全性工程
「高可信度電腦運算」(Trustworthy Computing) 是 Microsoft 致力達到的目標之一，旨在確保產生安全的程式碼。 高可信度電腦運算的重要元素為 Microsoft Security Development Lifecycle (SDL)。 SDL 是一項可與標準工程程序搭配使用，以加快安全程式碼產生速度的工程做法。 SDL 分十個階段，其中結合了標準化、可測量性和其他結構的最佳做法，這些階段包括：
安全性設計分析
工具式品質檢查
滲透測試
最終安全性檢閱
產品發行後安全性管理
WPF 內容
WPF 工程小組不僅會套用 SDL，也會加以擴充，而這兩個動作主要涵蓋下列方面：
將威脅模型化
安全性分析和編輯工具
測試技術
重要程式碼管理
將威脅模型化
威脅模型是 SDL 的核心元件，可彙總系統的整體設定來判斷潛在的安全性弱點。 識別弱點後，威脅模型還會確保是否已有適當的防患措施。
以雜貨店為例，威脅模型大致包含下列主要步驟：
識別資產。 雜貨店的資產可能包括員工、保險箱、收銀機和存貨。
列舉進入點。 雜貨店的進入點可能包括前後門、窗戶、卸貨區和空調設備。
調查經由進入點對資產發動的攻擊。 小偷可能會經由「空調」的通風口來竊取雜貨店的「保險箱」資產；空調設備的螺絲可能未鎖緊，而使保險箱可由此處運出店外。
整個 WPF 都會套用威脅模型，其分析範圍涵蓋：
XAML 剖析器 (Parser) 如何讀取檔案、將文字對應至對應的物件模型類別，以及建立實際程式碼。
視窗控制代碼 (Window Handle) (hWnd) 如何建立、傳送訊息，以及用以呈現視窗內容。
資料繫結 (Data Binding) 如何取得資源以及與系統互動。
在開發過程中，這些威脅模型對於識別安全性設計需求與威脅防患措施而言十分重要。
來源分析和編輯工具
除了 SDL 的手動安全性程式碼檢閱項目以外，WPF 小組也會使用多種可分析及編輯來源的工具，以減少安全性弱點。 他們所使用的來源工具範圍很廣泛，其中包括：
FXCop：可尋找 Managed 程式碼中的常見安全性問題，包括繼承規則、程式碼存取安全性做法，以及安全地與 Unmanaged 程式碼互動的方式。 請參閱 FXCop (英文)。
Prefix/Prefast：可尋找 Unmanaged 程式碼中的安全性弱點與常見安全性問題，例如緩衝區滿溢 (Buffer Overrun)、格式字串問題和錯誤檢查等。
禁止的 API：可搜尋原始程式碼，以識別不慎使用已知會造成安全性問題的功能 (例如 strcpy) 的情形。 這些功能一經識別後，即會被較安全的替代項目所取代。
測試技術
WPF 使用多種安全性測試技術，包括：
白箱測試：測試人員先檢視原始程式碼，然後建置攻擊測試。
黑箱測試：測試人員先檢查 API 與功能以嘗試找出安全性弱點，然後嘗試對產品發動攻擊。
從其他產品回復安全性問題：適當時會從相關產品測試安全性問題。 例如，目前已針對 Internet Explorer 識別出約六十個安全性問題，並已測試它們對 WPF 的適用性。
透過檔案模糊測試的工具式滲透測試：檔案模糊測試 (File Fuzzing) 是指測試各種輸入來利用檔案讀取器的輸入範圍。 在 WPF 中使用此技術的範例之一為檢查影像解碼程式碼中的失敗。
重要程式碼管理
對於 XAML browser applications (XBAPs)，WPF 會利用可對提升權限的重要安全性程式碼進行標記與追蹤的 .NET Framework 支援，建置安全性沙箱 (請參閱 WPF 安全性策略 – 平台安全性的＜重要安全性方法＞)。 重要安全性程式碼的安全性需求很高，因此應受到更深一層的來源管理控制與安全性稽核。 約有 5% 至 10% 的 WPF 含有重要安全性程式碼，此程式碼由專屬的檢閱小組負責檢閱。 原始程式碼與簽入程序的管理方式為：追蹤重要安全性程式碼，並將每個重要實體 (亦即 含有重要程式碼的方法) 對應至簽核狀態。 簽核狀態包含一名或多名檢閱者的名稱。 每天建置的 WPF 都會比較此重要程式碼與先前組建中的程式碼，以檢查是否有未經核准的變更。 如果工程師未經檢閱小組的核准即修改了重要程式碼，則會立即識別這個程式碼並加以修正。 這個程序可以對 WPF 沙箱程式碼執行及維持特別高度的檢查。