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