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.
2. Заголовок
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
3. Заголовок
• 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. Заголовок
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. Заголовок
5
• Reduce the risk of being hacked,
as soon as possible
• Stay compliant with legal team’s
policies on licenses
How will it help?
8. Заголовок
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. Заголовок
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
11. Заголовок
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. Заголовок
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. Заголовок
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
16. Заголовок
16
• Burp in docker
• Active and Passive mode
• Get reports from Burp
• vmware/burp-rest-api REST/JSON API to the Burp
Burp
17. Заголовок
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
20. Заголовок
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. Заголовок
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. Заголовок
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
24. Заголовок
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
Как вы видите процесс состоит из 4 компонент. Инциализация, Проверка, Отчет, Уведомление
В процессе моей работы их не было столько. Мы начинали с компоненты проверка. И уже потом постепенно формализовывали весь процесс, выводили отдельные его шаги.
Рассказать о каждом шаге.
Все эти приложения мы запускаем так или иначе в Jenkins. Можно посмотреть историю их запусков. Совет – поставьте нотификации если джоба упала и запуск джобы по крайней мере раз в день. Их проверки не занимают много времени и ресурсов, зато мы уменьшим риск того что в прошлый запуск что то не сработало и соответственно не нашлось никаких проблем
Они все говорят что используют их базу уязвимостей, но на практике все идет с NVD и кое кто смотри PL популярных библиотек на предмет обсуждения уязвимостей. Часто для не больших либ не создают CVE в базе и узнать что была или есть уязвимость можно только просматривать тикеты и PL в репозитории библиотеки. Часть тикеты или PL как то помечают, например тегом security.
Другой способ узнавания об уязвмостях в библиотеках это просматривать публичные репорты с BugCrowd и HackerOne.
Часто бывает, что у вас есть ваши внутренние библиотеки, которые вы используете во множестве проектов. Если вдруг в этой библиотеке была найдена проблема, то достаточно добавить запись об этой библиотеке и проблемной версии в вашу внутреннею NVD и принудительно запустить сканирование всех проектов. Через достаточно короткое время вы будете знать в каких проектах используется эта библиотека с проблемной версией.
SonarQube as platform for review source code findings
Bandit has integration
New rules can be added into SonarQube
Примеров опасных функций можно найти довольно много, в каждом фреймворке есть свои гайдлайны для этого. Если нет официальных, то просто поищите в гугле. Найдете очень много статей, именно про ваш фреймворк.
Проверяйте каждый пуш/PL в репозиторий. Если в коммите будет потенциально опасный файл или опасная функция, то дайте себе знать. Потом в ручном режиме просмотрите изменения. Безопасны ли они? Возможно другие SAST приложения, тоже смогут найти проблемы, но это нормально. В нашем случае, лучше получить несколько одинаковых находок с разных тулов, чем не получить вообще.
Часто никто даже не задумывается, что нужна еще проверка лицензии используемых библиотек.
Use different runs for different types of scans
Scan only XSS, SQLinj, Misc
