安全组件扫描工具owasp/dependency-check 使用

项目里需要安全组件扫描报告，之前没用过，踩过一些坑，特地记录下

Dependency-Check概述

Dependency-Check 是 OWASP（Open Web Application Security Project）的一个实用开源程序，用于识别项目依赖项并检查是否存在任何已知的，公开披露的漏洞。目前，已支持Java、.NET、Ruby、Node.js、Python等语言编写的程序，并为C/C++构建系统（autoconf和cmake）提供了有限的支持。而且该工具还是OWASP Top 10的解决方案的一部分。
Dependency-Check 支持面广（支持多种语言）、可集成性强，作为一款开源工具，在多年来的发展中已经支持和许多主流的软件进行集成，比如：命令行、Ant、Maven、Gradle、Jenkins、Sonar等；具备使用方便，落地简单等优势。
Dependency-Check 官网：https://owasp.org/www-project-dependency-check/

Dependency-Check实现原理

依赖性检查可用于扫描应用程序（及其依赖库），执行检查时会将 Common Platform Enumeration (CPE)国家漏洞数据库及NPM Public Advisories库下载到本地，再通过核心引擎中的一系列分析器检查项目依赖性，收集有关依赖项。

NVD概述

Dependency-Check依赖NVD漏洞数据库(美国国家通用漏洞数据库)进行依赖漏洞检查(全球信息安全领域著名的漏洞数据库包括中国国家信息安全漏洞库，美国国家信息安全漏洞库NVD，赛门铁克漏洞库等等)官网：https://nvd.nist.gov/

NVD的更新频率是出现问题实时更新，具体链接：https://nvd.nist.gov/general/nvd-dashboard

1.配置dependency-check环境，下载NVD数据库

一开始想到的是通过docker操作

下载镜像 owasp/dependency-check

docker hub上有使用脚本

#!/bin/sh
  
DC_VERSION="latest"
DC_DIRECTORY=$HOME/OWASP-Dependency-Check
DC_PROJECT="dependency-check scan: $(pwd)"
DATA_DIRECTORY="$DC_DIRECTORY/data"
CACHE_DIRECTORY="$DC_DIRECTORY/data/cache"

if [ ! -d "$DATA_DIRECTORY" ]; then
    echo "Initially creating persistent directory: $DATA_DIRECTORY"
    mkdir -p "$DATA_DIRECTORY"
fi
if [ ! -d "$CACHE_DIRECTORY" ]; then
    echo "Initially creating persistent directory: $CACHE_DIRECTORY"
    mkdir -p "$CACHE_DIRECTORY"
fi

# Make sure we are using the latest version
docker pull owasp/dependency-check:$DC_VERSION

docker run --rm \
    -e user=$USER \-u $(id -u ${USER}):$(id -g ${USER}) \
    --volume $(pwd):/src:z \
    --volume "$DATA_DIRECTORY":/usr/share/dependency-check/data:z \
    --volume $(pwd)/odc-reports:/report:z \
    owasp/dependency-check:$DC_VERSION \
    --scan /src \
    --format "ALL" \
    --project "$DC_PROJECT" \
    --out /report
    # Use suppression like this: (where /src == $pwd)
    # --suppression "/src/security/dependency-check-suppression.xml"

根据脚本 --volume $(pwd):/src:z 得知扫描目录就是执行脚本的当前目录

于是把需要扫描的jar包放到当前目录，执行脚本

问题来了，NVD 数据下载特别慢，而且经常下到一般就中断了，又要重新下载，试了几次还是无解

就在我焦头烂额的时候注意到了这句话

[WARN] An NVD API Key was not provided - it is highly recommended to use an NVD API key as the update can take a VERY long time without an API Key

没有 NVD API Key 会影响更新速度？果断安排上！

https://nvd.nist.gov/developers/request-an-api-key

申请点提交又遇到了无法连接到 reCAPTCHA 服务。请检查您的互联网连接,然后重新加载网页以获取 reCAP 报错

于是参考 https://blog.csdn.net/Alan_Wdd/article/details/144569424

使用gooreplacer插件

一番配置后解决问题

后面是需要在docker容器中配置NVD API Key 参数

首先查看help

docker run --rm owasp/dependency-check --help

得到参数--nvdApiKey

修改docker启动命令，添加--nvdApiKey 参数

#!/bin/sh
  
DC_VERSION="latest"
DC_DIRECTORY=$HOME/OWASP-Dependency-Check
DC_PROJECT="dependency-check scan: $(pwd)"
DATA_DIRECTORY="$DC_DIRECTORY/data"
CACHE_DIRECTORY="$DC_DIRECTORY/data/cache"

if [ ! -d "$DATA_DIRECTORY" ]; then
    echo "Initially creating persistent directory: $DATA_DIRECTORY"
    mkdir -p "$DATA_DIRECTORY"
fi
if [ ! -d "$CACHE_DIRECTORY" ]; then
    echo "Initially creating persistent directory: $CACHE_DIRECTORY"
    mkdir -p "$CACHE_DIRECTORY"
fi

# Make sure we are using the latest version
docker pull owasp/dependency-check:$DC_VERSION

docker run --rm \
    -e user=$USER \
    -u $(id -u ${USER}):$(id -g ${USER}) \
    --volume $(pwd):/src:z \
    --volume "$DATA_DIRECTORY":/usr/share/dependency-check/data:z \
    --volume $(pwd)/odc-reports:/report:z \
    owasp/dependency-check:$DC_VERSION \
    --nvdApiKey your_api_key_here \
    --scan /src \
    --format "ALL" \
    --project "$DC_PROJECT" \
    --out /report
    # Use suppression like this: (where /src == $pwd)
    # --suppression "/src/security/dependency-check-suppression.xml"

其实这里也困扰我好久，一开始用-e参数添加，没有效果

问过AI之后才知道，要放在镜像后面，让entrypoint带入参数，作为程序启动参数，很基础的知识对吧，但是没亲自用过，就是没啥印象 :(

经过大概1小时，nvd数据总算下完了

其实也可以不通过docker，直接下载 dependency-check程序，本地运行也可以

首先下载 jre11（ dependency-check运行jre版本为11）：https://adoptium.net/zh-CN/temurin/archive/?version=11

然后下载 dependency-check程序 https://owasp.org/www-project-dependency-check/

下载解压后，编辑 dependency-check\bin\dependency-check.bat配置jre环境

在bin目录打开cmd窗口，地址栏输入cmd直接回车

运行命令下载nvd数据库

dependency-check.bat --nvdApiKey=your_api_key_here --updateonly

至此 nvd数据库下载完成

另外还看到有人分享，替换http依赖包解决下载nvd数据库超时问题，暂时没遇到，记录下，以备不时之需

https://blog.csdn.net/GalaxySpaceX/article/details/145781292

抓包看了一下卡死后，程序会进入阻塞，不会在进行下载，分析应该是多次超时后进入等待，没有重新挂起，然后看了下官方的更新解释，估计应该是第三方jar包的问题，直接列出出问题的jar

问题就出现在httpclient5-5.4.2.jar；httpcore5-5.3.3.jar；httpcore5-h2-5.3.3.jar

原因如下，5.4.2版本要求如果 `Connection` 标头已经存在，则不要添加 `Upgrade` 标头（调用者手动管理连接状态），由此由于调用者接管了连接状态，当超时次数过多或其他异常没有处理就会进入等待状态，反应到前端就是卡死不动了

解决办法也很简单，不使用最新版本的，降低版本到如下三个

httpclient5-5.4.1.jar；httpcore5-5.3.2.jar；httpcore5-h2-5.3.1.jar

2.扫描jar包生成报告

docker环境的，很简单，把jar包拷贝到脚本当前目录，执行脚本即可，报告会在当前目录的 odc-reports 里面

cmd方式可以在cmd窗口执行命令

dependency-check.bat -n  --failOnCVSS 7 --project "unisystem" --scan "E:\\jars\app.jar" -o "E:\\reports"

注意，这里目录名称不能有中文，扫描的目录要指定jar包名称或者写成 *.jar

-n 是不更新扫描

failBuildOnCVSS 表示失败的告警阈值，不影响扫描结果。通过设置合理的阈值，开发者可以确保他们的项目不会因为包含高风险漏洞的依赖而构建成功，进而避免潜在的安全风险。

3.分析过报告概览后查看报告详细信息

dependency-check version(工具版本): 12.1.0
Report Generated On(报告生成时间): Thu, 12 Dec 2024 09:30:44 +0800
Dependencies Scanned(依赖项扫描数): 259 (191 unique)
Vulnerable Dependencies(漏洞依赖项数): 57
Vulnerabilities Found(总计漏洞数): 184
Vulnerabilities Suppressed(抑制的漏洞数): 0（抑制的漏洞指的是在扫描过程中，被工具识别并且被用户或配置文件明确忽略的漏洞数量。这些被“抑制”的漏洞不会出现在最终的报告中）

Dependency	Vulnerability IDs	Package	Highest Severity	CVE Count	Confidence	Evidence Count
代表存在漏洞的依赖项	代表对应NVD的漏洞ID	代表依赖中的包	代表漏洞的严重程度	代表与依赖包与漏洞关联的数量	代表工具对漏洞检测结果的置信度	代表支持该漏洞检测结果的证据数量

CVSS概述

NVD评级依赖CVSS(CommonVulnerability Scoring System)，即“通用漏洞评分系统”，是一个“行业公开标准，其被设计用来评测漏洞的严重程度，并帮助确定所需反应的紧急度和重要度，具体评分标准如下：

1）CRITICAL（9.0 - 10.0）：这些漏洞通常具有最高的严重性，可能导致远程代码执行、大规模数据泄露、系统完全被攻陷等影响。应立即修复或采取其他补救措施。
2）HIGH（7.0 - 8.9）：这些漏洞可能会导致重大安全问题，如数据泄露、拒绝服务攻击等。应尽快修复。
3）MEDIUM（4.0 - 6.9）：这些漏洞可能会导致中等程度的安全问题，但利用难度较大或者影响范围有限。虽然不需要紧急处理，但应在合理的时间内修复。
4）LOW（0.1 - 3.9）：这些漏洞通常不会造成重大影响。可以在日常维护过程中进行修复。
5）NONE*（0）：无问题。

Dependency-Check报告漏洞划分标准

Dependency-check对漏洞严重程度判定有四档分别为：

1）CRITICAL：这些漏洞通常会导致非常严重的后果，如远程代码执行、大规模数据泄露等。应优先处理。
2）HIGH：高危漏洞可能导致严重的后果，但不一定能直接被利用。也应尽快修复。
3）MEDIUM：中等风险漏洞可能会导致较大的安全问题，但利用难度较大或影响范围有限。
4）LOW：低风险漏洞一般不会造成重大影响，但在有余力的情况下也应考虑修复。