sonarqube integrated dependencycheck

Environment overview:

SonarQube：7.7
SonarScanner：3.10.0

Install plug-ins

Sonarqube dependency check plug in project address

To download, please pay attention to the version. At present, GitHub supports 6. X and 7. X. what I download here is:

sonar-dependency-check-plugin-1.2.3.jar

After downloading, place it in the plug-in directory of sonarqube, and then restart it.

There are several articles on the Internet that have mentioned that paths need to be configured here, but in fact, they can not be configured. We can use sonarscanner to transmit to sonarqube. (see end of article for reference)

Perform scan: resolve sonarqube cannot find Report

INFO: Dependency-Check HTML report does not exists

After stepping on this pit for a long time, I also communicated with the author of GitHub, who reminded me that I needed my husband to make a report.

Generate report tool: dependencycheck

# 下载工具
bash bin/dependency-check.sh -h

# 测试，我这里是结合SonarScanner + Gitlab-CI进行分析
# 配置Gitlab-CI文件

stages:
  - sast
sast:
  stage: sast
  script:
    - mvn package -DskipTests # 编译项目
    - mkdir $PWD/reports # 创建报告目录
    - /home/gitlab-runner/dependency-check/bin/dependency-check.sh -s $PWD/ -f XML -o $PWD/reports/dependency-check-report.xml # 生成报告
    - /home/gitlab-runner/dependency-check/bin/dependency-check.sh -s $PWD/ -f HTML -o $PWD/reports/dependency-check-report.html # 生成报告
    - sonar-scanner -Dsonar.host.url=http://10.10.10.12:9000 -Dsonar.login=token -Dsonar.projectKey=$CI_PROJECT_NAME:$CI_COMMIT_REF_NAME -Dsonar.java.binaries=$PWD -Dsonar.dependencyCheck.reportPath=$PWD/reports/dependency-check-report.xml -Dsonar.dependencyCheck.htmlReportPath=$PWD/reports/dependency-check-report.html # 执行SonarScanner扫描，并将DependencyCheck的结果传输给SonarQube
  tags:
    - sec1

Sonarqube results:

Reflection

Where to perform third-party dependency scanning

Since the tool to scan the third party depends on is to scan the jar package, you need to compile the project before scanning, otherwise it will have no effect. The test method is as follows:

# 在Gitlab-CI中去掉编译项目这一步
# 扫描结果如图

So in the code submission phase (in the form of this article), there will be a problem of resource reuse, because the project will also compile when it is released, which will lead to a repeated compilation. So the recommended action is to trigger the pipelines action when Jenkins is packaged. At this time, code packaging is generally released to the test environment (QA). We find security problems and can arrange to fix them.

How the loopholes found by scanning form a closed loop

Depending on the package, many vulnerabilities may be scanned. How to form a closed loop for these vulnerabilities should be considered in several aspects:

Does the vulnerability need to be fixed? : serious and high risk need to be repaired. Repair cost of vulnerability
How do vulnerabilities that need to be fixed form an automated tracking process? : submit manually to the vulnerability management platform, or use the sonarqube API to write scripts to submit automatically. On vulnerability lifecycle management

Vulnerability accuracy

There may be many false positives in the scanned vulnerability, or the vulnerability cannot be exploited successfully. At this time, we need to manually verify the vulnerability. So thinking about how to solve the vulnerability accuracy becomes the next problem to be solved.

Reference material

Linux EA: gitlab CI / CD dependency two ways (5)

IMCAFS