Fortify SCA產品組件及功能

Source

Code

Analysis

Engine（源代碼分析引擎）

數據流分析引擎-----跟蹤,記錄并分析程序中的數據傳遞過程的安全問題

語義分析引擎-----分析程序中不安全的函數,方法的使用的安全問題

結構分析引擎-----分析程序上下文環境,結構中的安全問題

控制流分析引擎-----分析程序特定時間,狀態下執行操作指令的安全問題

配置分析引擎

-----分析項目配置文件中的敏感信息和配置缺失的安全問題

特有的X-Tier?跟蹤qi-----跨躍項目的上下層次,貫穿程序來綜合分析問題

Secure

Coding

Rulepacks

?（安全編碼規則包）

Audit

Workbench（審查工作臺）

Custom

Rule

Editor

&

Custom

RuleWizard(規則自定義編輯器和向導)

DeveloperDesktop

(IDE

插件）

FortifySCA 分析安全漏洞的標準

OWASP top 2004/2007/2010/2013/2014(開放式Web應用程序安全項目)

2. PCI1.1/1.2/2.0/3.0(國際信用ka資料安全

技術PCI標準)

3. WASC24+2(Web應用安全聯合威脅分類)

4. NIST SP800-53Rev.4(美國與技術研究院)

5. FISMA(聯邦信息安全管理法案)

6. SANS Top25 2009/2010/2011(IT安全與研究組織)

7. CWE(MITRE公司安全漏洞詞典)

Fortify軟件

強化靜態代碼分析器

使軟件更快地生產

如何修正HP Fortify SCA報告中的弱點？

常見的靜態程序碼掃描工具（又稱原始碼檢測，白箱掃描），例如HP Fortify SCA，被許多企業用來提高資訊安全的透明度以及外部的法規遵循。但是拿到報告之后怎么辦呢？

對于許多開發者來說，HP Fortify SCA的報告被視為麻煩制造者，因為它們雖然指出了弱點（不論是真的或是誤報），但卻沒有提供任何修正這些弱點的方法。

有沒有簡單的方法能夠修正靜態程式碼掃描工具找到的弱點呢？

Lucent Sky AVM和靜態程序碼掃描工具一樣會指出弱點，同時提供即時修復 - 一段安全的程式碼片段，能夠直接插入程式碼中來修正跨站腳本（XSS），SQL注入和路徑處理這些常見的弱點。

以.NET（C＃和VB.NET）和Java應用程式來說，Lucent Sky AVM可以修正多達90％所找到的弱點。

一起使用HP Fortify SCA和Lucent Sky AVM

HP Fortify SCA只會告訴你弱點在哪里，而Lucent Sky AVM會指出它們的位置以及修正方式（并且實際為你修正他們，你喜歡的話）HP Fortify SCA是被設計來供資安人士使用，因此設計理念是找出大量的結果，再依賴資訊安全專家來移除其中的誤報.Lucent Sky AVM則是專注于找出會真正影響應用程式安全的弱點，并依照你或你的開發與資訊安全團隊的設定來可靠的修正這些弱點。你可以深入了解Lucent Sky AMV的修正流程。

Fortify軟件

強化靜態代碼分析器

使軟件更快地生產

強化SCA Eclipse修復插件

惠普企業HPE社區

下載

描述

發布

相似的項目

評測

聯系我們

描述

用于Eclipse的HPE Security Fortify修補插件（Eclipse Remediation Plugin）與HPE Security Fortify軟件安全中心配合使用，可以從Eclipse IDE向軟件安全分析添加補救功能。 Eclipse Remediation Plugin是一個輕量級的插件選項，用于不需要Audit Workbench和Eclipse Complete Plugin的掃描和審核功能的開發人員.Eclipse Remediation Plugin可以幫助開發人員快速輕松地了解所報告的漏洞并實施適當的解決方案。開發人員可以在Eclipse中編寫代碼時解決安全問題。您的組織可以使用軟件安全中心的Eclipse修復插件來管理項目，并向相關開發人員分配具體問題。

Fortify軟件

強化靜態代碼分析器

使軟件更快地生產

“將FINDBUGS XML轉換為HP FORTIFY SCA FPR | MAIN | CA特權身份管理員安全研究白皮書?

強化針對JSSE API的SCA自定義規則濫用

安全套接字層（SSL / TLS）是使用加密過程提供身份驗證，機mi性和完整性的廣泛使用的網絡安全通信協議。為確保該方的身份，必須交換和驗證X.509證書。一方當事人進行身份驗證后，協議將提供加密連接。用于SSL加密的算法包括一個安全的散列函數，保證了數據的完整性。

當使用SSL / TLS時，必須執行以下兩個步驟，以確保中間沒有人篡改通道：

證書鏈信任驗證：X.509證書指ding頒發證書的證書頒發機構（CA）的名稱。服務器還向客戶端發送中間CA的證書列表到根CA。客戶端驗證每個證書的簽名，到期（以及其他檢查范圍，例如撤銷，基本約束，策略約束等），從下一級到根CA的服務器證書開始。如果算法到達鏈中的后一個證書，沒有違規，則驗證成功。

主機名驗證：建立信任鏈后，客戶端必須驗證X.509證書的主題是否與所請求的服務器的完全限定的DNS名稱相匹配。 RFC2818規定使用SubjectAltNames和Common Name進行向后兼容。

當安全地使用SSL / TLS API并且可能導致應用程序通過受攻擊的SSL / TLS通道傳輸敏感信息時，可能會發生以下錯誤使用情況。

證明所有證書

應用程序實現一個自定義的TrustManager，使其邏輯將信任每個呈現的服務器證書，而不執行信任鏈驗證。

TrustManager [] trustAllCerts = new TrustManager [] {

新的X509TrustManager（）{

...

public void checkServerTrusted（X509Certificate [] certs，

String authType）{}

}

這種情況通常來自于自簽證書被廣泛使用的開發環境。根據我們的經驗，我們通常會發現開發人員完全禁用證書驗證，而不是將證書加載到密鑰庫中。這導致這種危險的編碼模式意外地進入生產版本。

當這種情況發生時，它類似于從煙霧探測器中取出電池：檢測器（驗證）將仍然存在，提供錯誤的安全感，因為它不會檢測煙霧（不可信方）。實際上，當客戶端連接到服務器時，驗證例程將樂意接受任何服務器證書。

在GitHub上搜索上述弱勢代碼可以返回13,823個結果。另外在StackOverflow上，一些問題詢問如何忽略證書錯誤，獲取類似于上述易受攻擊的代碼的回復。這是關于投piao答案建議禁用任何信任管理。