浅析DevOps中结合IAST的落地介绍
前言
這篇博客打算重點介紹一下IAST相關的內容,以及IAST如何在DevSecOps中的CI/CD中的結合。做一期大雜燴,同時也是對我這半年多來的實習一次技術總結。
大致需要了解的內容為:
CI/CD的介紹
DevOps的介紹
IAST的介紹
在Jenkins流水線引入IAST
CI/CD的介紹
CI/CD是一種在應用開發階段來引入自動化集成和部署交付的方法。其具體的核心是持續集成、持續交付和持續部署。在過去的開發階段中,往往都是各個開發人員寫完代碼再集成在一起,這時候如果出現bug,則所需耗費的人力、時間成本會大大增加。有CI/CD的頻繁自動化集成和交付之后,開發人員就只需將代碼上傳svngit平臺上觸發CI/CD流程即可,大大減小了研發期間的人力和時間成本。
其中CI指的是持續集成(Continuous Integration),而CD指的是持續交付(Continuous Delivery)或持續部署(Continuous Deployment)。
舉個例子:工廠里的裝配線以快速、自動化、可重復的方式從原材料生產出消費品。同樣,軟件交付管道以快速、自動化和可重復的方式從源代碼生成發布版本。如何完成這項工作的總體設計稱為“持續交付”(CD)。啟動裝配線的過程稱為“持續集成”(CI)。確保質量的過程稱為“持續測試”,將最終產品提供給用戶的過程稱為“持續部署”。一些專家讓這一切簡單、順暢、高效地運行,這些人被稱為運維開發DevOps踐行者。
而持續集成(CI)可以幫助開發人員更加頻繁地(有時甚至每天)將代碼更改合并到共享分支或“主干”中。一旦開發人員對應用所做的更改被合并,系統就會通過自動構建應用并運行不同級別的自動化測試(通常是單元測試和集成測試)來驗證這些更改,確保這些更改沒有對應用造成破壞。這意味著測試內容涵蓋了從類和函數到構成整個應用的不同模塊。如果自動化測試發現新代碼和現有代碼之間存在沖突,CI 可以更加輕松地快速修復這些錯誤。
在持續交付中,每個階段(從代碼更改的合并,到生產就緒型構建版本的交付)都涉及測試自動化和代碼發布自動化。在流程結束時,運維團隊可以快速、輕松地將應用部署到生產環境中。
實際上,持續部署意味著開發人員對應用的更改在編寫后的幾分鐘內就能生效(假設它通過了自動化測試)。這更加便于持續接收和整合用戶反饋。總而言之,所有這些 CI/CD 的關聯步驟都有助于降低應用的部署風險,因此更便于以小件的方式(而非一次性)發布對應用的更改。不過,由于還需要編寫自動化測試以適應 CI/CD 管道中的各種測試和發布階段,因此前期投資還是會很大。
DevOps介紹
DevOps是指開發運維一體化的概念,以實現用戶價值作為唯一評判標準,保證產品的功能以及功能的實現、成功部署和穩定使用。其DevOps的核心就是之前介紹到的CI/CD,在此基礎上針對開發(Dev)和運維(Ops)團隊的一種解決方案。這種解決方案大大的體現出敏捷開發的優勢以及長處。
DevOps的好處與價值
對于業務與產品而言,DevOps的好處更多基于持續部署與交付。 從組織結構而言,DevOps是部門間溝通協作的一組流程和方法,有助于改善公司組織文化、提高員工的參與感。
代碼的提交直接觸發:消除等待時間,快速反饋
每個變化對應一個交付管道:使問題定位和調試變得簡單
全開發流程高效自動化:穩定,快速,交付結果可預測
持續進行自動化回歸測試:提升交付質量
設施共享并按需提供:資源利用最大化
總的來說DevOps就是一套解決方案,一套開發-運維落地的流程,其中涉及的工具鏈各式各樣,下圖是從網上找到的一張圖,囊括了部分DevOps各個階段的工具集合。
IAST的介紹
IAST,全稱為交互式應用安全測試(Interactive Application Security Testing,IAST),是一種自動化診斷發現應用程序漏洞的一種技術,其核心技術可以分為主動式探測與被動式插樁兩種方式,本文主要講的是被動插樁(Instrumented)的方式。
其被動插樁方式的原理是利用Agent部署在應用服務器上,并通過織入相關代碼來獲取程序執行過程中的上下文數據流信息,并結合污點傳播的方式判斷是否存在漏洞的一套流程。相比較之下,與其他兩款DAST(黑盒)、SAST(白盒)自動化產品比較,IAST的優勢不僅存在誤報低,而且對系統的性能和環境的污染程度較低。
IAST在應用測試中取到至關重要的地位,對自有研發的代碼可以進行測試發現漏洞,同時IAST本身也會集成SCA的方式,獲取應用程序在運行時候所有加載的第三方依賴庫,并與網上的在野利用漏洞和CVE版本號進行匹配,同時保證第三方應用的安全使用。
在Jenkins流水線中引入IAST
因為IAST是部署在應用服務器上的(例如Tomcat、Springboot Jar包、Weblogic),再通過測試人員觸發程序的功能進行測試,IAST的Agent就會捕獲到相應的數據流信息,從而判斷出漏洞。而整個這個過程基本上無需等待時間,即點即出的結果。
在這里就可以打成一個Docker鏡像,并將k8s部署的yaml文件模板一起放到git倉庫中,到時候從倉庫中拉去-->修改-->編譯-->推送到Harbor-->k8s部署
Dockerfile中的文件如下:
#基礎鏡像 FROM docker.io/tomcat:9.0.31-jdk8-openjdk #將虛擬機內的war包復制到tomcat容器的webapps目錄下 ADD xxx.war webapps/xxx.war #復制IAST Agent進容器 ADD iast_agent.jar /tmp/iast_agent.jar #可以設置tomcat調優,并發數等,或修改tomcat端口號,然后替換掉容器內部的server.xml文件即可 #ADD server.xml conf/server.xml #使用上海時區 RUN cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime #啟動javaagent ENV JAVA_OPTS="$JAVA_OPTS -javaagent:/tmp/iast_agent.jar" #啟動命令,默認也是這個,可以不寫 CMD ["catalina.sh","run"]
最后流水線通過自動化發包工具將被測系統中的數據內容都觸發一遍,完成整體流程。并通過釘釘將漏洞數量來上報給測試人員。
總結
以上是生活随笔為你收集整理的浅析DevOps中结合IAST的落地介绍的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: linux(centos8):使用cgr
- 下一篇: 带你玩转Visual Studio——带