Важная частка кіравання ўразлівасцямі складаецца ў тым, каб добра разумець і гарантаваць бяспеку ланцужкі паставак тых кампанентаў ПЗ, з якіх будуюцца сучасныя сістэмы. Каманды, якія практыкуюць гнуткія методыкі і DevOps, шырока прымяняюць бібліятэкі і каркасы з адкрытым зыходным кодам, каб скараціць час і кошт распрацоўкі. Але гэты медаль мае і адваротны бок: магчымасць атрымаць у спадчыну чужыя памылкі і ўразлівасці.
Відавочна, каманда павінна абавязкова ведаць, якія кампаненты з адчыненым зыходным кодам уключаны ў яе прыкладанні, сачыць за тым, каб загадзя надзейныя версіі спампоўваліся з загадзя надзейных крыніц, і загружаць абноўленыя версіі кампанентаў пасля выпраўлення ізноў выяўленых уразлівасцяў.
У гэтым пасце разгледзім выкарыстанне OWASP Dependency Check для перапынення зборкі ў выпадку выяўлення сур'ёзных праблем з вашым кодам.
У кнізе "Бяспека распрацоўкі ў Agile-праектах" апісаны так. OWASP Dependency Check - гэта бясплатны сканер, які каталагізуе ўсе выкарыстоўваныя ў дадатку кампаненты з адкрытым зыходным кодам і паказвае наяўныя ў іх уразлівасці. Маюцца версіі для Java, .NET, Ruby (gemspec), PHP (composer), Node.js і Python, а таксама для некаторых праектаў на C/C++. Dependency Check інтэгруецца з распаўсюджанымі сродкамі зборкі, у т. ч. Ant, Maven і Gradle і серверамі бесперапыннай інтэграцыі тыпу Jenkins.
Dependency Check паведамляе аб усіх кампанентах з вядомымі ўразлівасцямі з Нацыянальнай базы дадзеных уразлівасцяў (NVD) NIST і абнаўляецца на падставе дадзеных з навінавых каналаў NVD.
На шчасце, усё гэта можна рабіць аўтаматычна з дапамогай такіх прылад, як праект OWASP Dependency Check, або камерцыйных праграм тыпу , , , кампаніі Sonatype або .
Гэтыя прылады можна ўключыць у зборачныя канвееры, каб аўтаматычна складаць вопіс залежнасцяў з адчыненым зыходным кодам, выяўляць састарэлыя версіі бібліятэк і бібліятэкі, утрымоўвальныя вядомыя ўразлівасці, і перарываць зборку ў выпадку выяўлення сур'ёзных праблем.
OWASP Dependency Check
Для тэставання і дэманстрацыі працы Dependency Check выкарыстоўваем гэты рэпазітар .
Для прагляду HTML справаздачы трэба наладзіць web-сэрвэр nginx на вашым gitlab-runner.
Прыклад мінімальнага канфіга nginx:
server {
listen 9999;
listen [::]:9999;
server_name _;
root /home/gitlab-runner/builds;
location / {
autoindex on;
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}У канцы зборкі вы можаце бачыць вось такую карціну:
Пераходзім па спасылцы і бачым справаздачу Dependency Check.
Першы скрыншот - верхняя частка справаздачы з кароткім зместам.
Другі скрыншот падрабязнасці CVE-2017-5638. Тут мы бачым узровень CVE і спасылкі на эксплоіты.
Трэці скрыншот - падрабязнасці log4j-api-2.7.jar. Бачым што ўзроўні CVE 7.5/9.8 і XNUMX/XNUMX.
Чацвёрты скрыншот - падрабязнасці commons-fileupload-1.3.2.jar. Бачым што ўзроўні CVE 7.5/9.8 і XNUMX/XNUMX.
Калі вы жадаеце выкарыстоўваць gitlab pages, тое не атрымаецца - якая падала цяга не створыць артэфакт.
Прыклад тут .
Выснова зборкі: артэфактаў няма, html справаздачы не бачу. Трэба паспрабаваць Artifact: always
Рэгуляванне ўзроўню CVE уразлівасцяў
Самы галоўны радок у файле gitlab-ci.yaml:
mvn $MAVEN_CLI_OPTS test org.owasp:dependency-check-maven:check -DfailBuildOnCVSS=7Параметрам failBuildOnCVSS вы можаце рэгуляваць узровень CVE уразлівасцяў, на якія трэба рэагаваць.
Спампоўванне з інтэрнэту базы дадзеных уразлівасцяў (NVD) NIST
Вы заўважылі што ўвесь час спампоўвае базы дадзеных уразлівасцяў (NVD) NIST з інтэрнэту:
Для спампоўкі можна выкарыстоўваць утыліту
Усталюем і запусцім яе.
yum -y install yum-plugin-copr
yum copr enable antonpatsev/nist_data_mirror_golang
yum -y install nist-data-mirror
systemctl start nist-data-mirrorNist-data-mirror запампоўвае CVE JSON NIST у /var/www/repos/nist-data-mirror/ пры запуску і абнаўляе дадзеныя кожныя 24 гадзіны.
Для спампоўкі CVE JSON NIST трэба наладзіць web-сервер nginx (напрыклад на вашым gitlab-runner).
Прыклад мінімальнага канфіга nginx:
server {
listen 12345;
listen [::]:12345;
server_name _;
root /var/www/repos/nist-data-mirror/;
location / {
autoindex on;
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}Каб не рабіць доўгі радок дзе запускаецца mvn вынесем параметры ў асобную зменную DEPENDENCY_OPTS.
Выніковы мінімальны канфіг .gitlab-ci.yml атрымаецца вось так:
variables:
MAVEN_OPTS: "-Dhttps.protocols=TLSv1.2 -Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=WARN -Dorg.slf4j.simpleLogger.showDateTime=true -Djava.awt.headless=true"
MAVEN_CLI_OPTS: "--batch-mode --errors --fail-at-end --show-version -DinstallAtEnd=true -DdeployAtEnd=true"
DEPENDENCY_OPTS: "-DfailBuildOnCVSS=7 -DcveUrlModified=http://localhost:12345/nvdcve-1.1-modified.json.gz -DcveUrlBase=http://localhost:12345/nvdcve-1.1-%d.json.gz"
cache:
paths:
- .m2/repository
verify:
stage: test
script:
- set +e
- mvn $MAVEN_CLI_OPTS install org.owasp:dependency-check-maven:check $DEPENDENCY_OPTS || EXIT_CODE=$?
- export PATH_WITHOUT_HOME=$(pwd | sed -e "s//home/gitlab-runner/builds//g")
- echo "************************* URL Dependency-check-report.html *************************"
- echo "http://$HOSTNAME:9999$PATH_WITHOUT_HOME/target/dependency-check-report.html"
- set -e
- exit ${EXIT_CODE}
tags:
- shell
Крыніца: habr.com