每日分享最新，最流行的軟體開發知識與最新行業趨勢，希望大家能夠一鍵三連，多多支援，跪求關注，點贊，留言。

DevSecOps 是一種将安全性內建到我們的 CI/CD 管道中的文化方法。它確定在 SDLC 和基礎架構的每個階段都實施安全性。

在了解 DevSecOps 之前，我們先來了解一下 DevOps 是什麼。DevOps 是文化理念、實踐和工具的結合，可提高組織高速傳遞應用程式和服務的能力。

在快速發展的項目中，安全性往往滞後并且被賦予低優先級，這可能導緻錯誤代碼和黑客攻擊。讓我們看看如何通過将安全性內建到我們的 DevOps 管道中來降低攻擊風險。

什麼是 DevSecOps（DevOps + 安全）？

DevSecOps 是一種文化方法，在該方法中，每個團隊和從事應用程式工作的人員都會在其整個生命周期中考慮安全性。它通過使用适當的工具将所需的安全檢查嵌入到 CI/CD 自動化中，確定在應用程式軟體開發生命周期 (SDLC) 的每個階段實施安全性。

例如，讓我們看看 DevSecOps 流程如何檢測和預防 log4j 等零日漏洞。使用Syft工具，我們可以為我們的應用程式代碼生成 SBOM 并将此 SBOM 報告傳遞給Grype，Grype 可以檢測這些新漏洞并向我們報告是否有任何可用的修複或更新檔。由于這些步驟是我們 CI/CD 的一部分，是以我們可以提醒我們的開發人員和安全團隊在發現此問題後立即對其進行補救。

使用 DevSecOps 的好處

在開發的早期階段發現漏洞和錯誤
簡化合規性
早日康複
安全的供應鍊
節約成本
可以包括用于檢測異常的基于 AI 的監控
降低表面攻擊的風險并增加信心
全面了解潛在威脅和可能的補救方法

如何讓安全文化成為您的預設狀态

除非您在每位員工的入職教育訓練中都包含安全性，否則建立廣泛的安全文化思維方式将具有挑戰性。員工将需要以不同的方式思考，以不同的方式行事，并最終将這些變化轉化為習慣，以便安全成為他們日常工作的自然組成部分。

DevSecOps CI/CD 管道是什麼樣的？

Jenkins DevSecOps 管道

在這篇文章中，我們将介紹以下标準 CI/CD 階段以及如何保護它們：

計劃/設計
開發
建構和代碼分析
測試
部署

讓我們深入了解如何實施 DevSecOps。

1. 計劃/設計

在這個階段，我們将概述內建、部署和安全測試将在何處、如何以及何時進行。

1.1 威脅模組化

它有效地将您置于攻擊者的思維模式中，并允許我們通過攻擊者的眼睛看到應用程式，并在他們有機會采取任何行動之前阻止他們的攻擊。我們可以使用 OWASP 威脅模組化或 Microsoft 的簡單問題方法來設計我們的威脅模組化。我們還可以使用 OWASP Threat Dragon 和Cairis開源威脅模組化工具為我們的安全開發生命周期建立威脅模型圖。

1.2 安全 SDLC

安全 SDLC 需要在每個軟體開發階段（從設計到開發、再到部署等）添加安全測試。示例包括設計應用程式以確定您的架構是安全的，并将安全風險因素作為初始規劃階段的一部分。

- Snyk 安全 SDLC

在一個安全的軟體開發周期中，我們應該将我們的開發、測試和生産環境分開，并且還應該有控制從一個環境到另一個環境的部署更新的授權過程。這降低了開發人員進行未經授權的更改的風險，并確定任何修改都通過标準的準許流程。

2. 開發

開發階段從編寫代碼開始，我們可以使用左移安全最佳實踐，它在開發的最早階段結合了安全思維。例如：

在代碼編輯器中安裝 linting 工具，例如 Visual Studio Code。最受歡迎的 linting 工具之一是 SonarLint，它會在您編寫代碼時突出顯示錯誤和安全漏洞。
使用預送出挂鈎來防止向代碼添加任何秘密。
設定受保護的分支和代碼審查流程。
使用 GPG 密鑰簽署 git 送出。
始終驗證下載下傳的二進制/檔案哈希。
啟用兩因素身份驗證。

3.建構和代碼分析

在建構之前，我們需要掃描我們的代碼以查找漏洞和秘密。通過進行靜态代碼分析，它可能會檢測到代碼中的錯誤或可能的溢出，這些溢出會導緻記憶體洩漏，進而通過減少每個程式的可用記憶體量來降低系統性能。有時它可以被黑客用作攻擊面來利用資料。

3.1 掃描秘密和憑證

detect-secret是一種企業友好型工具，用于檢測和防止代碼庫中的秘密。我們還可以掃描非 git 跟蹤的檔案。還有其他工具，例如Gitleaks，它們也提供類似的功能。

detect-secrets scan test_data/ --all-files

3.2 軟體物料清單 (SBOM)

SBOM 讓我們能夠識别在我們的環境中運作的所有軟體元件、庫和子產品，甚至它們的依賴關系。它加快了對新漏洞的響應時間——包括像 Log4j 這樣的零日漏洞。

我們可以使用以下工具生成 SBOM 報告。

3.2.1 帶有 Grype 和 Trivy 的 Syft

Syft 工具以CycloneDX開源格式提供容器映像和檔案系統 SBOM 結果，可以輕松共享。Syft 還支援用于驗證合法圖像的 cosign 證明。

syft nginx:latest -o cyclonedx-json=nginx.sbom.cdx.json

是以，我們生成了一份 SBOM 報告，顯示了我們軟體中運作的庫和子產品。現在，讓我們使用 Grype 掃描 SBOM 報告中的漏洞。

[root@laptop ~]# grype sbom:./nginx.sbom.cdx.json | head ✔ Vulnerability DB [no update available] ✔ Scanned image [157 vulnerabilities] NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY apt 2.2.4 deb CVE-2011-3374 Negligible bsdutils 1:2.36.1-8+deb11u1 deb CVE-2022-0563 Negligible coreutils 8.32-4+b1 deb CVE-2017-18018 Negligible coreutils 8.32-4+b1 (won't fix) deb CVE-2016-2781 Low curl 7.74.0-1.3+deb11u1 deb CVE-2022-32208 Unknown curl 7.74.0-1.3+deb11u1 deb CVE-2022-27776 Medium curl 7.74.0-1.3+deb11u1 (won't fix) deb CVE-2021-22947 Medium curl 7.74.0-1.3+deb11u1 (won't fix) deb CVE-2021-22946 High curl 7.74.0-1.3+deb11u1 (won't fix) deb CVE-2021-22945 Critical # Or we can directly use Grype for SBOM scanninggrype nginx:latest

注意： SCA 工具掃描的許多漏洞既無法利用也無法通過定期更新修複。Curl 和 glibc 就是一些例子。這些工具将它們顯示為不可修複或無法修複。

最新版本的Trivy也可以生成 SBOM 報告，但它主要用于查找容器和檔案系統中的漏洞。

3.2.2 OWASP 依賴檢查

OWASP Dependency-Check 是一種軟體組合分析 (SCA) 工具，它試圖檢測項目依賴項中包含的公開披露的漏洞。它通過确定給定依賴項是否存在通用平台枚舉 (CPE) 辨別符來做到這一點。如果找到，它将生成連結到相關 CVE 條目的報告。我們還可以将我們的 SBOM 報告釋出到 Dependency-Track 并可視化我們的軟體元件及其漏洞。

dependency-check.sh --scan /project_path

一旦我們知道我們的軟體中存在哪些類型的漏洞，我們就可以修補它們并使我們的應用程式安全可靠。

3.3 靜态應用安全測試（SAST）

這是一種無需運作程式即可調試代碼的方法。它根據預定義的規則集分析代碼。

SonarQube允許所有開發人員編寫更清潔、更安全的代碼。它支援多種用于掃描的程式設計語言（Java、Kotlin、Go、JavaScript）。它還支援為代碼覆寫率運作單元測試。它可以輕松地與 Jenkins 和 Azure DevOps 內建。Checkmarx、Veracode 和 Klocwork 也提供類似的功能，但這些都是付費工具。

docker run \ --rm \ -e SONAR_HOST_URL="http://${SONARQUBE_URL}" \ -e SONAR_LOGIN="AuthenticationToken" \ -v "${YOUR_REPO}:/usr/src" \ sonarsource/sonar-scanner-cli

來源：從 Docker 映像運作 SonarScanner。

3.4 單元測試

在單元測試中，檢查各個軟體代碼元件以確定其按預期工作。單元測試隔離代碼的功能或子產品并驗證其正确性。我們可以使用JaCoCo for Java 和 Mocha 和 Jasmine for NodeJS 等工具來生成單元測試報告。最後，我們可以将這些報告發送到 SonarQube，它會向我們顯示代碼覆寫率以及測試用例覆寫的代碼百分比。

一旦 SAST 完成，我們也可以掃描 Dockerfile。

3.5 Dockerfile 靜态掃描

始終掃描 Dockerfile 以查找漏洞，因為在編寫 Dockerfile 時，我們可能會錯過一些 Dockerfile 最佳實踐，這可能會導緻容器易受攻擊。舉幾個我們可以避免的常見錯誤。

不要使用最新的 docker 鏡像标簽。
確定已建立容器的使用者。

Checkov或 docker scan 可以用來掃描 Dockerfile，它遵循最佳實踐規則來編寫 Dockerfile。

docker run -i -v $(pwd):/output bridgecrew/checkov -f /output/Dockerfile -o json

建構容器鏡像後，我們掃描它的漏洞并簽署我們的容器鏡像。

3.6 容器鏡像掃描

掃描圖像會給出容器圖像的安全狀态，并讓我們采取行動來生成更安全的容器圖像。我們應該避免安裝不必要的包并使用多階段方法。這樣可以保持圖像清潔和安全。圖像掃描應在開發和生産環境中進行。

以下是一些我們可以用于容器掃描的知名開源和付費工具：

開源： Trivy、Gryp 和Clair是廣泛使用的容器掃描開源工具。
Docker 掃描：它使用 Snyk 作為掃描的後端引擎。它還可以掃描 Dockerfile。
Aqua 掃描：提供容器圖像掃描，但它有一個獨特的功能：容器的 Aqua DTA（動态威脅分析），它監控行為模式和危害名額 (IoC)，例如惡意行為和網絡活動，以檢測容器逃逸，惡意軟體、加密貨币礦工、代碼注入後門和其他威脅。

trivy image nginx:latest# ORdocker scan nginx:latest

3.7 容器鏡像簽名和驗證

如果容器建構過程受到破壞，它會使使用者容易意外使用惡意圖像而不是實際的容器圖像。對容器進行簽名和驗證始終確定我們運作的是實際的容器鏡像。

使用distroless鏡像不僅可以減小容器鏡像的大小，還可以減少表面攻擊。容器鏡像簽名的必要性是因為即使使用 distroless 鏡像，也有可能面臨一些安全威脅，例如接收惡意鏡像。我們可以使用cosign或skopeo進行容器簽名和驗證。

cosign sign --key cosign.key custom-nginx:latest cosign verify -key cosign.pub custom-nginx:latest

3.8 容器鏡像驗證測試

在容器映像上添加額外的安全層，以驗證它是否按預期工作，并且所有必需的檔案都具有正确的權限。我們可以使用dgoss來做容器鏡像的驗證測試。

例如，我們對運作在 80 端口的 Nginx 鏡像做一個驗證測試，可以通路網際網路，并驗證/etc/nginx/nginx.conf容器中 Nginx 使用者 shell 的檔案權限是否正确。

dgoss edit nginx goss add port 80 goss add http https://google.comgoss add file /etc/nginx/nginx.conf goss add user nginx # Once we exit it will copy the goss.yaml from the container to the current directory and we can modify it as per our validation.# Validate[root@home ~]# dgoss run -p 8000:80 nginx INFO: Starting docker container INFO: Container ID: 5f8d9e20 INFO: Sleeping for 0.2 INFO: Container health INFO: Running Tests Port: tcp:80: listening: matches expectation: [true]Port: tcp:80: ip: matches expectation: [["0.0.0.0"]]HTTP: https://google.com: status: matches expectation: [200] File: /etc/nginx/nginx.conf: exists: matches expectation: [true]File: /etc/nginx/nginx.conf: mode: matches expectation: ["0644"]File: /etc/nginx/nginx.conf: owner: matches expectation: ["root"]File: /etc/nginx/nginx.conf: group: matches expectation: ["root"]User: nginx: uid: matches expectation: [101] User: nginx: gid: matches expectation: [101] User: nginx: home: matches expectation: ["/nonexistent"]User: nginx: groups: matches expectation: [["nginx"]]User: nginx: shell: matches expectation: ["/bin/false"]Total Duration: 0.409s Count: 13, Failed: 0, Skipped: 0 INFO: Deleting container

我們還可以使用kgoss對 pod 進行驗證測試。

到目前為止，我們已經建構并掃描了容器鏡像，但在部署之前，讓我們測試并掃描部署或 Helm 圖表。

4. 測試

測試確定應用程式按預期工作并且沒有錯誤或漏洞。

4.1 冒煙測試

冒煙測試很小，但會檢查應用程式的關鍵元件和功能。實施後，它會在每個應用程式建構上運作，以在內建之前驗證關鍵功能是否通過，并且可以進行端到端測試，這可能非常耗時。冒煙測試有助于建立對軟體開發生命周期至關重要的快速回報循環。

例如，在冒煙測試中，我們可以在 API 上運作 curl 指令來擷取 HTTP 響應代碼和延遲。

4.2 API 測試

今天的應用程式可能會暴露數百個對黑客非常有吸引力的非常有價值的端點。確定您的 API 在生産之前、期間和之後的安全至關重要。是以，我們需要測試我們的 API。

API 測試報告需要什麼類型的身份驗證以及敏感資料是否通過 HTTP 和 SQL 注入加密，進而允許您繞過登入階段。

我們可以使用 Jmeter、Taurus、Postman 和 SoapUI 工具進行 API 測試。下面是一個使用 Jmeter 的小示例，其中test.jmx包含 API 測試用例。

jmeter -n --t test.jmx -l result.jtl

4.3 動态應用安全測試（DAST）

DAST 是一種 Web 應用程式安全測試，用于發現正在運作的應用程式中的安全問題。DAST 工具也稱為 Web 應用程式漏洞掃描程式，可以檢測常見漏洞，如 SQL 注入、跨站點腳本、安全錯誤配置以及 OWASP Top 10 中詳述的其他常見問題。我們可以使用 HCL Appscan、ZAP、Burp Suite 和Invicti，它發現正在運作的 Web 應用程式中的漏洞。

zap.sh -cmd -quickurl http://example.com/ -quickprogress -quickout example.report.html

5. 部署

部署可以是基礎設施或應用程式；但是，我們應該掃描我們的部署檔案。我們還可以添加手動觸發器，使管道在進入下一階段之前等待外部使用者驗證，或者它可以是自動觸發器。

5.1 Kubernetes Manifest 檔案或 Helm Chart 的靜态掃描

在部署之前掃描您的 Kubernetes 部署或 Helm 圖表始終是一個好習慣。我們可以使用 Checkov 掃描 Kubernetes 清單并識别安全和配置問題。它還支援 Helm 圖表掃描。我們還可以使用terrascan和kubeLinter來掃描 Kubernetes 清單。

docker run -t -v $(pwd):/output bridgecrew/checkov -f /output/keycloak-deploy.yml -o json# For Helmdocker run -t -v $(pwd):/output bridgecrew/checkov -d /output/ --framework helm -o json

5.2 預部署政策檢查 Kubernetes Manifest YAML 檔案

Kyverno增加了一個額外的安全層，僅将允許的清單類型部署到 Kubernetes 上，否則，它将拒絕或者我們可以設定validationFailureAction為審計，它隻記錄政策違規消息以進行報告。Kubewarden 和Gatekeeper是可用于在 Kubernetes CRD 上實施政策的替代工具。

5.3 用于 CIS 掃描的 kube-bench

kube-bench通過運作 CIS Kubernetes Benchmark 中記錄的檢查來檢查 Kubernetes 是否已安全部署。我們可以将 kube-bench 部署為每天運作的作業，并使用 CI/CD 中的報告來根據嚴重程度通過或失敗管道。

kubectl apply -f eks-job.yaml kubectl logs kube-bench-pod-name

5.4 IaC 掃描

Checkov、Terrascan和Kics可用于掃描我們的基礎設施代碼。它支援 Terraform、Cloudformation 和 Azure ARM 資源。
Terratest可用于實時測試基礎設施。

terraform init terraform plan -out tf.plan terraform show -json tf.plan | jq '.' > tf.json checkov -f tf.json

在掃描 Kubernetes 部署和 kube-bench 之後，我們可以部署我們的應用程式并開始測試階段。

6. 監控和警報

監控和警報是收集有關我們基礎設施中發生的一切的日志和名額并根據名額門檻值發送通知的過程。

6.1 名額監控

Prometheus：它是一種廣泛使用的用于度量監控的開源工具。它提供了各種可用于監控系統或應用程式名額的導出器。我們還可以使用Grafana來可視化 Prometheus 名額。
Nagios 和Zabbix：這些是用于監控 IT 基礎設施（如網絡、伺服器、虛拟機和雲服務）的開源軟體工具。
Sensu Go：它是用于大規模監控和可觀察性的完整解決方案。

6.2 日志監控

OpenSearch/ Elasticsearch：它是一個實時分布式和分析引擎，有助于執行各種搜尋操作。
Graylog：它提供集中的日志管理功能，用于收集、存儲和分析資料。
Grafana Loki：它是一個輕量級的日志聚合系統，旨在存儲和查詢來自所有應用程式和基礎設施的日志。

6.3 警報

Prometheus Alertmanager：Alertmanager 處理由 Prometheus 伺服器等用戶端應用程式發送的警報。
Grafana OnCall：通過電話、短信、Slack 和電報通知對開發人員友好的事件響應。

以安全為中心的日志記錄和監控政策用于防止敏感資訊以純文字形式記錄。我們可以在我們的日志系統中編寫一個測試用例來查找某些資料模式。例如，查找敏感資訊的正規表達式，以便我們可以在較低環境中檢測日志。

應用程式性能監控 (APM) 提高了對分布式微服務架構的可見性。APM 資料可以通過允許應用程式的完整視圖來幫助增強軟體安全性。像Zipkin和Jaeger這樣的分布式跟蹤工具将所有日志拼接在一起，并從頭到尾提供請求的完全可見性。它加快了對新錯誤或攻擊的響應時間。

盡管所有雲提供商都有自己的監控工具集，并且一些工具可以從市場上通路。此外，還有 Newrelic、Datadog、Appdynamics 和 Splunk 等付費監控工具提供商提供所有類型的監控。

6.4 安全資訊和事件管理 (SIEM)

安全資訊和事件管理 (SIEM) 提供事件的實時監控和分析、安全資料的跟蹤和記錄，以實作合規性或審計目的。Splunk、Elastic SIEM 和Wazuh可以自動檢測可疑活動，并且使用基于行為的規則的工具也可以使用預建構的 ML 作業檢測異常。

6.5 審計

在部署可見性來自已在應用程式和基礎架構上實施的審計級别之後，目标是讓您的審計處于允許您将資訊輸入安全工具以提供所需資料的級别。我們可以使用 CloudTrail 在 AWS 雲上啟用審計，在 Azure 上使用平台日志啟用審計。對于審計應用程式，我們可以啟用内置審計日志并将審計資料發送到任何日志工具，如使用 auditbeat 或 Splunk 的 Elasticsearch，并建立一個審計儀表闆。

6.6 Kubernetes 運作時安全監控

Falco 是一個雲原生的 Kubernetes 威脅檢測工具。它可以實時檢測意外行為、入侵和資料盜竊。在後端，它使用 Linux eBPF 技術在運作時跟蹤您的系統和應用程式。例如，它可以檢測是否有人試圖讀取容器内的機密檔案、以 root 使用者身份通路 pod 等，并觸發 webhook 或将日志發送到監控系統。有類似的工具，如Tetragon、KubeArmor和Tracee，它們也提供 Kubernetes 運作時安全性。

到目前為止，我們已經看到了 DevSecOps CI/CD 管道的樣子。現在，讓我們深入研究在頂部添加更多安全層。

保護 DevSecOps CI/CD 基礎設施的最佳實踐

網絡安全

網絡是我們抵禦任何類型攻擊的第一道防線，為了防止對我們的應用程式的攻擊，我們應該強化我們的網絡。

為工作負載（例如應用程式和資料庫）建立一個單獨的專用網絡，并且隻允許從 NAT 通路網際網路。
對入站和出站網絡規則設定細粒度通路。此外，我們可以使用 Cloud custodian 設定安全合規性，這會自動删除任何不需要的網絡流量。
始終為 AWS 中的子網配置網絡 ACL (NACL)。最佳做法是阻止所有出站流量，然後允許所需的規則。
使用 Web 應用程式防火牆 (WAF)。
啟用 DDOS 保護。
Nmap、Wireshark 和 tcpdump 工具可以掃描網絡和資料包。
使用 VPN 或堡壘主機連接配接到基礎設施網絡。

Web 應用程式防火牆 (WAF)

WAF 是第 7 層防火牆，可保護我們的 Web 應用程式免受常見 Web 漏洞（如 XSS 和 SQL 注入）和可能影響可用性、危及安全性或消耗過多資源的機器人的侵害。大多數雲服務提供商都提供WAF，隻需點選幾下，我們就可以輕松地将它與我們的應用程式內建。

Curiefense是一個開源的雲原生自我管理 WAF 工具，可用于保護各種形式的 Web 流量、服務、DDoS 和 API。我們還可以将 WAF 用作 Cloudflare 和 Imperva 的服務。

身份通路管理 (IAM)

IAM 是一種集中定義的政策，用于控制對資料、應用程式和其他網絡資産的通路。以下是一些有助于防止未經授權的通路的方法。

使用 Active Directory 或 LDAP 進行集中式使用者管理。
使用 RBAC 通路管理。
為 AWS IAM 角色制定細粒度的通路政策。
定期輪換使用者的通路密鑰和密鑰。
使用 Teleport 進行集中連接配接、身份驗證、授權和審計。
将機密存儲在保險庫中，并確定隻有授權使用者才能通路。
在您的服務中實施零信任。

雲、伺服器和應用程式強化

我們可以使用 CIS 基準來強化雲、作業系統和應用程式。使用強化作業系統始終是一個好習慣，因為它可以減少伺服器的攻擊面。大多數雲提供商都提供了強化鏡像，或者我們可以建立自己的自定義強化鏡像。

如今，大多數應用程式都在容器内運作。我們需要通過靜态分析和容器圖像掃描來強化我們的應用程式和容器。

為了防止病毒、木馬、惡意軟體和其他惡意威脅，我們可以安裝 Falcon、SentinelOne 或 Clamav 等防病毒軟體。

伺服器更新檔

最常見的攻擊向量利用作業系統或伺服器上運作的應用程式中的漏洞。針對環境運作定期漏洞掃描并更新正常軟體包可降低漏洞風險。

我們可以建立一個自動化管道來使用 Foreman 或 Red Hat Satellite 修補伺服器，對于掃描，我們可以使用OpenVAS或 Nessus 來擷取漏洞清單。

保護 Kubernetes

Kubernetes 已經成為現代基礎設施的支柱，為了確定我們安全地運作它，我們可以使用以下工具：

在 Kubernetes YAML 檔案中使用正确的安全上下文。
使用網絡政策預設阻止所有流量，僅允許所需流量。
使用 Service Mesh ( Linkerd , Istio ) 在微服務之間進行 mTLS 通信并實作授權以進行細粒度通路。
為 Kubernetes 叢集實作 CIS 基準報告的 kube-bench。我們可以每天在我們的 Kubernetes 叢集中運作此掃描并修複任何報告的漏洞。
使用Kube-hunter、Popeye和Kubescape等工具來解決 Kubernetes 叢集中的安全漏洞和錯誤配置以及安全問題的可見性。
使用 Checkov、KubeLinter和 Terrascan 掃描具有最佳實踐和漏洞的 Kubernetes YAML 和 Helm 圖表。
實施部署前政策檢查，如Kyverno、Kubewarden 和Gatekeeper可以阻止非标準部署。
為工作伺服器使用強化映像。所有雲提供商都提供 CIS 基準強化鏡像。我們還可以使用amazon-eks-ami建構我們自己的自定義強化映像。
以加密格式存儲 Kubernetes 機密或使用 Vault 等外部機密管理器。
使用服務賬戶的 IAM 角色将 AWS 角色直接配置設定給 Kubernetes 服務賬戶。
實施Chaos Mesh和Litmus混沌工程架構，以了解應用程式在實際用例中的行為和穩定性。
遵循最佳實踐來保護 Kubernetes。
使用 Falco 和 Tracee 等工具來監控運作時特權和不需要的系統調用。

容器

容器是在現代基礎設施中運作任何工作負載的最小抽象級别。下面是一些保護我們容器的方法，我們也在上面看到了如何将它們內建到我們的 CI/CD 管道中。

掃描容器鏡像和 Dockerfile。
通過多階段建構減少 Docker 鏡像大小，并使用無發行版鏡像來減少攻擊面。
不要使用 root 使用者和特權容器。
使用 Gvisor 和 Kata 容器進行核心隔離。
使用容器鏡像簽名和驗證。
設定已知良好容器系統資料庫的清單。
實施容器安全最佳實踐。

軟體供應鍊安全

供應鍊安全對于軟體産品的整體安全至關重要。可以控制供應鍊中某個步驟的攻擊者可以針對惡意意圖更改産品，從在源代碼中引入後門到在最終産品中包含易受攻擊的庫。

- 整體規格

根據Anchore 2022 年軟體供應鍊安全報告，62% 的受訪組織受到軟體供應鍊攻擊的影響。當我們掃描所有軟體元件（如代碼、SBOM、容器、基礎設施、簽名和驗證容器等）時，實施 DevSecOps CI/CD 顯着減少了供應鍊攻擊。

網際網路安全中心 (CIS) 标準

CIS 是一個非營利組織，提供安全标準基準來保護我們的基礎設施。遵循 CIS 基準的好處之一是它直接映射到多個既定标準指南，包括 NIST 網絡安全架構 (CSF)、ISO 27000 系列标準、PCI DSS、HIPAA 等。此外，2 級 CIS 基準提供了更多的安全控制。

漏洞評估和滲透測試 (VAPT)

VAPT 是組織用來測試其應用程式、網絡、端點和雲的一種安全測試方法。它可以由内部和外部第三方供應商執行。根據合規性和法規以及技術的風險程度，組織确實會安排每季度、每半年或每年一次的 VPAT 掃描。

漏洞評估

漏洞評估 (VA) 是識别應用程式、系統或網絡中的弱點或漏洞的安全過程。漏洞評估旨在确定所有漏洞并幫助營運商修複它們。 DAST 掃描也是漏洞評估的一部分，它通常很快，從 10 分鐘到 48 小時不等，具體取決于配置。它更容易與我們的 CI/CD 管道內建，而滲透測試超越了 VA，并在發現任何漏洞後進行積極的掃描和利用。

滲透測試

筆測試是一種主動的網絡安全實踐，安全專家針對單個元件或整個應用程式來查找可被利用來破壞應用程式和資料的漏洞。 ZAP 、 Metasploit和 Burp Suite 可用于滲透測試并發現 SAST 和 DAST 工具可能遺漏的漏洞。筆測試的缺點是它需要更多時間，具體取決于覆寫範圍和配置。正确的滲透測試可能需要長達數周的時間，并且随着 DevOps 的開發速度，它變得不可持續。但是，仍然值得添加内部 VAPT，它可以在每個功能版本上完成以快速移動。外部 VAPT 可以每半年或每年進行一次，以控制整體安全性。

結論

為了快速回顧我們為建立 DevSecOps 管道所做的工作，我們掃描了機密、SAST 和 SBOM，以查找代碼中的任何漏洞。之後，我們掃描了我們的 Dockerfile、容器鏡像、Kubernetes 清單，并進行了容器驗證測試，并簽署了我們的容器鏡像以確定它是安全的。部署後，我們進行了 Smoke、API 測試和 DAST 掃描，以確定部署中沒有錯誤。永遠記住安全需要不斷的關注和改進。然而，這些可能是邁向 DevSecOps 永無止境的第一步。

實施 DevSecOps 最佳實踐可降低漏洞和黑客攻擊的風險。掃描您的基礎設施和應用程式的所有部分，可以全面了解潛在威脅和可能的補救方法。“確定安全的唯一方法是擁有多層安全性”，是以我們讨論了可用于發現漏洞的多種方法和工具。

以下是我們用來設定 DevSecOps 管道的一些工具的清單。

我希望這篇文章内容豐富，你喜歡閱讀它。

實施 DevSecOps 以保護您的 CI/CD 管道