SheftLeft Scan - A Free & Open Source DevSecOps Platform

Проект предоставляет :
- SAST
- SCA
- Поиск секретов
- Проверка open-source лицензий

Из поддерживаемых языков: Salesforce Apex, Bash, Go, Java, JSP, Node.js, Oracle PL/SQL, Python, Rust (Dependency and Licence scan alone), Terraform, Salesforce Visual Force, Apache Velocity.

Есть интеграция с Visual Studio Code, а также со всеми популярными CI/CD.


https://www.shiftleft.io/scan/

#tools #sca #sast #secret #dev #ops

Salus (Security Automation as a Lightweight Universal Scanner)

Salus - инструмент для централизованного управления статическими сканерами и инструментами проверки зависимостей. В число интегрированного open-source ПО: Bandit, BundleAudit, Brakeman, npm audit, yarn audit, semgrep, PatternSearch, gosec. Таким образом, Salus позволяет проверять проекты, написанные на Ruby, Node, Python и Go.

Сам Salus поставляется в виде единого контейнера (а еще он имеет интеграцию с Circle CI и может запускаться как Github Action)

#tools #sast #sca #dev

OWASP - Component Analysis

Страница на OWASP, опубликованная пару месяцев назад и посвященная безопасности сторонних компонентов - Component Analysis. На странице можно прочитать про факторы риска использования стороних компонентов, рекомендации, C-SCRM, полезные пункты для добавления в политику безопасности, а также перечень инструментов, как open-source, так и commercial.

https://owasp.org/www-community/Component_Analysis

#tools #sca #dev

OWASP Software Component Verification Standard (SCVS)

SCVS - новый стандарт OWASP, направленый на определение и снижение рисков, связанных с цепочками поставок ПО. Риском, связанным с цепочкой поставок, является использование уязвимого open-source компонента в процессе разработки, нарушение целостности имеющихся пакетов в репозитории, нарушение лицензионных соглашений. Среди лучших практик SCVS - использование Software Composition Analysis, пакетных менеджеров, усиленных настроек к пайплайну сборки и другое.

#compliance #sca #dev

False Positive: Dependency Check, Dependency Track and Nexus IQ

Просканировал уязвимый java-проект dvja тремя инструментами SCA: open-source Dependency Check, Dependency Track и платным продуктом Nexus IQ. Для каждой выявленной CVE сделал ревью и вот что предварительно получилось - 65% фолзов для Dependency Check, 52% для Dependency Track и только 10 для Nexus IQ.

Казалось бы, откуда тут фолзы? Так как open source инструменты строят на базе выявленной компоненты CPE-строку, после чего лезут в NVD за CVE для этой компоненты, то могут возникать ошибки - несоответствие CVE к выявленной компоненте, несоответствие CVE к выявленной версии и дублирование CVE (отображение несколько CVE об одной и той же уязвимости). Nexus в данном случае выиграет за счет того, что Sonatype расширили каждую CVE, указав уязвимый класс, функцию и проведя дополнительные ресерчи.

Чуть попозже надеюсь, что оформим это все в статью, чтобы все могли познакомиться с ревью поглубже.

#sca #tools #dev

State of Open Source Security Report 2020

Кстати об SCA. Оказывается, у Snyk вышел ежгодный отчет State of Open Source
Security Report 2020. Много разных графиков, статистики и рекомендаций. Спасибо @mobile_appsec_world

#report #sca #dev

Anchore Toolbox

Помимо известного Anchore Engine, в арсенале open source Anchore недавно появились такие инструменты как syft и grype.

Grype - сканер уязвимостей для образов контейнеров, пакетов операционных систем (Alpne, BusyBox, CentOS, Debian, Ubuntu), а также таких пакетов как Ruby Bundler, JARs, NPM, Egg/Wheel, Pip.

Syft - CLI, которая умеет создавать спецификации зависимостей (SBOM) из тех же образов контейнеров, дистрибутивов Linux (Apline, BusyBox, CentOS, Debian, Ubuntu), а также пакетов вроде APK, DEB, NPM, Go.

И из future plans Grype научится принимать в качестве входных параметров как SBOM от Syft, так и CycloneDX (!). Кажется, что скоро надо будет делать сравнение SCA от OWASP и Anchore...

#tools #sca #dev

DevSecOps: принципы работы и сравнение SCA. Часть первая

Рад объявить о том, что мы запустили блог на Хабре и серию статей по DevSecOps на русском языке. Первая статья - "Принципы работы и сравнение SCA". В этой статье я рассказываю, что такое Software Composition Analysis, как он работает, при чем здесь BOM и что это такое, какие фолзы выдают SCA и как их выявлять, а также табличка с функциональным сравнением. Вся статья построена вокруг двух самых известных open source решений Dependency Check, Dependency Track и коммерческего решения Nexus IQ.

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

В следующих частях планируем написать о встраивании SCA в CI/CD, сравнении результатов различных DAST и многом другом.

#sca #tools #dev

Очень люблю подобные сравнения

#sca #docker #dev

State of Software Security

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

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

#sast #dast #sca #dev #report

Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies

Недавно вышла интересная статья про то, как исследователь получил возможность исполнять код на серверах компаний и внедрять бэкдоры в их приложения. Уязвимыми оказались такие гиганты, как Microsoft, Apple, PayPal и Tesla. Атака стала возможной благодаря особенности пакетных менеджеров, которые пытаются загрузить внутренние зависимости компаний, в том числе и из публичных репозиториев. Это касается и хранилищ артефактов, если в одном виртуальном репозитории смешаны внутренние и внешние пакеты.

Реализовать атаку довольно просто: находим имена приватных пакетов, создаем собственные версии с аналогичным названием, выкладываем в публичный репозиторий. Далее ждем, когда кто-то установит наш пакет вместо приватного пакета компании. На HackerOne есть репорт, который раскрывает всю подноготную атаки, включая "вредоносный" пакет для тестирования.

Защита от подобного рода атак описывается в новеньком документе Microsoft. Для Nexus и JFrog выпущены соответствующие рекомендации. Но какой-то серебряной пули, которая поможет здесь и сейчас, нет. Особенно в случае с npm, когда ваши разработчики не используют scope.

Кстати, ситуация с Dependency Confusion еще один звоночек в пользу создания своей баг-баунти программы. Ведь владельцы оных были уведомлены об уязвимости аж 7 месяцев назад.

Новость и разбор от @Khorcus

#dev #sca #attack #news

Launching OSV - Better vulnerability triage for open source

В вопросах, касающихся уязвимостей в сторонних компонентах (цепочке поставок), одна из главных проблем - полнота сведений в базе данных. В частности речь идет о NIST. Информации о CVE, CVSS и CPE чаще всего недостаточно, чтобы точно идентифицировать, какие компоненты подверглись уязвимости в цепочке поставок. Это же проблема является ключевой в вопросах корреляции SAST/SCA. Более того, мы не обладаем информацией о том, в каких версиях происходит исправления уязвимости. Чтобы решить данную проблему, крупные вендоры (например, Sonatype) ведут собственные фиды.

По этой причине команда Google на базе информации, полученной по итогам работы над OSS-Fuzz, запустила проект Open Source Vulnerabilities (OSV). Это сервис, который использует собственные фиды, чтобы предоставить расширенную информацию об уязвимостях в версии ПО. Про подход "Know, Prevent, Fix", взятый за основу, они также писали в отдельной статье.

Как работать с сервисом можно прочитать здесь, а на саму базу можно взглянуть по пути list.

Вот, например, OSV-2020-2291. Здесь содержится информация о том, что за уязвимость, какие компоненты также подвержены, ссылка на репо, коммит, в котором уязвимость была найдена и устранена. Здесь же есть данные о результатах тестирования с помощью OSS-Fuzz.

#dev #sca

Возвращаясь к теме Dependency Confusion, хочется упомянуть несколько простых скриптов, которые могут помочь в обнаружении проблемных артефактов: confused и repo-diff.

Первая утилита анализирует файл с определением зависимостей и проверяет, заняты ли имена приватных пакетов в публичных репозиториях. Работает для Python (pypi), JavaScript (npm) и PHP (composer). Подойдет для сканирования небольшого количества проектов.

Если репозиториев больше нескольких десятков, то гораздо проще взаимодействовать с хранилищем артефактов. Неплохим примером, иллюстрирующим работу с API Nexus, служит repo-diff. Он проверяет, нет ли в проксируемых репозиториях Nexus пакетов с такими же именами, что и в приватных. На его основе можно написать кастомный скрипт. Например, чтобы вытащить все приватные зависимости. Такую задачу можно решить также с помощью кастомных groovy скриптов.

P.S. В предыдущем посте никак не затрагивался PHP с его composer. Хотя про эту парочку есть хорошая статья. Исправляюсь.

От @Khorcus

#attack #sca #dev

Introducing sigstore: Easy Code Signing & Verification for Supply Chain Integrity

Сегодня у нас новый проект от Linux Foundation - Sigstore, основная цель которого предоставить возможность подписывать и проверять релизы. Из слов разработчиков, "Так же, как Let's Encrypt предоставляет бесплатные сертификаты и инструменты автоматизации для HTTPS, sigstore предоставляет бесплатные сертификаты и инструменты для автоматизации и проверки подписей исходного кода."

На текущий момент проект нацелен на артефакты вроде tar, бинарных файлов и образов контейнеров. Позже будут рассмотрены jar-файлы, манифесты (например, SBOM).

Важно отметить, что речь идет именно о проекте. Реализация зависит от конкретного инструмента. На текущий момент это Cosign от инженера Google (пример работы), Rekore и Fulcio.

Среди примеров угроз, от которых потенциально спасает инструмент - dependency confusion attack и импорт уязвимых пакетов RubyGems.

#sca

Still Dependency Confusion. Defending Against Software Supply Chain Attacks

На тему атаки Dependency Confusion продолжают выходить статьи и инструменты.

В частности ребята из Salesforce выпустили инструмент DazedAndConfused для проверки Cocoapods, composer, gems, gradle и не только.

Вышла даже статья по реализации атаки в Game Development на Unity (потому что NPM). На тему устранения уязвимости в NPM вот. Если вы используете Bundler для работы с зависимостями в Ruby, то для вас также есть статья.

На тему Supply Chain последнее время пишут достаточно часто. В частности CISA выпустила методичку "Defending Against Software Supply Chain Attacks" по защите от атак на цепочку поставок. В ней есть упоминание множества полезных практик NIST - NIST SP 800-161 (April 2015), NISTIR 8276 (February 2021), SSDF (April, 2020)

#dev #sca #attack

Introducing the Open Source Insights Project

Google продолжают радовать своими открытыми продуктами, посвященными безопасности open-source. На этот раз они выпустили Open Source Insights Project. С самим сервисом можно поиграть здесь. Он позволяет анализировать сторонние зависимости для указанного компонента с помощью интерактивного графа, а если открыть описание компонента, то можно увидеть историю релизов и перечень тестов от OpenSSF Scorecards (было ли сканирование SAST для компонента, fuzzing, давно ли были релизы и так далее)

Другие интересные проекты от Google:
- Cosign
- Open Source Vulnerabilities (OSV)

Обсуждать можно в нашем чате: @sec_devops_chat

#sca #dev

The Python Vulnerability Landscape

Сегодня у нас пост про Python. Начнем со статьи "The Python Vulnerability Landscape" о развитии уязвимостей в пакетах python'а. В статье приведены данные об изменение числа уязвимостей в пакетах (в т.ч. с разбивкой на CWE и популярные фреймворки вроде django) и степени их критичности. На картинке вы в частности можете видеть наиболее уязвимые пакеты по годам.

А теперь об инструментах. Они не такие популярные как тот же Safety, но безусловно заслуживают внимания.

trailofbits/pip-audit - инструмент для анализа уязвимостей пакетов python от небезызвестных Trail of Bits с базой advisory-db. Скармливаем requirments.txt и получаем результат (можно в json).

ochronasec/ochrona-cli - аналогичный инструмент, использующий базу данных с уязвимостями, которая бралась за основу для формирования статистики выше. В базе используются NIST NVD, Github Advisory Database, PyPA Advisory DB.

#dev #sca

What does your code use, and is it vulnerable? It depends!

Когда дело доходит до внедрения практики выявления уязвимостей в сторонних библиотеках, первое, что часто приходит на ум - внедрить инструмент класса SCA, получить уязвимые библиотеки и получить с разработчика обещание все исправить. При таком подходе мы сталкиваемся со встречными вопросами:
- откуда у вас уверенность, что в транзитивных зависимостях есть эксплуатируемые уязвимости,
- как определить версию директивной зависимости, чтобы обновить транзитивную
- можете ли вы полагаться на перечень зависимостей, который для вас определил SCA (например, в том же package.json может быть указано, что пакет lodash имеет версию "*")

На все эти вопросы ответить сразу на первых этапах внедрения практики не всегда удается успешно. Например, в случае, если мы имеем gradle, то build.gradle никак не даст ответов на вопросы выше, а результатом сборки в данном случае будет набор библиотек, лежащих в единой директории. Что из этого директивная зависимость,а что транзитивная по итогу анализа результатов SCA понять редко возможно. Приходится смотреть дерево зависимотей от самого gradle и сопоставлять с результатами SCA, из-за чего TTM сильно возрастает.

Часто компании принимают для себя решение просить исправлять только уязвимые директивные зависимости, а контроль устранения уязвимостей в транзитивных зависимостях отдавать на авторов директивных. Это решает часть проблем с объемом работы, но часть вопросов выше остаются актуальными.

В данном случае нам могут помочь несколько вещей. Один из простых и эффективных способов - получить lockfile! Это формат описания зависимостей с указанием явных хэш-сумм (а именно на хэш-суммы, как правило, смотрят все SCA, что сразу повышает точность сканирования). Что удобно, так это то, что lockfile можно получить нативным образом от всех популярных сборщиков (pipenv, npm, yarn, nuget, gradle, composer).

Второе решение - построить граф зависимостей и явно отсечь зависимости с глубиной выше 1. Здесь может помочь инструмент вроде It-Depends от Trail of Bits. Он построит вам перечень зависимостей с нужной глубиной и отдаст результат в формате SBOM, который можно скормить в SCA. Кроме того, он может выдать некоторые уязвимости на основе OSV vulnerability database, про которую я писал ранее.

#sca #dev

OWASP Dep-scan

В чате участники нашего сообщества поделились проектом Dep-scan — инструментом поиска уязвимостей в зависимостях "нового поколения" от OWASP. Несмотря на то что инструмент не новый, известен он не так сильно как Dependency-Check и Dependency-Track.

Отличительная особенность данного инструмента — это предоставление возможности по приоритизации уязвимостей. Dep-scan добавляет к каждой уязвимости графу "Insights". Приоритизация осуществляется за счет так называемого Reachability анализа — анализа кода на предмет того, может ли уязвимый пакет быть затронут опасными методами, например, пользовательским вводом с помощью параметров requests или методов safecode. Механизм построен на базе проекта Atom и поддерживает Java, JavaScript, TypeScript и Python.

В проект также добавили режим аудита риска. Этот режим позволяет оценить степень рискованности npm или PyPI-пакетов с помощью заложенной разбивки весов. Баллы риска могут прибавляться, например, если у пакета всего два npm-пользователя, приватный пакет доступен в публичном реестре (привет атаки dependency confusion), либо пакет в принципе достаточно старый.

Среди фич авторы отмечают генерацию SBOM за счет интеграции с cdxgen, быстроту сканирования и количество поддерживаемых языков и форматов (Node.js, Java, PHP, Python, Go, .NET, C/C++, Docker, OCI image, YAML).

А какие SCA используете вы? И есть ли положительный опыт работ с импортозамещенными инструментами? Обсуждаем в комментариях и чате.

#sca

Non-Actionable Findings в 3rd-party Security Scanners...и как их распознать

Инженер Google написал блог-пост о том, как обрабатывать результаты CVE от сканеров безопасности и как распознать те, которые можно спокойно убрать из списка задач на фиксы.

Краткий конспект от нашей команды:

Rejected уязвимости: Самый простой вариант — исключить уязвимости с пометкой rejected в NVD (например, CVE-2023-4881). Это имеет смысл, когда сканер тащит весь NVD без минимальной фильтрации. Такой случай не особо интересен, двигаемся дальше.

Переоценка от мейнтейнеров: Бывает, что NVD отмечает уязвимость как high, а мейнтейнеры ОС считают, что у неё минимальный импакт и не выпускают патчи для своих дистрибутивов Linux. В таких случаях мнение мейнтейнеров может быть более релевантным, и уязвимость можно классифицировать как false positive.
Пример — CVE-2018-20657:

10-byte memleak, not considered important to be fixed by upstream, so no patch is available as of 2023-06-02

Отсутствие импакта на используемую ОС: NVD может показывать широкий диапазон уязвимых версий пакета, но не учитывать влияние на конкретную версию ОС. Если сканер использует только данные NVD и игнорирует статусы not affected от ОС, то он может ложно сработать на уязвимость, которой на самом деле нет (пример CVE-2023-52426)

Кастомные патчи от ОС: Иногда сканеры не учитывают кастомные патчи, которые ОС выпускает для фиксов. Например, сканер видит версию Python 3.6.10 как уязвимую, но Ubuntu выпустила патч с версией 3.6.9-1~18.04ubuntu1.1. Внешние сканеры, использующие NVD вместо базы уязвимостей от Ubuntu, могут ложно считать патченную версию Python уязвимой.

Неполная информация об уязвимости пакета: Некоторые фиды, как Debian, репортят уязвимости только для исходных пакетов. Сканеры часто ошибаются, считая уязвимыми все связанные бинарные пакеты, даже если они не содержат уязвимых библиотек. Например для уязвимости CVE-2024-6387 затрагивается только OpenSSH-серверы, но Debian отмечает уязвимым исходный пакет "openssh". В итоге даже системы с установленным только "openssh-client" будут ошибочно помечены как уязвимые, хотя уязвимых библиотек там нет.

Нерелевантные к безопасности срабатывания: Некоторые сканеры репортят пакеты, не связанные с безопасностью. Например, Trivy репортит файндинги из Debian LTS (DLA) о таких вещах, как обновления часовых поясов или новые GPG-ключи, которые не влияют на безопасность. Отсутствие этих обновлений не создает рисков для безопасности.

А какие классификации используете вы? Может быть расширим и углубим список "гугла"?

#sca #supplychain