譯者 | 陳峻
審校 | 重樓
在現代開發環境中，持續集成（CI）和持續交付（CD）管道對于向最終用戶交付軟件的變更已是“家常便飯”。這導致了過去在部署之后才執行安全測試的傳統方法，對于每天可能要進行數十甚至數百次部署的場景而言，已不再有效。
安全測試人員為了能夠輕松地自動運行和協調一系列開箱即用的安全測試工具，也往往需要一個模塊化的工具鏈。而secureCodeBox正是這樣一個基于Kubernetes（又稱 K8s）的、可被用于對軟件項目進行持續安全掃描的工具。它能夠被集成到CI/CD管道中，自動掃描變更，并向開發人員提供測試結果，以便他們在部署之前修復軟件問題。
架構
總的說來，secureCodeBox的架構如下圖所示：
secureCodeBox的架構圖
而且，由于Kubernetes作業可以按需啟動，并只在需要時才使用資源，因此它能夠在掃描活動之間節省大量資源。同時，其另一個優勢在于，所有不必要的掃描工件或元數據都會在Kubernetes作業執行之間被刪除。
如圖所示，負責處理這一流程的主要組件便是secureCodeBox操作器（Operator）。該操作器通過為每個步驟觸發相應的Kubernetes作業來協調掃描，即：從掃描活動開始，到解析結果，再到修改和持久化結果。整個過程無需依賴人工安全審查，而且具有可擴展性，可以輕松添加更多的掃描器作為新的Kubernetes對象。
部署secureCodeBox
SecureCodeBox可以使用Helm圖表在Kubernetes中進行部署。畢竟Helm在K8s中不需要太多的部署工作，而且部署的對象可以通過Helm變量輕松調整。
下面，我將使用Minikube創建一個本地Kubernetes集群。這里，Minikube并不是為生產環境的用例而設計的，不過您可以用它來測試性部署在K8s中。
首先，我們使用如下命令，以 4 個CPU和2048 MB內存的方式啟動Minikube：
minikube start --cpus=4 --memory=2048m啟動Minikube之后，我們便可以使用如下命令添加Helm資源庫：
helm repo addsecureCodeBoxhttps://charts.securecodebox.io接著，我們可以使用以下命令創建新的K8s命名空間。在此，我強烈建議您創建一個單獨的Kubernetes命名空間，將secureCodeBox對象與其他K8s對象分離開來，尤其是在K8s中已部署了其他服務的情況下。據此，我們可以更方便地管理新創建的、專用于該平臺的對象。
kubectl create namespacesecureCodeBox-system命令成功執行后，我們就可以在新創建的名為securecodebox-system 的命名空間中，使用如下命令安裝secureCodeBox了：
helm --namespacesecureCodeBox-system upgrade --installsecureCodeBox-operatorsecureCodeBox/operator至此，secureCodeBox操作器已部署完畢，可隨時進行掃描管理了。下圖展示了上述各項命令：
啟動Minikube并部署secureCodeBox
如下圖所示，您可以通過執行kubectl get pods -nsecureCodeBox-system來驗證pod是否正常運行。
在K8s中運行secureCodeBoxPods
使用secureCodeBox進行掃描
SecureCodeBox集成了許多適用于各種場景的流行掃描組件。其官方文檔就提及了 20 多種掃描集成，其中包括但不限于：
SecureCodeBox的掃描集成
由于secureCodeBox中的掃描器是由ScanTypes表示的，而ScanTypes在Kubernetes中屬于定制資源定義（CustomResourceDefinition），因此在運行掃描之前，我們必須通過如下Helm命令，將Semgrep安裝到secureCodeBox中：
helm upgrade --install semgrepsecureCodeBox/semgrep -nsecureCodeBox-system下圖展示了該命令的截圖：
安裝Semgrep掃描器
安裝好Semgrep掃描類型（ScanType）之后，我們就可以針對所選的存儲庫開始配置掃描器了。以下是Semgrep配置的示例，您可以參見其官方文檔。該配置實際上是一個描述性的掃描（Scan）YAML文檔，即在K8s中secureCodeBox使用的一個自定義對象。
apiVersion: "execution.securecodebox.io/v1"
kind: Scan
metadata:
name: "semgrep-vulnerable-flask-app"
spec:
# Specify aKubernetesvolume that will be shared between the scanner and the initContainer
volumes:
- name: repository
emptyDir: {}
# Mount the volume in the scan container
volumeMounts:
- mountPath: "/repo/"
name: repository
# Specify an init container to clone the repository
initContainers:
- name: "provision-git"
# Use an image that includes git
image: bitnami/git
# Mount the same volume we also use in the main container
volumeMounts:
- mountPath: "/repo/"
name: repository
# Specify the clone command and clone into the volume, mounted at /repo/
command:
- git
- clone
- "https://github.com/we45/Vulnerable-Flask-App"
- /repo/flask-app
# Parameterize the semgrep scan itself
scanType: "semgrep"
parameters:
- "-c"
- "p/ci"
- "/repo/flask-app"在上述配置中，您可以看到，作為容器的prosision-git被用于執行git clone，以下載所選的存儲庫。在本例中，它克隆了Vulnerable Flask App，以便對其執行掃描。此處的Vulnerable Flask App是一個使用Python Flask框架創建的Web應用。當然，通過自定義的git參數，您也可以改變命令參數，以克隆任何選定的存儲庫。
在上例中，存儲庫被克隆到了/repo/flask-app目錄中，該目錄也是在provision-git和semgrep容器之間共享的Kubernetes卷。一旦存儲庫被克隆，Semgrep就會使用參數配置來啟動掃描。這些參數，尤其是使用到的規則，都是可以被調整的。而且，由于Semgrep的規則是公開的，因此您可以在規則注冊表中輕松找到。
下面，讓我們將YAML文檔保存為semgrep-vulnerable-flask-app.yaml，然后使用如下kubectl命令啟動掃描：
kubectl apply -f semgrep-vulnerable-flask-app.yaml -nsecureCodeBox-system該命令的輸出結果如下圖所示：
針對存在漏洞的Flask App運行Semgrep掃描
我使用了kubectl get scan命令來檢查掃描狀態。由于secureCodeBox使用K8s對象來表示掃描，因此它們的訪問方式與其他K8s對象類似。
后續，您可以再次執行相同的get命令，來驗證掃描是否成功完成。
如上圖所述，Done狀態表示掃描已完成，且包含了1項發現。
獲取結果詳情
在默認配置下，掃描結果不會保存在數據庫中。您可以使用如下kubectl describe命令來訪問掃描的輸出：
kubectl describe scan semgrep-vulnerable-flask-app -nsecureCodeBox-system在kubectl的輸出中，我們可以看到如下內容：
Semgrep執行掃描后的輸出
在上圖中，我們可以通過“發現下載鏈接（Finding Download Link）”來下載報告。我據此訪問了指向Kubernetes服務的URL，并收到了作為響應的、JSON格式的Semgrep報告。下面，讓我們來查看這份報告：
{
...
"results": [
{
"check_id": "python.jwt.security.jwt-hardcode.jwt-python-hardcoded-secret",
"end": {
"col": 193,
"line": 184,
"offset": 6227
},
"extra": {
"engine_kind": "OSS",
"fingerprint": "221138ec7d837ea33e1e3346821e6bf50d3f21bf8600de705b7831ef2fe9139023f1f58202a21034ac06a54a67236bd9a41624ac7960e173627cb6298a92c5c6_0",
"is_ignored": false,
"lines": " auth_token = jwt.encode({'user': username, 'exp': get_exp_date(), 'nbf': datetime.datetime.utcnow(), 'iss': 'we45', 'iat': datetime.datetime.utcnow()}, app.config['SECRET_KEY_HMAC'], algorithm='HS256')",
"message": "Hardcoded JWT secret or private key is used. This is a Insufficiently Protected Credentials weakness: https://cwe.mitre.org/data/definitions/522.html Consider using an appropriate security mechanism to protect the credentials (e.g. keeping secrets in environment variables)",
"metadata": {
"category": "security",
"confidence": "HIGH",
"cwe": [
"CWE-522: Insufficiently Protected Credentials"
],
"cwe2021-top25": true,
"impact": "MEDIUM",
"license": "Commons Clause License Condition v1.0[LGPL-2.1-only]",
"likelihood": "HIGH",
"owasp": [
"A02:2017 - Broken Authentication",
"A04:2021 - Insecure Design"
],
"references": [
"https://semgrep.dev/blog/2020/hardcoded-secrets-unverified-tokens-and-other-common-jwt-mistakes/"
],
"semgrep.dev": {
"rule": {
"origin": "community",
"rule_id": "X5U8P5",
"url": "https://semgrep.dev/playground/r/l4T4vPA/python.jwt.security.jwt-hardcode.jwt-python-hardcoded-secret",
"version_id": "l4T4vPA"
}
},
...
}在上述報告中，我們可以看到：規則python.jwt.security.jwt-hardcode.jwt-python-hardcoded-secret識別出了存儲庫中的一個硬編碼密鑰。其問題就出現在第 184行，與創建JWT令牌有關。作為令牌的密文，它使用了存儲在app.config['SECRET_KEY_HMAC']變量中的值。為了弄清楚這個值到底是硬編碼，還是從環境變量等中獲取的，我們搜索了設置該密鑰的位置，并最終確定了該變量定義的確源于硬編碼。
...
app.config['SECRET_KEY_HMAC'] = 'secret'
app.config['SECRET_KEY_HMAC_2'] = 'am0r3C0mpl3xK3y'
app.secret_key = 'F12Zr47j\3yX R~X@H!jmM]Lwf/,?KT'
...
if auth_user:
auth_token = jwt.encode({'user': username, 'exp': get_exp_date(), 'nbf': datetime.datetime.utcnow(), 'iss': 'we45', 'iat': datetime.datetime.utcnow()}, app.config['SECRET_KEY_HMAC'], algorithm='HS256')
resp = Response(json.dumps({'Authenticated': True, "User": username}))
#resp.set_cookie('SESSIONID', auth_token)
resp.headers['Authorization'] = "{0}".format(auth_token)
resp.status_code = 200
resp.mimetype = 'application/json'
return resp
...此外，為了加快漏洞報告的訪問效率，我們可以使用DefectDojo作為與secureCodeBox集成的漏洞管理平臺，以通過其友好的用戶界面和更高效的漏洞管理，來改進流程。目前，SecureCodeBox允許我們將發現結果以持久方式傳遞給Azure Monitor、DefectDojo、Dependency-Track、以及ElasticSearch等服務。
小結
secureCodeBox作為一個獨立的掃描器，配置起來非常簡單。在上文中，我們介紹了secureCodeBox的架構、可用的掃描器、各種配置示例、以及典型用例。
在我看來，secureCodeBox既是一個非常有前途的持續安全測試方案，也是為數不多的此類開源項目之一。通過將其集成到CI/CD中，并根據代碼庫相關事件觸發掃描，它不但提供了在Kubernetes中執行安全測試的能力，而且提供了許多開源掃描器的集成，因此覆蓋了持續安全測試的大部分方面。同時，它也可以被用作一體化的掃描服務，針對代碼庫和已部署的應用定期執行自動化的安全評估。
此外，secureCodeBox還可以直接向CI或專用開發人員提供報告，使之能夠在將代碼合并到主分支之前，修復已發現的漏洞。當然，應該指出的是，由滲透測試人員進行人工安全測試的傳統方法仍然十分重要，畢竟自動化可能無法檢測到復雜的安全問題。
總之，如果您正在尋找一個一體化的開源掃描儀，且愿意使用Kubernetes和YAML文件去自定義掃描的話，secureCodeBox會是持續安全測試中最好、最被低估的開源項目之一。
譯者介紹
陳峻（Julian Chen），51CTO社區編輯，具有十多年的IT項目實施經驗，善于對內外部資源與風險實施管控，專注傳播網絡與信息安全知識與經驗。
原文標題：Exploring secureCodeBox— An Open-Source Continuous Security Testing Solution for DevSecOps，作者：Krzysztof Pranczk
