Кто сказал что здесь не может быть ничего альтерантивного?
С момента своего запуска Хабр эволюционировал из ресурса для обмена знаниями из мира информационных технологий (назовём это computer science) в гораздо менее специализированный сайт, который часто используется как генератор трафика или рекламная площадка. Ещё и добавили неотключаемые новостные блоки, чтобы ещё больше получить внимания. Проблема даже не в этой эволюции, а в том что альтернативы текущему Хабру, но с прежними принципами, так и не появилось (?) за это время. К тому же, всё-таки и сейчас бывают годные статьи тут.
Все эти млрд строк кода и десятки тысяч репозиториев (с кучей веток) выглядят как маркетинговые цифры и/или цифры, которые вы сами себе сгенерировали (как в случае со срабатываниями анализиторов). При этом сама AppSec платформа выглядит впечатляюще. Спасибо за интересную статью!
Хотелось бы побольше узнать о базовом процессе со стороны разработчика и безопасника: как буквально разработчик с этим взаимодействует и насколько это ухудшает (или улучшает) его жизнь? Security Gate скорее всего предполагает блокирование релиза на основе наличия High+ уязвимостей? То же самое и в контексте безопасника, особенно с учётом таких объёмов для триаджа.
Сорри за немного провакационный вопрос, но рассматривали ли возможность вообще не аггрегировать и не хранить результаты работы анализаторов, а показывать их только в контексте PR-ов?
На счет существующих решений - есть большое количество решений для git репозиториев, но именно для таск трекера находил несколько
Но ведь вам по факту уже не так важна интеграция с Джирой, сколько просто анализ текста на наличие секретов. Вы же всё равно сами забираете текст нужных тикетов и потом отдаете в ваш анализатор. Поэтому и подумалось, что вам мог бы подойти и какой-то из существующих анализаторов, который умеет в stdin принимать текст или же просто текстовые файлики анализировать.
Но тут есть сложности - это настраивается на каждом workflow а у нас их довольно много. Так же эта проверка не отработает, при написании комментария, либо после редактирования.
Интересный проект получился! Хотя и не покидает ощущение, что вам было даже более интересно в ML погрузиться, чем решить конкретно задачу мониторинга утечки "секретов" :)
В первую очередь мы начали искать готовое решение. Но оказалось, что готовых opensource-плагинов для Jira на этот случай нет. Поэтому мы решили написать свой с использованием Machine Learning и сделать его более универсальным, для подключения к различным источникам: Jira, Confluence, общие диски.
Если я правильно понял, то вы "по крону" дёргаете джировское API и запрашиваете список подходящих тикетов для проверки (новые или недавно отредактированные). Дальше анализируете их текст на предмет утечки секретов с последующим созданием алерта. Пробовали ли использовать для этого анализа существующие opensource-решения (trufflehog или аналоги)? Исследовали ли возможности Джиры и Конфлюенса на предмет предотвращения постинга туда секретов, может там есть аналог git хуков?
Интересная статья, спасибо, что поделились опытом!
Второй момент — необходимость избегать уязвимости Dependency Confusion, и для этого мы используем параметр default = true (pyproject.toml), который запрещает использовать в сборке неглобальные PYPI. То есть мы запрещаем доступ напрямую и создаем свой дефолтный приватный репозиторий с нашими библиотеками. Благодаря чему код злоумышленника не может проникнуть в инфраструктуру, выполниться и натворить бед с безграничными возможностями.
Не совсем понятно, что понимается под "неглобальными PyPI", но этот параметр устанавливает указанный источник как дефолтный при поиске пакетов вместо PyPI. Чтобы этот параметр помогал с Dependency Confusion атаками, у вас должен быть указан только этот источник (в котором мы можете, например, проксировать PyPI с фильтром на приватные пакеты по префиксу). Либо уж использовать "Package source constraints" и явное указание источника для каждого пакета.
При этом у вас схема с 2 источниками пакетов и второй источник для пакетов, кажется, как раз прокси на PyPI:
[[tool.poetry.source]]
name = "acme-pypi"
url = "https://registry.acme.com/repository/pypi-acme-pay/simple/"
default = true
[[tool.poetry.source]]
name = "acme-pypi-proxy"
url = "https://registry.acme.com/repository/pypi-proxy/simple/"
Не получится ли так, что при резолвинге версий для приватного пакета, Poetry будет учитываться и наличие более высокой версии фейкового пакета с таким именем, но опубликованном в PyPI (который вы проксируете в acme-pypi-proxy)?
В мире багбаунти-программ важную роль играет доверие между всеми участниками процесса. То, что сделал H1, являясь по сути мировым локомотивом этого движения, никак этому принципу не соответствует.
Не лишним будет напомнить, если вы хотите иметь прямую связь с багхантером - разместите в корень сайта файл /security.txt с информацией о связи с командой, как это сделано на mos.ru или gosuslugi.ru.
Почитайте, пожалуйста, про Mozilla и её историю. Даже сейчас после всего того, что они выпилили из браузера за последние годы, и при такой зависимости доходов от Гугла, это всё-таки отдельный игрок на рынке браузеров со своим движком рендренинга. Всего таких сейчас в мире осталось по сути 3 полноценных базовых браузера:
Mozilla Firefox
Google Chrome
Apple Safari
Последние два буквально связаны с мегакорпорациями. Ещё относительно недавно была Опера, которая при своих размерах, также играла важную роль.
Это не было сарказмом. Firefox — по сути последний сколько-нибудь видный независимый игрок на рынке браузеров. Да и сама Mozilla много значит для Интернета.
Это какая-то жесть. Такая уважаемая и ценная для Интернета компания как Mozilla меняет пользовательские настройки в уже установленных браузерах Firefox, не снабдив это нормальным объяснением и не ссылаясь на какие-то открытые отчёты/факты действий Яндекса.
А как по-вашему должна была поступить Mozilla, чтобы не огрести за сотрудничество с компаниями, попавшими под санкции, и лишёнными возможности оплачивать своё нахождение в составе дистрибутива?
Не удалять поисковик, если он явным образом выбран и/или использовался пользователем. Сейчас выглядит как то, что Mozilla изменила настройки установленного (из репозитория дистрибутива) и настроенного мной Firefox.
Плохой ход со стороны Мозиллы. По факту на используемых браузерах у пользователях взяли и выключили тот поисковик, который они предпочитали. В контексте GNU/Linux выглядит так, что вы ставите собранное из исходных кодов приложение, функциональность которого вдруг для вас поменялась по решению извне.
Чтобы установить Яндекс поиском достаточно в поле поиска (его надо добавить в тулбар, если не использовали ранее) при посещении https://yandex.ru нажать на плюсик напротив соответствующей иконки. Благо дело, что пока не выпилили OpenSearch (https://developer.mozilla.org/en-US/docs/Web/OpenSearch)
Они вполне могут храниться в зашифрованном виде (и хранятся), но ключ используется серверный.
В контексте шифрования переписки (и требования сохранения её тайны) это не важно. В данном случае важно то, что вся переписка, за исключением секретных чатов, появляется на новом устройстве, с которого просто выполнена аутентификация по коду из СМС. Владельцем такого устройства можеть быть вовсе не участник соответствующей переписки, а администраторы серверов мессенжера могут прочитать эту переписку и до передачи на устройство. Пока нет e2e-шифрования, у них будет такая возможность.
С момента своего запуска Хабр эволюционировал из ресурса для обмена знаниями из мира информационных технологий (назовём это computer science) в гораздо менее специализированный сайт, который часто используется как генератор трафика или рекламная площадка. Ещё и добавили неотключаемые новостные блоки, чтобы ещё больше получить внимания. Проблема даже не в этой эволюции, а в том что альтернативы текущему Хабру, но с прежними принципами, так и не появилось (?) за это время. К тому же, всё-таки и сейчас бывают годные статьи тут.
Эта статья, к сожалению, вообще отвечает почти всем тенденциям последнего времени на Хабре:
кликбейтный заголовок
не относится к IT вообще
репост с другого ресурса, например VC
в посте куча картинок, часто и для кода
обязательно попытка в юмор и мемы, что само по себе и не так уж и плохо, но вопрос в уровне
в конце обязательно должне быть призыв подписываться на блог в Телеграме
Все эти млрд строк кода и десятки тысяч репозиториев (с кучей веток) выглядят как маркетинговые цифры и/или цифры, которые вы сами себе сгенерировали (как в случае со срабатываниями анализиторов). При этом сама AppSec платформа выглядит впечатляюще. Спасибо за интересную статью!
Хотелось бы побольше узнать о базовом процессе со стороны разработчика и безопасника: как буквально разработчик с этим взаимодействует и насколько это ухудшает (или улучшает) его жизнь? Security Gate скорее всего предполагает блокирование релиза на основе наличия High+ уязвимостей? То же самое и в контексте безопасника, особенно с учётом таких объёмов для триаджа.
Сорри за немного провакационный вопрос, но рассматривали ли возможность вообще не аггрегировать и не хранить результаты работы анализаторов, а показывать их только в контексте PR-ов?
Но ведь вам по факту уже не так важна интеграция с Джирой, сколько просто анализ текста на наличие секретов. Вы же всё равно сами забираете текст нужных тикетов и потом отдаете в ваш анализатор. Поэтому и подумалось, что вам мог бы подойти и какой-то из существующих анализаторов, который умеет в stdin принимать текст или же просто текстовые файлики анализировать.
Жаль. Выходит, что только мониторинг :(
Интересный проект получился! Хотя и не покидает ощущение, что вам было даже более интересно в ML погрузиться, чем решить конкретно задачу мониторинга утечки "секретов" :)
Если я правильно понял, то вы "по крону" дёргаете джировское API и запрашиваете список подходящих тикетов для проверки (новые или недавно отредактированные). Дальше анализируете их текст на предмет утечки секретов с последующим созданием алерта. Пробовали ли использовать для этого анализа существующие opensource-решения (trufflehog или аналоги)? Исследовали ли возможности Джиры и Конфлюенса на предмет предотвращения постинга туда секретов, может там есть аналог git хуков?
+1, но статья получилась всё равно замечательная. Большой респект автору!
Ещё можно было бы упомянуть про:
рынок аутсорса, который вырос в Академгородке 00-х
ни только про Level, но и про небезызвестную НЭТУ на базе НГТУ/НЭТИ
развитие локальных сетей и провайдеров
знаковые веб-студии
Интересная статья, спасибо, что поделились опытом!
Не совсем понятно, что понимается под "неглобальными PyPI", но этот параметр устанавливает указанный источник как дефолтный при поиске пакетов вместо PyPI. Чтобы этот параметр помогал с Dependency Confusion атаками, у вас должен быть указан только этот источник (в котором мы можете, например, проксировать PyPI с фильтром на приватные пакеты по префиксу). Либо уж использовать "Package source constraints" и явное указание источника для каждого пакета.
При этом у вас схема с 2 источниками пакетов и второй источник для пакетов, кажется, как раз прокси на PyPI:
Не получится ли так, что при резолвинге версий для приватного пакета, Poetry будет учитываться и наличие более высокой версии фейкового пакета с таким именем, но опубликованном в PyPI (который вы проксируете в
acme-pypi-proxy)?Здорово, что опубликовали видео, но хорошо бы ещё и слайды!
Выглядит как обязательный к посещению! :) Большой респект всем тем, кто стоял за созданием этого музея.
Спасибо!
Сейчас активно исследуем варианты на российском рынке. При этом как альтернативный (вне багбаунти) канал доступен и адрес security-report@ozon.ru.
В мире багбаунти-программ важную роль играет доверие между всеми участниками процесса. То, что сделал H1, являясь по сути мировым локомотивом этого движения, никак этому принципу не соответствует.
Вот тут про формат security.txt чуть подробнее https://habr.com/ru/post/456910
Почитайте, пожалуйста, про Mozilla и её историю. Даже сейчас после всего того, что они выпилили из браузера за последние годы, и при такой зависимости доходов от Гугла, это всё-таки отдельный игрок на рынке браузеров со своим движком рендренинга. Всего таких сейчас в мире осталось по сути 3 полноценных базовых браузера:
Mozilla Firefox
Google Chrome
Apple Safari
Последние два буквально связаны с мегакорпорациями. Ещё относительно недавно была Опера, которая при своих размерах, также играла важную роль.
Это не было сарказмом. Firefox — по сути последний сколько-нибудь видный независимый игрок на рынке браузеров. Да и сама Mozilla много значит для Интернета.
Это какая-то жесть. Такая уважаемая и ценная для Интернета компания как Mozilla меняет пользовательские настройки в уже установленных браузерах Firefox, не снабдив это нормальным объяснением и не ссылаясь на какие-то открытые отчёты/факты действий Яндекса.
Мне не удалось найти у них даже тикета на это в Багзилле и пришлось завести новый https://bugzilla.mozilla.org/show_bug.cgi?id=1759570
Не удалять поисковик, если он явным образом выбран и/или использовался пользователем. Сейчас выглядит как то, что Mozilla изменила настройки установленного (из репозитория дистрибутива) и настроенного мной Firefox.
Завёл багрепорт https://bugzilla.mozilla.org/show_bug.cgi?id=1759570
Плохой ход со стороны Мозиллы. По факту на используемых браузерах у пользователях взяли и выключили тот поисковик, который они предпочитали. В контексте GNU/Linux выглядит так, что вы ставите собранное из исходных кодов приложение, функциональность которого вдруг для вас поменялась по решению извне.
Чтобы установить Яндекс поиском достаточно в поле поиска (его надо добавить в тулбар, если не использовали ранее) при посещении https://yandex.ru нажать на плюсик напротив соответствующей иконки. Благо дело, что пока не выпилили OpenSearch (https://developer.mozilla.org/en-US/docs/Web/OpenSearch)
Какое отношение эта статья имеет к Хабру, причём написанная в таком стиле?
В контексте шифрования переписки (и требования сохранения её тайны) это не важно. В данном случае важно то, что вся переписка, за исключением секретных чатов, появляется на новом устройстве, с которого просто выполнена аутентификация по коду из СМС. Владельцем такого устройства можеть быть вовсе не участник соответствующей переписки, а администраторы серверов мессенжера могут прочитать эту переписку и до передачи на устройство. Пока нет e2e-шифрования, у них будет такая возможность.
https://support.signal.org/hc/ru/articles/360007059752
Самое интересное в том, в каком виде вотсап это делает.