Holistic.dev - static sql analyzer

Пока еще продолжает идти хайп на Flipper Zero, предлагаю посмотреть на также весьма интересный молодой проект.

Holistic.dev - это статический анализатор в виде SaaS. Принимает на вход схемы DBA, после чего выводит результаты, сообщающие проблемы как в производительности, так и в безопасности. Так, например, сервис может предотвратить утечку данных или сообщить о наличии запросов, требующих чрезмерное количество данных.

На данный момент сервис бесплатный, поддерживается синтаксис Postgresql до 13 версии включительно.

Подробнее вы можете прочитать в заметках автора проекта в телеграм-канале. У @antonrevyako в планах развивать проект, увеличить число правил и поддерживаемых БД, после чего попытаться внедрить сервис в популярные облачные провайдеры.

#tools #sast #dev

Pysa: An open source static analysis tool to detect and prevent security issues in Python code

Статья от Facebook о работе их open source статического анализатора кода на Python - Pysa, которого они используют для поиска дефекта кода Instagram. Немного рассказывают про то, как Pysa обнаруживает фолзы, и как работает data flow analysis. В документации Pysa позиционируется как performant type checker. Pysa интегрируется с VSCode, но как и в Bandit результаты не приводятся к CWE, что нередко вызывает сложности при менеджменте дефектов.

https://www.facebook.com/notes/protect-the-graph/pyre-fast-type-checking-for-python/2048520695388071/

#sast #tools #dev

"SonarQube in Action" by G.Ann Cambell and Patroklos P.Papapetrou

#literature #sast #dev

Как написать правила для Checkmarx и не сойти с ума

Тем временем Юра(@Mr_R1p) выпустил статью по кастомным правилам Checkmarx. Это вторая статья в русскоговорящем сообществе, объясняющая queries в чеке (первая статья от Максима). Здесь есть и словарь, и методика написания правил и то, что можно уже использовать прямо сейчас в своих проектах. Плюс к статье прилагается полезное репо с правилами.

https://habr.com/ru/company/swordfish_security/blog/521396/

#sast #dev

Когда не умеешь писать на CodeQL, но надо написать data flow для поиска open redirect в JS

#пятничное #sast #dev

Taint Tracking, перевод статьи про Pysa и экспериментальный функционал Semgrep.

Только сейчас нашел перевод на Habr статьи про Pysa, которую я публиковал недавно. Напомню, что Pysa - статический анализатор от Facebook для Python проектов. Pysa представляет из себя модуль для open source проекта Pyre, который также, как и в CodeQL, позволяет описывать свой data flow с помощью taint tracking.

Taint tracking - это механизм отслеживания taint data - так называемых "испорченных" данных. Это данные, которые поступили на вход (как правило от клиента), прошли через написанный разработчиками код и попали в небезопасную функцию, что в свою очередь породило уязвимость. Описывается taint tracking везде через Source и Sink. Пример того, как это работает в CodeQL, можно увидеть на скриншоте. Здесь ищется код, в котором данные, передаваемые пользователем, через proces.argv попадают в fs.readFile(). Конструкция Taint Tracking является одной из самых популярных в CodeQL. На этом же механизме построен анализ данных в Pysa.

В документации Semgrep также недавно появилась страница с описанием taint tracking в качестве экспериментальной фичи в Python. Это должно значительно сократить объем необходимых правил для поиска багов и увеличить процент покрытия.

#sast #dev

Benchmarking Approach to Compare Web Applications Static Analysis Tools Detecting OWASP Top Ten Security Vulnerabilities

Любопытное сравнение инструментов статического анализа на ResearchGate от лета 2020 года в разрезе OWASP Top 10. Внутри больше цифр и графиков. Выводы остаются за вами.

#dev #sast

OpenSSF CVE Benchmark

День назад OpenSSF релизнули проект OpenSSF CVE Benchmark. Основная цель проекта - сравнивать инструменты SAST на реальных кодовых базах, в которых была найдена CVE до и после патча. По сути, это репо, содержащее скрипты, которые запускают на текущий момент ESLint, NodeJSScan и CodeQL против различных open-source проектов на GitHub. Ссылки, версии и уязвимость содержатся в JSON-файлах для каждой CVE (пока что только JavaScript и TypeScript). После запуска сканирования автоматически генерируется сравнение результатов в веб-морде с указанием на ложные срабатывания. В roadmap обещают больше тулов и CVE.

Похожий проект 4 года назад делала команда OWASP. Они написали 2740 test cases на Java и натравили на них различные инструменты SAST, в том числе туда попал DAST - OWASP ZAP. Среди SAST были и коммерческие инструменты. Запустить бенчмарки можно и сейчас на их репо. В отличие от OpenSSF бенчмарки от OWASP содержат непосредственно сам код, а не ссылку на репо.

#sast #dev

Semgrep for Cloud Security

Semgrep - инструмент статического анализа кода и всевозможных конфигурационных файлов. Он позволяет задавать паттерны, согласно которым будет осуществляться поиск той или иной конструкции в файле. В частности, учитывать одновременно сразу несколько конструкций для сокращения ложных срабатываний. На практике при анализе исходных кодов semgrep выдает все же достаточно много фолзов, уступая более умным инструментам вроде codeql.

Другое, отличное на мой взгляд, применение semgrep - terraform и kubernetes. В сравнении с OPA Conftest semgrep обладает более доступным языком описания запросов. Вот пример того, как могли бы выглядеть правила. Часть некоторых правил, с которых можно было бы начать, уже можно найти в репо semgrep-rules. Еще у semgrep есть удобный веб-интерфейс для тестирования правил.

#k8s #terraform #sast #ops #opa

State of Software Security

Со временем начинаю все меньше любить вендорские отчеты в виду большого колличетсва воды и минимальной ценности. Тем не менее заинтересовал последний отчет Veracode. Они проанализировали различные уязвимости с точки зрения их покрытия с помощью SAST и DAST - что из них эффективнее и при каких условиях, зависимость эффективности инструментов от частоты сканирования и способе их использования. Также рассматриваются уязвимости по степени их популярности и времени фикса.

Также в отчете отдельно рассматриваются "природные" (nature) и "приобретенные" (narture) факторы команды и то, как они влияют на безопасность приложений. К "природным" относятся масштабы организации и приложений, величины тех. долга безопасности. К "приобретенным" факторам относится все то, на что команда может повлиять, например, на частоту сканирования.

#sast #dast #sca #dev #report

HuskyCI - open source tool that orchestrates security tests

huskyCI - open-source утилита для упрощения встраивания статических анализаторов в процессы CI. Из поддерживаемых Bandit, Safety, Brakeman, Npm Audit, Yarn Audit, Gosec, SpotBugs с Find Sec Bugs, TFSec, GitLeaks. Есть клиентская и серверная части. Веб-морда для управления уязвимостями отсутствует, но можно отправить запрос на API для извлечения результатов из БД. Подробнее можно прочитать в документации.

https://github.com/globocom/huskyci

#dev #ops #sast #secret

CodeQL: SAST своими руками (и головой). Часть 1

Вводная статья от Паши Канна про CodeQL. Что это такое, как начать с этим работать и чем это может быть полезно. Ссылки в дополнительных материалах помогут разобрать вопрос чуть глубже.

Конечно, здесь ещё много чего нет про построение data flow, подводные камни и сопутствующие страдания, но на то это и первая часть. Кое-что про основы я писал здесь.

Кстати, также Паша запустил чат по обсуждению CodeQL.

https://habr.com/ru/company/swordfish_security/blog/541554/

#sast #dev

Infrastructure-as-code security tool compare

Сравнение инструментов для анализа конфигурационных файлов IaC: Checkov, Indeni Cloudrail, Kics, Snyk, Terrascan, Tfsec. В качестве тестовой выборки был взят Terraform для AWS. Каждый test-case можно увидеть в репо. Полезно также будет для понимания типовых ошибок.

#terraform #iac #sast #dev #ops

Mobsfscan - SAST for Android and iOS source code

mobsfscan - отдельный проект от MobSF, который направлен на поиск уязвимостей в исходном коде мобильных приложений (Java, Kotlin, Swift, Objective C). По факту это обертка вокруг правил semgrep и libsast, но результат может быть весьма полезным.

#mobile #sast #dev

Up to 40 Percent Of GitHub Copilot Generated Code May Be Insecure

Copilot от Github (AI-помощник для разработчика) многие прозвали уже одним из самых инновационных проектов для повышения эффективности разработки в 2021 году. Чтобы ответить на вопрос "а насколько генерируемый код безопасен" было проведено исследование, в рамках которого создано 89 сценариев для Copilot и 1692 программ, 40% из которых оказались уязвимыми. Для формирования критерия качества кода использовался инструмент CodeQL.

Помимо проблем с уязвимостями, есть те, кто считают, что Copilot может привести за собой проблемы с авторским правом, так как инструмент обучен, в том числе, на исходных кодах с лицензией GPL.

#dev #sast

Company wide SAST

Ребята из Яндекса выложили последний недостающий доклад с ZN (+слайды), где они рассказали о том, как строили SAST. В первой части речь пойдет про разработанный внутри оркестратор SAST'а и правила для Semgrep. Во второй части будет затронута тема CodeQL: его плюсы/минусы, опыт проведения пилота и написания правил. Есть также ссылка на репозиторий с полезными запросами для улучшения taint-анализа.

#dev #sast

How to find client-side prototype pollution at scale

Загрязнение прототипа (prototype pollution) - уязвимость, вызванная особенностями JS, позволяющая реализовать XSS и даже RCE. Подробное описание уязвимости было приведено ребятами из Huawei. Сегодня мне хотелось бы поделиться статьей о том, как эту уязвимость искали - "A tale of making internet pollution free"- Exploiting Client-Side Prototype Pollution in the wild". Благодаря selenuim, собственному расширению для браузера и запросу codeql ресерчеры нашли 18 уязвимых библиотек и зарепортили около 80 багов.

Кстати в стандартном паке codeql также есть кое-какие правила для поиска prototype pollution в собственных исходниках.

#dev #sast

CodeQL for Log4j

“Пятница-пятницей, а Log4j JNDI инъекцию никто не отменял :) все про нее уже в курсе, но если нет, то почитать можно тут или тут, ну или по-русски тут. Для CodeQL соответственно сразу же подъехали экспериментальные запросы: https://github.com/github/codeql/pull/7354/files
Можно уже погонять на своём коде. Сами запросы используют csv-модели, то есть разделенные точкой с запятой однострочные описания неймспейса, типа, подтипа, имени класса и еще нескольких параметров для задания source'a, sink'a и summary. Это укорачивает спецификацию этих элементов, позволяет их писать быстрее, но читать это чуть непривычнее :)”

За текст спасибо @shad0wrunner

Из чата @codeql

#dev #ops #attack #sast

Code Review Hotspots with Semgrep

Автор сегодняшней статьи предлагает поделить сработки на две группы - security и hotspots. Сработки группы security имеют низкий уровень ложных срабатываний и предназначаются для разработчиков, в то время как сработки группы hotspots только свидетельствуют о подрзрении на уязвимость и попадают под ответственность security-инженеров. Вся статья дальше вращается вокруг хотспотов и способов их поиска через инструмент semgrep. К хотспотам относят hardoced secrets, небезопасную криптографию, мисконфиги, переполнения буфера и тд.

Интереснее не сами баги, которые здесь подсвечиваются, а подход в разделении ответственности. Какие правила считать достаточно надежными, чтобы их сработки асайнить сразу на разраба, а не на ИБ?

В теории можно обратиться к последнему отчету Veracode - State of Software Security v12. В отчете приводится разного рода интересная статистика в контексте сканеров класса SAST/DAST/SCA. В частности, здесь есть перечень CWE, которые лучше всего находятся для того или иного класса сканера (картинка приложена к посту выше). Любопытно, что Cryptographic Issues и Credentials Management относятся к категории уязвимостей, которые гораздо чаще находятся именно SAST'ами, в то время как в вышеупомянутой статье они относятся к хотспотам. Что же делать?

Здесь позволю себе высказать собственное мнение, как мы делим сработки на security и hotspots в Альфе. Для многих оно покажется очевидным. Чем больше уязвимость поддается паттернам, а не механизмам data flow, тем лучше она будет находиться через SAST и тем более уверены вы в ней будете. Сюда относятся hardocded credentials, небезопасный CORS, мисконфиги (в т.ч. Docker / Kubernetes) и другие уязвимости, которые можно допустить, указав в коде непрерывный набор строк кода. SQL-инъекции, XSS, SSRF и прочие уязвимости, подразумевающие прием данных от пользователя через request-объекты имеют свойства приобретать сложную логику развития, а значит и более высокую степень FP/FN. Нередко, влияние на правила нахождения таких уязвимостей в контексте data flow стоит вам от 3 непрерывных месяцев работы в codeql/checkmarx в соусе из перегоревших appsec'ов. В это же время паттерновые уязвимости довольно легко корректируются с помощью того же semgrep.

#dev #sast

Vulncov - A tool that correlates Semgrep scans with Python test code coverage

Небольшой тул-эксперимент недельной давности — VulnCov. Его цель — приоритизировать файндинги Semgrep, исключая уязвимости, найденные в "мертвом коде". Для этого тул берет файндинги из Semgrep и объединяет их с результатами работы юнит-тестов Pytest.

Чтобы лучше разобраться, проще всего рассмотреть демонстрационный пример, где есть несколько уязвимостей внутри недостижимого участка кода:
- Закомментированный роутер #@app.route
- Невыполнимое условие if 1 == 2

По результатам сканирования Semgrep, по очевидным причинам, выдаст все уязвимости, включая те, что находятся в недостижимом коде. В проекте также есть тесты, которые по итогам выполнения формируют файл coverage.json. Файл coverage из отчета юнит-тестов содержит информацию о том, какие строки кода были выполнены в процессе тестирования, а также предоставляет сводную статистику о покрытии кода тестами. Этот файл помогает разработчикам понять, какие части кода проверены тестами, а какие — нет, что создает идеальную базу для приоритизации результатов Semgrep. В результате VulnCov сравнивает два файла и выдает JSON с наиболее релевантными файндингами.

А еще проект имеет поддержку приватной LLM ollama (хотя где-то без подключения OpenAI) для генерации баг-фиксов.

В репозитории всего 21 ⭐️, но в домене корреляции результатов, даже в эпоху искусственного интеллекта, вряд ли стоит ожидать величайших прорывов. Сразу вспоминаются решения класса IAST и сопутствующие рассуждения о корреляции SAST и DAST из далекого 2020 года. Как мы можем видеть, гораздо быстрее и эффективнее развиваются практики reachability analysis и автоматического триажа с помощью AI.

#sast #ai