支持行業(yè)領(lǐng)先的編程語言

掃描采用開發(fā)人員首選的編程語言編寫的源代碼。支持 25 種語言，包括 Java、C#、C、C++、Swift、PHP。

找到更多缺陷，修復(fù)缺陷更輕松，構(gòu)建更優(yōu)質(zhì)的應(yīng)用

相信您的軟件可實(shí)現(xiàn)最佳效果：找到更多缺陷，減少誤報(bào)，獲得更準(zhǔn)確的信息、分析和修復(fù)指導(dǎo)。

數(shù)分鐘內(nèi)獲得結(jié)果

加速 DevOps，在數(shù)分鐘內(nèi)獲得掃描結(jié)果。免去部分或增量掃描的需要，可能忽略嚴(yán)重問題。

“我們支持無縫集成”

無縫集成開發(fā)人員使用的工具！集成對象包括 IDE、構(gòu)建工具、代碼庫、錯(cuò)誤跟蹤、票證系統(tǒng)以及可擴(kuò)展的 API，讓 appsec 前所未有的簡單。

行業(yè)領(lǐng)先的研究和支持

由規(guī)模最大的專業(yè)應(yīng)用程序安全研究團(tuán)隊(duì)提供技術(shù)支持。能夠跨越 25 種編程語言和 911,000 多個(gè)獨(dú)特的 API 檢測 763 種獨(dú)特的漏洞。

可在本地和云端使用或混合使用

在本地或云端開始使用，并可根據(jù)業(yè)務(wù)需求擴(kuò)展。集中管理本地和云端程序。

掃描采用開發(fā)人員首選的編程語言編寫的源代碼。支持 25 種語言，包括 Java、C#、C、C++、Swift、PHP。

通過集成 IDE 插件、源代碼庫、構(gòu)建服務(wù)器、持續(xù)集成 (CI/CD) 系統(tǒng)和 Rest API，為開發(fā)人員保證更高安全性。通過無縫管理整個(gè)現(xiàn)代 SDLC 的代碼發(fā)布，為所有開發(fā)流程提供支持，包括 DevOps、敏捷或瀑布式開發(fā)。

通過 IDE、錯(cuò)誤跟蹤系統(tǒng)集成和票證系統(tǒng)集成輕松掃描代碼、審計(jì)結(jié)果，并與開發(fā)人員一起開始修復(fù)問題。

清晰的漏洞描述、具有代碼行細(xì)節(jié)的證據(jù)以及特定于編程語言的建議可以使開發(fā)人員更容易理解和修復(fù)漏洞。

客戶評(píng)價(jià)

Fortify 幫助我們在產(chǎn)品上市前發(fā)現(xiàn)和修復(fù) Vital Images 醫(yī)療成像軟件中的安全漏洞。它直接負(fù)責(zé)改進(jìn)軟件安全防衛(wèi)。

Tim Dawson - 高級(jí)軟件工程總監(jiān)

Fortify 根據(jù)其對我們軟件安全架構(gòu)和應(yīng)用程序代碼的分析，幫助我們建立了安全開發(fā)實(shí)踐。我們將繼續(xù)使用 Fortify 軟件在我們所有軟件生命周期對其進(jìn)行測試，確保軟件在全周期保證安全。

Luc Porchon - 銀行應(yīng)用項(xiàng)目經(jīng)理

Parkeon

行政支持和業(yè)務(wù)支持對我們的成功尤為重要。開發(fā)和安全共同前進(jìn)，確保我們?yōu)榭蛻艉蜆I(yè)務(wù)所做的工作和努力是正確的，這點(diǎn)非常關(guān)鍵。發(fā)現(xiàn)開發(fā)過程中的漏洞，教育開發(fā)人員在開展工作時(shí)考慮“安全”問題，正在改變我們的工作和交付方式。這一征途是一次莫大的團(tuán)隊(duì)成功，讓我們能夠與 Fortify 形成伙伴關(guān)系，對敏捷思維進(jìn)行文化變革，同時(shí)為未來創(chuàng)造更好、可持續(xù)發(fā)展的流程。

Jennifer Cole - 前任首席信息安全官

ServiceMaste

理論上來說，安全防御是需要進(jìn)行縱深防御，而不僅僅是單單最外層一層進(jìn)行防御。 首先最外層肯定是要處理這些數(shù)據(jù)驗(yàn)證問題，其次各層系統(tǒng)之間的信任問題，最好也需要有相關(guān)的安全措施。但是由于成本等，Secure in depth 這個(gè)，實(shí)際和理論差距很大，SQL 注入問題直接由數(shù)據(jù)庫實(shí)現(xiàn)，但是最終由于各種原因，數(shù)據(jù)庫這邊對 SQL 注入并未處理，仍然堅(jiān)持自己只堅(jiān)持?jǐn)?shù)據(jù)庫的功能，注入這種問題并不打算處理，安全的問題，很大程度上是信任的問題。所以中間件說他信任上層應(yīng)用的數(shù)據(jù)。那么實(shí)際上要去研究下上層應(yīng)用是否都是值得信任的。如果是復(fù)雜的系統(tǒng)，甚至有提供給第三方的，很難保證所有的外界輸入都已經(jīng)被妥善處理 。但是對于中間件和數(shù)據(jù)庫來說無法區(qū)分執(zhí)行的命令是攻擊命令還是正常命令。這時(shí)候 rasp 這種東西就上了，這個(gè)情況很像消防制度、煙霧報(bào)警器、消防員滅火三者的關(guān)系。因?yàn)閷τ诓煌膽?yīng)用來說需要執(zhí)行的命令是不同的，比如一個(gè)數(shù)據(jù)庫管理的軟件，就是要傳送 SQL 指令的，這時(shí)候就沒法過濾或者參數(shù)化。所以有時(shí)候這理論和實(shí)際理想情況差別很大。只能說是結(jié)合具體場景具體分析。一般也就是最多在前面 2、3 層應(yīng)用都要求對輸入進(jìn)行處理，再后面的系統(tǒng)，也是沒法再要求了。如果外層僅僅是個(gè)別自己可信任的應(yīng)用提供數(shù)據(jù)給中間件，那么就實(shí)際效果來看，中間件不愿意處理也說的過去。但是如果外層太多，就很難控制的住了。而且就咱們安全來說，能集中化處理的，就盡量集中化處理，不然不管是工作量，還是出問題的概率，都不好辦了。舉個(gè)最簡單的例子，某個(gè)系統(tǒng)對外提供一個(gè)接口，那么如果外層就 1、2 個(gè)系統(tǒng)用，那么實(shí)際效果來看，那 1、2 個(gè)系統(tǒng)中都對數(shù)據(jù)進(jìn)行了正確驗(yàn)證，接口這邊即使不驗(yàn)證，也是安全的。但是如果外層有幾十個(gè)，甚至更多應(yīng)用來用，或者說以后調(diào)用的數(shù)量擴(kuò)展了，那么接口這邊如果不做集中化的驗(yàn)證，那就很復(fù)雜了（《阿里巴巴 Java 開發(fā)手冊》要求對接口全部做驗(yàn)證》）。靈活，易用和安全，側(cè)重點(diǎn)取個(gè)平衡。

SDL 推行

如果要是沒有上面高層的強(qiáng)力支持，很難推下去的，阻力太大。開發(fā)基本不關(guān)心安全不安全，關(guān)心的是自己的任務(wù)能不能即使完成，pm 也是更關(guān)注項(xiàng)目進(jìn)度。而安全通常會(huì)給項(xiàng)目帶來額外的資源消耗，無論是人力還是時(shí)間。而互聯(lián)網(wǎng)公司有很鮮明的特點(diǎn)： 1. 開發(fā)周期快 2. 產(chǎn)品開發(fā)多 3. SDL 人員少 完整的 SDL 流程，恐怕是行不通的，SDL 基本上可以說是 100% 會(huì)被整個(gè)開發(fā)團(tuán)隊(duì)反感，我們工作接觸多的 code review 和開發(fā)的 code review 還不是一回事，門檻更高，而且由于工具的太過于昂貴，一般公司沒有設(shè)立相應(yīng)的職位或者職位繼續(xù)不下去，從流程上看可以看看http://www.owasp.org.cn/owasp-project/download/owasp-samm samm 源碼審計(jì)推進(jìn)分步驟，似乎也挺適合互聯(lián)網(wǎng)公司的，是個(gè)非大型專業(yè)轉(zhuǎn)件公司版的微軟 SDL，其實(shí)流程和要求和 SDL 已經(jīng)差別不大了，還是 1. 人員要求高 2. 成本大，和 SDLC 一樣的缺點(diǎn)，它好在于有三個(gè)等級(jí)，可以慢慢一步步提高，而 SDL 則直接一步到位。目前的情況，其實(shí) SDL 很難做到位，雖然一直在做，疲于數(shù)據(jù)安全檢測、漏洞審計(jì)、修復(fù)、閉環(huán)。主要是項(xiàng)目周期短，發(fā)布快，項(xiàng)目又多，安全人員少，只能盡量走自動(dòng)化路線，但是像漏洞和代碼分析，架構(gòu)設(shè)計(jì)安全審計(jì)這些，好多東西自動(dòng)化目前還無法辦到。SDL 除非是公司有足夠高的層次支持，使之成為像軟件開發(fā)流程那樣的基本工作流程才行。這里分為兩種情況，將安全作為產(chǎn)品的基本需求特性，賣軟件的廠商，另外一種是開發(fā)的產(chǎn)品自用，兩者對于安全性的初心是不一樣的。

國內(nèi)外區(qū)別

國內(nèi)做安全是與國外相比是歐洲他們那邊罰的太狠了，歐洲是相當(dāng)于根據(jù)漏洞產(chǎn)生的數(shù)據(jù)、隱私安全方面的影響，繼而影響推動(dòng)提升源碼的安全性，一則是法律和罰款，人家有官方機(jī)構(gòu)，每年都要進(jìn)行 PCI 的審計(jì)，二則是普通人對于隱私、自由方面十分看重，國內(nèi)的隱私保護(hù)其實(shí)都是為了商業(yè)，似乎并不是為了客戶和法律。而且國外還有各種審計(jì)機(jī)構(gòu)要審計(jì)，所以不得不重視，不得不嚴(yán)格，代碼審計(jì)畢竟不是漏洞挖掘工具，發(fā)現(xiàn)問題進(jìn)而驗(yàn)證、推動(dòng)整個(gè)占了安全人員很大的時(shí)間。至于建模、攻擊面分析，開發(fā)人員又不會(huì)，所以等于沒有。這方面是國內(nèi)外都遇到的問題。
在 GDPR 方面，分為隱私要求和安全要求：在評(píng)估階段

• 發(fā)現(xiàn)并分類個(gè)人數(shù)據(jù)資產(chǎn)和受影響的系統(tǒng)

• 識(shí)別訪問風(fēng)險(xiǎn)，通過設(shè)計(jì)支持隱私。

  在設(shè)計(jì)階段

  • 創(chuàng)建安全參考架構(gòu)

  • 設(shè)計(jì)適合風(fēng)險(xiǎn)的 TOM（如加密，偽化，訪問控制，監(jiān)控）

  在數(shù)據(jù)控制層面

  • 實(shí)施隱私增強(qiáng)控制（例如，加密，標(biāo)記，動(dòng)態(tài)屏蔽）

  • 代碼防御原則理論上來說，安全防御是需要進(jìn)行縱深防御，而不僅僅是單單最外層一層進(jìn)行防御。 首先最外層肯定是要處理這些數(shù)據(jù)驗(yàn)證問題，其次各層系統(tǒng)之間的信任問題，最好也需要有相關(guān)的安全措施。但是由于成本等，Secure in depth 這個(gè)，實(shí)際和理論差距很大，SQL 注入問題直接由數(shù)據(jù)庫實(shí)現(xiàn)，但是最終由于各種原因，數(shù)據(jù)庫這邊對 SQL 注入并未處理，仍然堅(jiān)持自己只堅(jiān)持?jǐn)?shù)據(jù)庫的功能，注入這種問題并不打算處理，安全的問題，很大程度上是信任的問題。所以中間件說他信任上層應(yīng)用的數(shù)據(jù)。那么實(shí)際上要去研究下上層應(yīng)用是否都是值得信任的。如果是復(fù)雜的系統(tǒng)，甚至有提供給第三方的，很難保證所有的外界輸入都已經(jīng)被妥善處理 。但是對于中間件和數(shù)據(jù)庫來說無法區(qū)分執(zhí)行的命令是攻擊命令還是正常命令。這時(shí)候 rasp 這種東西就上了，這個(gè)情況很像消防制度、煙霧報(bào)警器、消防員滅火三者的關(guān)系。因?yàn)閷τ诓煌膽?yīng)用來說需要執(zhí)行的命令是不同的，比如一個(gè)數(shù)據(jù)庫管理的軟件，就是要傳送 SQL 指令的，這時(shí)候就沒法過濾或者參數(shù)化。所以有時(shí)候這理論和實(shí)際理想情況差別很大。只能說是結(jié)合具體場景具體分析。一般也就是最多在前面 2、3 層應(yīng)用都要求對輸入進(jìn)行處理，再后面的系統(tǒng)，也是沒法再要求了。如果外層僅僅是個(gè)別自己可信任的應(yīng)用提供數(shù)據(jù)給中間件，那么就實(shí)際效果來看，中間件不愿意處理也說的過去。但是如果外層太多，就很難控制的住了。而且就咱們安全來說，能集中化處理的，就盡量集中化處理，不然不管是工作量，還是出問題的概率，都不好辦了。舉個(gè)最簡單的例子，某個(gè)系統(tǒng)對外提供一個(gè)接口，那么如果外層就 1、2 個(gè)系統(tǒng)用，那么實(shí)際效果來看，那 1、2 個(gè)系統(tǒng)中都對數(shù)據(jù)進(jìn)行了正確驗(yàn)證，接口這邊即使不驗(yàn)證，也是安全的。但是如果外層有幾十個(gè)，甚至更多應(yīng)用來用，或者說以后調(diào)用的數(shù)量擴(kuò)展了，那么接口這邊如果不做集中化的驗(yàn)證，那就很復(fù)雜了（《阿里巴巴 Java 開發(fā)手冊》要求對接口全部做驗(yàn)證》）。靈活，易用和安全，側(cè)重點(diǎn)取個(gè)平衡。

    SDL 推行

    如果要是沒有上面高層的強(qiáng)力支持，很難推下去的，阻力太大。開發(fā)基本不關(guān)心安全不安全，關(guān)心的是自己的任務(wù)能不能即使完成，pm 也是更關(guān)注項(xiàng)目進(jìn)度。而安全通常會(huì)給項(xiàng)目帶來額外的資源消耗，無論是人力還是時(shí)間。而互聯(lián)網(wǎng)公司有很鮮明的特點(diǎn)： 1. 開發(fā)周期快 2. 產(chǎn)品開發(fā)多 3. SDL 人員少 完整的 SDL 流程，恐怕是行不通的，SDL 基本上可以說是 100% 會(huì)被整個(gè)開發(fā)團(tuán)隊(duì)反感，我們工作接觸多的 code review 和開發(fā)的 code review 還不是一回事，門檻更高，而且由于工具的太過于昂貴，一般公司沒有設(shè)立相應(yīng)的職位或者職位繼續(xù)不下去，從流程上看可以看看http://www.owasp.org.cn/owasp-project/download/owasp-samm samm 源碼審計(jì)推進(jìn)分步驟，似乎也挺適合互聯(lián)網(wǎng)公司的，是個(gè)非大型專業(yè)轉(zhuǎn)件公司版的微軟 SDL，其實(shí)流程和要求和 SDL 已經(jīng)差別不大了，還是 1. 人員要求高 2. 成本大，和 SDLC 一樣的缺點(diǎn)，它好在于有三個(gè)等級(jí)，可以慢慢一步步提高，而 SDL 則直接一步到位。目前的情況，其實(shí) SDL 很難做到位，雖然一直在做，疲于數(shù)據(jù)安全檢測、漏洞審計(jì)、修復(fù)、閉環(huán)。主要是項(xiàng)目周期短，發(fā)布快，項(xiàng)目又多，安全人員少，只能盡量走自動(dòng)化路線，但是像漏洞和代碼分析，架構(gòu)設(shè)計(jì)安全審計(jì)這些，好多東西自動(dòng)化目前還無法辦到。SDL 除非是公司有足夠高的層次支持，使之成為像軟件開發(fā)流程那樣的基本工作流程才行。這里分為兩種情況，將安全作為產(chǎn)品的基本需求特性，賣軟件的廠商，另外一種是開發(fā)的產(chǎn)品自用，兩者對于安全性的初心是不一樣的。

    國內(nèi)外區(qū)別

    國內(nèi)做安全是與國外相比是歐洲他們那邊罰的太狠了，歐洲是相當(dāng)于根據(jù)漏洞產(chǎn)生的數(shù)據(jù)、隱私安全方面的影響，繼而影響推動(dòng)提升源碼的安全性，一則是法律和罰款，人家有官方機(jī)構(gòu)，每年都要進(jìn)行 PCI 的審計(jì)，二則是普通人對于隱私、自由方面十分看重，國內(nèi)的隱私保護(hù)其實(shí)都是為了商業(yè)，似乎并不是為了客戶和法律。而且國外還有各種審計(jì)機(jī)構(gòu)要審計(jì)，所以不得不重視，不得不嚴(yán)格，代碼審計(jì)畢竟不是漏洞挖掘工具，發(fā)現(xiàn)問題進(jìn)而驗(yàn)證、推動(dòng)整個(gè)占了安全人員很大的時(shí)間。至于建模、攻擊面分析，開發(fā)人員又不會(huì)，所以等于沒有。這方面是國內(nèi)外都遇到的問題。
    在 GDPR 方面，分為隱私要求和安全要求：在評(píng)估階段

    • 發(fā)現(xiàn)并分類個(gè)人數(shù)據(jù)資產(chǎn)和受影響的系統(tǒng)

    • 識(shí)別訪問風(fēng)險(xiǎn)，通過設(shè)計(jì)支持隱私。

      在設(shè)計(jì)階段

      • 創(chuàng)建安全參考架構(gòu)

      • 設(shè)計(jì)適合風(fēng)險(xiǎn)的 TOM（如加密，偽化，訪問控制，監(jiān)控）

      在數(shù)據(jù)控制層面

      • 實(shí)施隱私增強(qiáng)控制（例如，加密，標(biāo)記，動(dòng)態(tài)屏蔽）

      • 實(shí)施安全控制; 緩解訪問風(fēng)險(xiǎn)和安全漏洞