近幾年,伴隨云計(jì)算、容器技術(shù)以及 DevOps 的普及,DevSecOps 作為糅合了開(kāi)發(fā)、安全及運(yùn)營(yíng)理念的全新方法,其關(guān)注熱度持續(xù)上升,并在全球范圍內(nèi)得到廣泛應(yīng)用。目前 IAST 被部分業(yè)內(nèi)人士看作一種“更適合 DevSecOps 流程構(gòu)建”的應(yīng)用程序安全檢測(cè)技術(shù),受到行業(yè)的更多關(guān)注。那么 IAST 是否真的更適合 DevSecOps 流程構(gòu)建?它能夠提供哪些核心能力和關(guān)鍵技術(shù),以及有哪些局限性,未來(lái)前景如何?對(duì)此,安全牛特別邀請(qǐng)到火線(xiàn)安全洞態(tài) IAST 產(chǎn)品負(fù)責(zé)人董志勇先生,就 IAST 和 DevSecOps 的相關(guān)話(huà)題展開(kāi)探討。
安全牛:
在您看來(lái),目前DevSecOps的痛點(diǎn)和難點(diǎn)是什么?
董志勇:
要了解 DevSecOps 的痛點(diǎn)和難點(diǎn),首先要弄明白 DevSecOps 到底是什么。根據(jù) Gartner 定義,DevSecOps(即 Development、Security 和 Operations)是指在不減少敏捷度和開(kāi)發(fā)者效率,或在不要求開(kāi)發(fā)者離開(kāi)現(xiàn)有工具鏈的情況下,將安全盡可能無(wú)縫、無(wú)感知地集成進(jìn) IT 和 DevOps 開(kāi)發(fā)中。
DevSecOps 有三個(gè)核心點(diǎn):一是便于集成,安全工具可以很方便的與現(xiàn)有的 IT 或 DevOps 流程對(duì)接和打通,這也是實(shí)現(xiàn) DevSecOps 的前提條件;二是無(wú)感知,要求安全工具對(duì)已有的 DevOps 流程不能產(chǎn)生任何的影響和干擾;三是在研發(fā)階段解決安全問(wèn)題,而不是像傳統(tǒng)開(kāi)發(fā)流程一樣,在軟件上線(xiàn)后由安全人員檢測(cè)問(wèn)題,再反饋給研發(fā)人員來(lái)解決問(wèn)題。問(wèn)題越早的檢測(cè)和修復(fù),企業(yè)的整體修復(fù)成本就越低,這也是 DevSecOps 的核心目的之一。目前來(lái)看,DevSecOps 在落地時(shí)遇到的主要痛點(diǎn)和難點(diǎn)也體現(xiàn)在這三個(gè)點(diǎn)上。
在 IAST 技術(shù)出現(xiàn)之前,我們熟知的安全技術(shù)是動(dòng)態(tài)應(yīng)用程序安全測(cè)試技術(shù)(DAST)和靜態(tài)應(yīng)用程序安全測(cè)試技術(shù)(SAST),這兩種技術(shù)在 DevSecOps 流程構(gòu)建中有其獨(dú)特優(yōu)勢(shì),但也有各自的不足。
DAST 的優(yōu)點(diǎn)是檢測(cè)結(jié)果準(zhǔn)確,因?yàn)樗玫氖钦鎸?shí) Payload(有效載荷),在運(yùn)行的應(yīng)用程序上直接做漏洞驗(yàn)證。DAST 發(fā)現(xiàn)問(wèn)題后,沒(méi)有代碼層的相關(guān)信息,這可能會(huì)給研發(fā)人員解決問(wèn)題帶來(lái)一定的成本,同時(shí)其檢測(cè)時(shí)間較長(zhǎng)、會(huì)產(chǎn)生臟數(shù)據(jù)等,不能滿(mǎn)足 DevSecOps 對(duì)無(wú)感的要求;SAST 的檢測(cè)結(jié)果對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)比較友好,但由于工具無(wú)法直接理解代碼,尤其是開(kāi)發(fā)人員在寫(xiě)代碼時(shí),引用的各種設(shè)計(jì)模式和新奇的技術(shù),這些原因都會(huì)導(dǎo)致 SAST 漏洞檢測(cè)的誤報(bào)率存在挑戰(zhàn),給到研發(fā)人員時(shí),不能保證報(bào)告的準(zhǔn)確性,影響使用。
安全牛:
IAST 可以幫助 DevSecOps 進(jìn)行哪些應(yīng)對(duì)呢?
董志勇:
IAST 是交互式應(yīng)用程序安全測(cè)試(Interactive Application Security Testing),是一種新的應(yīng)用程序安全測(cè)試方案,通過(guò)在服務(wù)端部署 Agent ,收集、監(jiān)控應(yīng)用程序運(yùn)行時(shí)的函數(shù)執(zhí)行、數(shù)據(jù)傳輸?shù)刃畔?然后根據(jù)污點(diǎn)跟蹤算法、值傳遞算法等一系列算法進(jìn)行漏洞的識(shí)別。
IAST 是一種應(yīng)用程序運(yùn)行時(shí)的漏洞檢測(cè)技術(shù),所以它具備了 DAST 中檢測(cè)結(jié)果準(zhǔn)確的特征;此外,IAST 采集到數(shù)據(jù)在方法內(nèi)部的流動(dòng)后,通過(guò)污點(diǎn)跟蹤算法來(lái)進(jìn)行漏洞檢測(cè),用算法來(lái)進(jìn)行漏洞檢測(cè),所以檢測(cè)結(jié)果也具備了 SAST 中全面性的特征。
同時(shí)因?yàn)?nbsp;IAST 安裝在應(yīng)用程序內(nèi)部,安全人員可以拿到類(lèi)似于源碼級(jí)漏洞報(bào)告,這種漏洞結(jié)果對(duì)于開(kāi)發(fā)人員很友好,可以方便開(kāi)發(fā)人員進(jìn)行漏洞修復(fù)。綜合來(lái)看,IAST 具有高檢出率、低誤報(bào)率、檢測(cè)報(bào)告詳細(xì)便于排查等一系列優(yōu)勢(shì),可以很好地在 DevSecOps 流程中解決痛點(diǎn)和難點(diǎn)。
安全牛:
基于 IAST 來(lái)構(gòu)建 DevSecOps 流程,所依靠的關(guān)鍵性技術(shù)有哪些?
董志勇:
對(duì)于這個(gè)問(wèn)題,我的理解是如何用 IAST 來(lái)構(gòu)建 DevSecOps ,或者說(shuō)是構(gòu)建 DevSecOps 流程時(shí),IAST 必須具備哪些功能才能支撐這個(gè)流程的構(gòu)建。我個(gè)人認(rèn)為大概有三點(diǎn)。第一點(diǎn),IAST 必須柔和地嵌入 DevOps 流程,即十分便利地與 CI/CD 流程對(duì)接,包括與 Jenkins 、Gitlab 等工具打通等;第二點(diǎn),當(dāng) IAST 和 DevOps 流程對(duì)接時(shí),需要做版本的控制,支持在 Agent 端直接指定項(xiàng)目名稱(chēng)和版本,進(jìn)行后續(xù)的版本跟蹤,以及版本的漏洞對(duì)比等;第三點(diǎn),IAST 可通過(guò)漏洞復(fù)測(cè)與回歸測(cè)試,驗(yàn)證此前發(fā)現(xiàn)的漏洞是否依舊存在。
安全牛:
相比較其他應(yīng)用程序安全測(cè)試模式,您認(rèn)為 IAST 的核心能力有哪些?其在具體的場(chǎng)景應(yīng)用中又會(huì)存在哪些局限性?
董志勇:
IAST 本質(zhì)是做漏洞檢測(cè),其核心能力主要包括四點(diǎn):一是實(shí)時(shí)的漏洞檢測(cè),保證不影響 DevOps 的原有效率;二是第三方組件的梳理和漏洞檢測(cè),保證應(yīng)用避免供應(yīng)鏈的攻擊;三是靈活的漏洞檢測(cè)邏輯,讓用戶(hù)在使用內(nèi)置檢測(cè)邏輯的同時(shí),很方便地配置出具有業(yè)務(wù)屬性的特定檢測(cè)邏輯,來(lái)做業(yè)務(wù)層面的漏洞檢測(cè);四是極低的運(yùn)營(yíng)成本,IAST 在企業(yè)內(nèi)部使用時(shí),一定是需要持續(xù)運(yùn)營(yíng)的,當(dāng)出現(xiàn)了 IAST 沒(méi)有覆蓋到的漏洞情況時(shí),可以用最低的成本來(lái)完善檢測(cè)策略和檢測(cè)邏輯,保證漏洞的檢出。
IAST 的局限性主要體現(xiàn)在 IAST 的內(nèi)置漏洞策略有限、且無(wú)業(yè)務(wù)屬性,無(wú)法保證檢測(cè)所有的安全風(fēng)險(xiǎn);推薦在上線(xiàn)前通過(guò)白盒、灰盒、黑盒、人工滲透測(cè)試一起來(lái)檢測(cè)漏洞,然后將 IAST 沒(méi)有覆蓋到的漏洞策略補(bǔ)充進(jìn)來(lái);上線(xiàn)后可通過(guò)外部的眾測(cè)、SRC 運(yùn)營(yíng)等手段,更全面地發(fā)現(xiàn)安全風(fēng)險(xiǎn),同時(shí)將漏洞策略補(bǔ)充到 IAST 中,做后續(xù)的自動(dòng)化測(cè)試。
安全牛:
目前國(guó)內(nèi) IAST 產(chǎn)品的代表類(lèi)型有哪些?從應(yīng)用的角度看其主要差異是什么?
董志勇:
根據(jù) Gatner 定義,IAST 特指被動(dòng)插樁的這種模式,但由于開(kāi)發(fā)難度等一系列原因,在國(guó)內(nèi)出現(xiàn)了一些臨時(shí)性的解決方案,如:將黑盒改造成 IAST ,另外也有將 RASP 與掃描器結(jié)合形成主動(dòng)插樁的方案。
主動(dòng)插樁的原理是在應(yīng)用程序上安裝 Agent,Agent 采集應(yīng)用程序從外部獲取數(shù)據(jù)的入口,以及最終觸發(fā)漏洞的關(guān)鍵位置信息,然后聯(lián)動(dòng)外部掃描器,把流量數(shù)據(jù)發(fā)到掃描器上,掃描器根據(jù)漏洞庫(kù),或者根據(jù)主動(dòng)式對(duì)應(yīng)的 POC 庫(kù),來(lái)做一些流量的重組、重放,實(shí)現(xiàn)對(duì)漏洞的檢測(cè)。它在檢測(cè)漏洞的時(shí)候,是看外部掃描器端重組的 POC 有沒(méi)有到達(dá)上次出現(xiàn)危險(xiǎn)的位置。
主動(dòng)式有很大的局限性:一,從整個(gè)行業(yè)來(lái)看,應(yīng)用的安全性越來(lái)越高,比如驗(yàn)證碼、數(shù)據(jù)包加密、防重放等一些安全措施越來(lái)越完善。在這樣的背景下,主動(dòng)式 IAST 依賴(lài)流量重放進(jìn)行漏洞檢測(cè),比如:滑動(dòng)驗(yàn)證碼場(chǎng)景下,IAST 無(wú)法重放流量,此時(shí),便無(wú)法檢測(cè)對(duì)應(yīng)位置的漏洞;二,主動(dòng)式 IAST 需要進(jìn)行流量重放,會(huì)產(chǎn)生大量的臟數(shù)據(jù),影響功能測(cè)試結(jié)果;三,應(yīng)用程序的技術(shù)架構(gòu)整體趨勢(shì)是向微服務(wù)、分布式等方向發(fā)展,在微服務(wù)中,服務(wù)間可能不用傳統(tǒng)的 Http 請(qǐng)求進(jìn)行通信,比如使用基于 TCP 協(xié)議的 RPC 請(qǐng)求。此時(shí),主動(dòng)式 IAST 無(wú)法發(fā)起 RPC 請(qǐng)求,也就無(wú)法進(jìn)行漏洞檢測(cè)。
被動(dòng)式 IAST 的檢測(cè)原理,是在應(yīng)用程序上安裝 Agent ,安全人員進(jìn)行正常的功能測(cè)試時(shí),外部會(huì)有一定的流量進(jìn)入。在這種模式下,所有進(jìn)來(lái)的流量數(shù)據(jù)都會(huì)被標(biāo)記為不可信,并分析不可信數(shù)據(jù)在內(nèi)部應(yīng)用程序中如何變化,如何流轉(zhuǎn),類(lèi)似于生物學(xué)上的基因傳遞流程。它只需要分析不可信數(shù)據(jù)在應(yīng)用程序內(nèi)部的變化情況,重點(diǎn)分析數(shù)據(jù)的流向和傳播,然后用“算法 + 數(shù)據(jù)流”進(jìn)行漏洞檢測(cè),根據(jù)不可信數(shù)據(jù)未經(jīng)任何有效處理直接到達(dá)危險(xiǎn)函數(shù)的方法,來(lái)判定漏洞是否存在,無(wú)需做流量重放。前文所提到的驗(yàn)證碼、數(shù)據(jù)包加密或者防重放場(chǎng)景,以及分布式、微服務(wù)的技術(shù)架構(gòu)下都可以使用被動(dòng)式 IAST 進(jìn)行漏洞檢測(cè)。
從整個(gè)行業(yè)趨勢(shì)上來(lái)說(shuō),應(yīng)用本身的安全性越來(lái)越高,只有被動(dòng)式 IAST 才能兼容所有的場(chǎng)景,在實(shí)現(xiàn)漏洞檢測(cè)的同時(shí),滿(mǎn)足 DevOps 流程下高效、準(zhǔn)確等要求,所以最佳選擇一定是被動(dòng)式 IAST 。
安全牛:
用戶(hù)在選擇 IAST 產(chǎn)品時(shí),應(yīng)從哪些維度進(jìn)行評(píng)估?
董志勇:
第一點(diǎn)是使用成本,它體現(xiàn)在幾部分,其一是產(chǎn)品在 Server 端的部署成本,其二是在 Server 端的升級(jí)成本,其三是當(dāng)把 Server 端部署和升級(jí)之后,Agent 在業(yè)務(wù)線(xiàn)上的推廣成本,或者 Agent 在使用過(guò)程中的升級(jí)成本等。所以整體來(lái)看,需要綜合考慮:Server 端的部署成本, Server 端的升級(jí)成本,Agent 端的部署升級(jí)成本以及 Agent 端的推廣成本。
第二點(diǎn)是漏洞檢測(cè)能力,建議直接把 IAST 部署到企業(yè)內(nèi)部真實(shí)業(yè)務(wù)線(xiàn)上試運(yùn)行兩到三個(gè)月。根據(jù)“是否檢測(cè)到漏洞,及漏洞檢測(cè)的準(zhǔn)確率”,對(duì)比哪款產(chǎn)品檢測(cè)效果更佳,這是最實(shí)際的評(píng)估方法。第三點(diǎn)是 IAST 的整體擴(kuò)展性,在企業(yè)落地 IAST 時(shí),需評(píng)估其是否能夠便利地與已有業(yè)務(wù)系統(tǒng)較好結(jié)合。可通過(guò)查看其 API 接口是否完善、需要的數(shù)據(jù)是否都能獲取。火線(xiàn)安全洞態(tài) IAST 直接開(kāi)放源代碼,方便用戶(hù)做二次開(kāi)發(fā),因此可擴(kuò)展性更強(qiáng)。
第四點(diǎn)是前文提到的運(yùn)營(yíng)成本,當(dāng)出現(xiàn)未檢測(cè)到的漏洞時(shí),如何將缺失的策略或檢測(cè)規(guī)則加入到產(chǎn)品中,也會(huì)產(chǎn)生比較高的后期使用成本,不能忽視。
安全牛:
火線(xiàn)安全選擇了開(kāi)源 IAST 產(chǎn)品模式,其原因是什么?開(kāi)源 IAST 產(chǎn)品的能力表現(xiàn)如何?我們未來(lái)的產(chǎn)品規(guī)劃又是怎樣的?
董志勇:
IAST 是個(gè)非常不錯(cuò)的工具,可以高效地幫助企業(yè)在 DevOps 階段解決相當(dāng)多的漏洞。火線(xiàn)安全的理念是幫助整個(gè)行業(yè)提升安全能力,我們想讓更多的企業(yè)使用 IAST 來(lái)防范安全風(fēng)險(xiǎn)。此外,IAST 本身是一個(gè)安全產(chǎn)品,其開(kāi)發(fā)門(mén)檻比較高,倘若因?yàn)槭袌?chǎng)上沒(méi)有開(kāi)源的 IAST 產(chǎn)品,導(dǎo)致很多企業(yè)重復(fù)造輪子,就會(huì)影響行業(yè)進(jìn)步,因此我們選擇了開(kāi)源。其實(shí)開(kāi)源和非開(kāi)源只是產(chǎn)品的外在形式不同,同樣的領(lǐng)域也都存在偉大的閉源產(chǎn)品和開(kāi)源產(chǎn)品。洞態(tài) IAST 是這一領(lǐng)域的后起之秀,產(chǎn)品進(jìn)展很快,也得到了很多用戶(hù)的支持和認(rèn)可。我們也會(huì)繼續(xù)努力打磨產(chǎn)品,為用戶(hù)帶來(lái)更大的價(jià)值。
對(duì) IAST 的未來(lái)規(guī)劃:洞態(tài) IAST 整體架構(gòu)是利用 Agent 采集數(shù)據(jù),在 Server 端進(jìn)行漏洞檢測(cè)。在這種架構(gòu)下,在一定程度上將安全與開(kāi)發(fā)進(jìn)行分割,安全人員可專(zhuān)注于安全,開(kāi)發(fā)人員可專(zhuān)注于開(kāi)發(fā)。火線(xiàn)安全希望洞態(tài) IAST 真正成為一款鏈接 Dev、Ops 和 Sec 團(tuán)隊(duì)的工具,讓安全賦能開(kāi)發(fā)和運(yùn)維,并結(jié)合場(chǎng)景來(lái)滿(mǎn)足更多 DevSecOps 流程下的安全需求。
安全牛評(píng):
在代碼安全與敏捷交付同樣重要的時(shí)代,只有開(kāi)發(fā)者主動(dòng)接受安全測(cè)試,才能從“根”上解決代碼安全問(wèn)題。在提高開(kāi)發(fā)人員安全意識(shí)的同時(shí),將安全測(cè)試無(wú)感知地融入開(kāi)發(fā)流程等等都是在想盡辦法讓開(kāi)發(fā)者愛(ài)上測(cè)試。“以 IAST 為起點(diǎn)構(gòu)建 DevSecOps 流程”的初衷是用開(kāi)發(fā)思維拉近代碼安全測(cè)試與代碼開(kāi)發(fā)者的距離。
而開(kāi)源的代碼安全工具,進(jìn)一步推動(dòng)開(kāi)發(fā)者樂(lè)于進(jìn)行安全測(cè)試,有利于應(yīng)用開(kāi)發(fā)行業(yè)代碼安全整體水平的提高,也將成為推動(dòng)代碼安全市場(chǎng)良性循環(huán)的“加速劑”。火線(xiàn)安全開(kāi)創(chuàng)了開(kāi)源代碼安全工具的元年——代碼安全從代碼開(kāi)源做起。
