SlideShare a Scribd company logo

Aleksei Dremin - Application Security Pipeline - phdays9

•Download as PPTX, PDF•
•
A
Alexey Dremin

This document discusses setting up an application security pipeline for continuous integration and delivery (CI/CD). It recommends using static application security testing (SAST) tools, dependency checkers, source code scanners, dynamic application security testing (DAST) tools, and integrating them with Jenkins. It also suggests managing vulnerabilities and results in DefectDojo and notifying stakeholders of new findings through integration with communication tools like Slack. The document stresses the importance of educating developers on security best practices.

1 of 25
Заголовок ptsecurity.com AppSec Pipeline Application Security Lead Dremin Alexey
Заголовок 2 • Security Engineer / Application Security Lead • CISSP Professional • What I do: • DevSecOps • Vulnerability management • Design architecture of infrastructure (AWS/Azure) • Development • Twitter: @alekseidremin • dremin.aleksei@gmail.com About me
Заголовок • All products mentioned in the presentation are given merely as an example. • Their mention should not be considered as a recommendation for the use of these particular products. • Disclaimer 3
Заголовок 4 • Know what is happening in our source code • Know which libraries we’re using. Licensing issues? Vulnerabilities? • Find the problems as early as possible: shift left • Company is growing very quickly: this cannot be a manual process Why do we need security in our CI/CD pipeline?
Заголовок 5 • Reduce the risk of being hacked, as soon as possible • Stay compliant with legal team’s policies on licenses How will it help?
Заголовок 6 Application Security Pipeline
Заголовок 7 SAST Tools?
Заголовок 8 •Free/Free minimum: • OWASP Dependency Check • NPM audit • Snyk • Safety • RetireJS •Commercial: • WhiteHat • Veracode (https://www.sourceclear.com/) • Nexus-auditor • PT Application Inspector • and many others For most of commercial SAST that feature is already by default Dependency Checkers?
Заголовок 9 • Scan Python code • Identifies vulnerabilities in Python code third party libraries • Can be your database, or someone else’s (e.g., NIST NVD) • Get it here: https://github.com/pyupio/safety Internal vulnerability database dependency checker
Заголовок 10 • Free (for python) • Bandit https://github.com/openstack/bandit • Pyt https://github.com/python-security/pyt • Pyre https://github.com/facebook/pyre-check • SonarQube (more for developers) • Commercial • WhiteHat • Veracode • Checkmarx • Synopsis • PT Application Inspector Source code checkers?
Заголовок 11 • Use security guidelines for frameworks • Search specific dangerous words in code such as: • For Django - mark_safe(), extra(), RawSQL • For React – dangerouslySetInnerHTML() or innerHTML • Catch changes: • What and when it happened • Configuration files • requirements.txt/packages.lock Catch something dangerous
Заголовок 12 • Safety in enterprise versions is able to provide info about licenses of dependencies • ScanCode toolkit • Veracode/Whitehat and other commercial scanners • AquaSec checks licenses of libraries in docker images Check licenses of used dependencies?
Заголовок 13 • Many source code scanners do it • But they can’t cover all situations • Use specialized tools like: • GitLeaks • TruffleHog • Gitrob • and many other clones. • User defined patterns • Look for the patterns in: • log aggregation tools (e.g., Splunk) • Messaging apps (e.g., Slack) • Ticket systems such as JIRA Hunt for leaked credentials: problems
Заголовок 14 DAST
Заголовок 15 Integration with SQA automatic tests
Заголовок 16 • Burp in docker • Active and Passive mode • Get reports from Burp • vmware/burp-rest-api REST/JSON API to the Burp Burp
Заголовок 17 • Jenkins is core • All our tools running in Jenkins. • All results store in s3 bucket and specific vulnerability management db • Parametrized Jenkins jobs • Manage Jenkins from source code Jenkins
Заголовок 18 • DefectDojo • ThreadFix • Faradaysec • Dradis • ArcherySec Do you want to manage results and how?
Заголовок 19 DefectDojo
Заголовок 20 • Import scan results of various security tools by default • Your own plugins for uploaded results of security tools • Equivalent findings get marked as duplicate Important things about Vulnerability management program
Заголовок 21 • Mark findings as false, true positive • Similar findings are merged • Set and show remediation timeframes • Jira/Slack/Email for notification Important things about Vulnerability management program
Заголовок 22 •Integration with our chosen vulnerability management program •Get reports about new findings every day. •Get information about which findings is old and doesn’t appear more. •Maybe problems was fixed or something was broken in your scans. Notifications
Заголовок 23 Notifications
Заголовок 24 • Tools: • Security Code Warrior • Veracode • Checkmarx • Start your internal guideline for developers: • Which libs should be used • Best security practice for frameworks • Make friends with the dev team who care about security • Transparency of your job for dev team. Do not only notify them, talk to them is not less important. Developer Education program
Заголовок ptsecurity.com Спасибо! Спасибо!

More Related Content

Aleksei Dremin - Application Security Pipeline - phdays9

Editor's Notes

  1. Как вы видите процесс состоит из 4 компонент. Инциализация, Проверка, Отчет, Уведомление В процессе моей работы их не было столько. Мы начинали с компоненты проверка. И уже потом постепенно формализовывали весь процесс, выводили отдельные его шаги. Рассказать о каждом шаге.
  2. Все эти приложения мы запускаем так или иначе в Jenkins. Можно посмотреть историю их запусков. Совет – поставьте нотификации если джоба упала и запуск джобы по крайней мере раз в день. Их проверки не занимают много времени и ресурсов, зато мы уменьшим риск того что в прошлый запуск что то не сработало и соответственно не нашлось никаких проблем
  3. Они все говорят что используют их базу уязвимостей, но на практике все идет с NVD и кое кто смотри PL популярных библиотек на предмет обсуждения уязвимостей. Часто для не больших либ не создают CVE в базе и узнать что была или есть уязвимость можно только просматривать тикеты и PL в репозитории библиотеки. Часть тикеты или PL как то помечают, например тегом security. Другой способ узнавания об уязвмостях в библиотеках это просматривать публичные репорты с BugCrowd и HackerOne.
  4. Часто бывает, что у вас есть ваши внутренние библиотеки, которые вы используете во множестве проектов. Если вдруг в этой библиотеке была найдена проблема, то достаточно добавить запись об этой библиотеке и проблемной версии в вашу внутреннею NVD и принудительно запустить сканирование всех проектов. Через достаточно короткое время вы будете знать в каких проектах используется эта библиотека с проблемной версией.
  5. SonarQube as platform for review source code findings Bandit has integration New rules can be added into SonarQube
  6. Примеров опасных функций можно найти довольно много, в каждом фреймворке есть свои гайдлайны для этого. Если нет официальных, то просто поищите в гугле. Найдете очень много статей, именно про ваш фреймворк. Проверяйте каждый пуш/PL в репозиторий. Если в коммите будет потенциально опасный файл или опасная функция, то дайте себе знать. Потом в ручном режиме просмотрите изменения. Безопасны ли они? Возможно другие SAST приложения, тоже смогут найти проблемы, но это нормально. В нашем случае, лучше получить несколько одинаковых находок с разных тулов, чем не получить вообще.
  7. Часто никто даже не задумывается, что нужна еще проверка лицензии используемых библиотек.
  8. Use different runs for different types of scans Scan only XSS, SQLinj, Misc