"Developers are taking over AppSec" by WhiteSource

Компания WhiteSource представила статистику по безопасности приложений на базе опроса около 600 разработчиков

Статистика охватывает следующие вопросы:
- Кто несет ответственность за безопасность приложения
- Как расставляются приоритеты относительно безопасности приложений в компаниях
- На каком этапе SDLC разработчики начинают тестировать безопасность приложения
- Про обучение безопасности разработчиков
- На что ориентируются команды при выборе бесплатных инструментов AppSec
- Какие бесплатные инструменты для AppSec используются

За ссылку спасибо @oleg_log

#report

https://www.whitesourcesoftware.com/developers-security-report/

#dev #sca

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