实施 DevSecOps 以保护您的 CI/CD 管道

每日分享最新，最流行的软件开发知识与最新行业趋势，希望大家能够一键三连，多多支持，跪求关注，点赞，留言。

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 阶段以及如何保护它们：

1. 计划/设计
2. 开发
3. 构建和代码分析
4. 测试
5. 部署

让我们深入了解如何实施 DevSecOps。

1. 计划/设计

在这个阶段，我们将概述集成、部署和安全测试将在何处、如何以及何时进行。

1.1 威胁建模

它有效地将您置于攻击者的思维模式中，并允许我们通过攻击者的眼睛看到应用程序，并在他们有机会采取任何行动之前阻止他们的攻击。我们可以使用 OWASP 威胁建模或 Microsoft 的简单问题方法来设计我们的威胁建模。我们还可以使用 OWASP Threat Dragon 和Cairis开源威胁建模工具为我们的安全开发生命周期创建威胁模型图。

1.2 安全 SDLC

安全 SDLC 需要在每个软件开发阶段（从设计到开发、再到部署等）添加安全测试。示例包括设计应用程序以确保您的架构是安全的，并将安全风险因素作为初始规划阶段的一部分。
– Snyk 安全 SDLC

在一个安全的软件开发周期中，我们应该将我们的开发、测试和生产环境分开，并且还应该有控制从一个环境到另一个环境的部署升级的授权过程。这降低了开发人员进行未经授权的更改的风险，并确保任何修改都通过标准的批准流程。

2. 开发

开发阶段从编写代码开始，我们可以使用左移安全最佳实践，它在开发的最早阶段结合了安全思维。例如：

使用预提交挂钩来防止向代码添加任何秘密。

设置受保护的分支和代码审查流程。

使用 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

3.4 单元测试

在单元测试中，检查各个软件代码组件以确保其按预期工作。单元测试隔离代码的功能或模块并验证其正确性。我们可以使用JaCoCo for Java 和 Mocha 和 Jasmine for NodeJS 等工具来生成单元测试 告。最后，我们可以将这些 告发送到 SonarQube，它会向我们显示代码覆盖率以及测试用例覆盖的代码百分比。

一旦 SAST 完成，我们也可以扫描 Dockerfile。

3.5 Dockerfile 静态扫描

始终扫描 Dockerfile 以查找漏洞，因为在编写 Dockerfile 时，我们可能会错过一些 Dockerfile 最佳实践，这可能会导致容器易受攻击。举几个我们可以避免的常见错误。

1. 不要使用最新的 docker 镜像标签。
2. 确保已创建容器的用户。

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 管道的一些工具的列表。

我希望这篇文章内容丰富，你喜欢阅读它。