Pull to refresh
10
0

Пользователь

Send message

На счет существующих решений - есть большое количество решений для git репозиториев, но именно для таск трекера находил несколько

Но ведь вам по факту уже не так важна интеграция с Джирой, сколько просто анализ текста на наличие секретов. Вы же всё равно сами забираете текст нужных тикетов и потом отдаете в ваш анализатор. Поэтому и подумалось, что вам мог бы подойти и какой-то из существующих анализаторов, который умеет в stdin принимать текст или же просто текстовые файлики анализировать.

Но тут есть сложности - это настраивается на каждом workflow а у нас их довольно много. Так же эта проверка не отработает, при написании комментария, либо после редактирования.

Жаль. Выходит, что только мониторинг :(

Интересный проект получился! Хотя и не покидает ощущение, что вам было даже более интересно в ML погрузиться, чем решить конкретно задачу мониторинга утечки "секретов" :)

В первую очередь мы начали искать готовое решение. Но оказалось, что готовых opensource-плагинов для Jira на этот случай нет. Поэтому мы решили написать свой с использованием Machine Learning и сделать его более универсальным, для подключения к различным источникам: Jira, Confluence, общие диски.

Если я правильно понял, то вы "по крону" дёргаете джировское API и запрашиваете список подходящих тикетов для проверки (новые или недавно отредактированные). Дальше анализируете их текст на предмет утечки секретов с последующим созданием алерта. Пробовали ли использовать для этого анализа существующие opensource-решения (trufflehog или аналоги)? Исследовали ли возможности Джиры и Конфлюенса на предмет предотвращения постинга туда секретов, может там есть аналог git хуков?

+1, но статья получилась всё равно замечательная. Большой респект автору!

Ещё можно было бы упомянуть про:

  • рынок аутсорса, который вырос в Академгородке 00-х

  • ни только про Level, но и про небезызвестную НЭТУ на базе НГТУ/НЭТИ

  • развитие локальных сетей и провайдеров

  • знаковые веб-студии

Интересная статья, спасибо, что поделились опытом!

Второй момент — необходимость избегать уязвимости 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)?

Здорово, что опубликовали видео, но хорошо бы ещё и слайды!

Выглядит как обязательный к посещению! :) Большой респект всем тем, кто стоял за созданием этого музея.

Спасибо!

Где теперь вы принимаете баги после закрытия HackerOne?

Сейчас активно исследуем варианты на российском рынке. При этом как альтернативный (вне багбаунти) канал доступен и адрес security-report@ozon.ru.

В мире багбаунти-программ важную роль играет доверие между всеми участниками процесса. То, что сделал H1, являясь по сути мировым локомотивом этого движения, никак этому принципу не соответствует.

Не лишним будет напомнить, если вы хотите иметь прямую связь с багхантером - разместите в корень сайта файл /security.txt с информацией о связи с командой, как это сделано на mos.ru или gosuslugi.ru.

Вот тут про формат 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, чтобы не огрести за
сотрудничество с компаниями, попавшими под санкции, и лишёнными
возможности оплачивать своё нахождение в составе дистрибутива?

Не удалять поисковик, если он явным образом выбран и/или использовался пользователем. Сейчас выглядит как то, что Mozilla изменила настройки установленного (из репозитория дистрибутива) и настроенного мной Firefox.

  1. Плохой ход со стороны Мозиллы. По факту на используемых браузерах у пользователях взяли и выключили тот поисковик, который они предпочитали. В контексте GNU/Linux выглядит так, что вы ставите собранное из исходных кодов приложение, функциональность которого вдруг для вас поменялась по решению извне.

  2. Чтобы установить Яндекс поиском достаточно в поле поиска (его надо добавить в тулбар, если не использовали ранее) при посещении https://yandex.ru нажать на плюсик напротив соответствующей иконки. Благо дело, что пока не выпилили OpenSearch (https://developer.mozilla.org/en-US/docs/Web/OpenSearch)

Какое отношение эта статья имеет к Хабру, причём написанная в таком стиле?

Они вполне могут храниться в зашифрованном виде (и хранятся), но ключ используется серверный.

В контексте шифрования переписки (и требования сохранения её тайны) это не важно. В данном случае важно то, что вся переписка, за исключением секретных чатов, появляется на новом устройстве, с которого просто выполнена аутентификация по коду из СМС. Владельцем такого устройства можеть быть вовсе не участник соответствующей переписки, а администраторы серверов мессенжера могут прочитать эту переписку и до передачи на устройство. Пока нет e2e-шифрования, у них будет такая возможность.

А у сигнала есть синхронизация переписки между двумя устройствами одного
аккаунта? Если да, то где хранятся сообщения и через что они
передаются?

https://support.signal.org/hc/ru/articles/360007059752

С сигналом не знаком, но вотсап вполне себе гоняет всю переписку через свой сервер когда синхронизирует веб-версию с приложением

Самое интересное в том, в каком виде вотсап это делает.

Есть WhatsApp, в нём e2e шифрование по умолчанию для всех пользователей. Только вот обычный российский следователь пишет в Фейсбук запрос на
выдачу переписки 2 пользователей, и без вопросов её получает (это кстати
удобно, благодаря этому вы можете в суде подтвердить переписку).

На каких фактах основаны ваши заявления о том, что Фейсбук выдает переписку (содержание сообщений) пользователей WhatsApp?

Это и так было на поверхности, но здорово, что и сам Мокси Марлинспайк ещё раз это обозначил. Ни один мессенджер не может позиционироваться как безопасный, пока безопасность (в данном случае e2e-шифрование) там не сделана по умолчанию для всех пользователей. Он может быть удобным, красивым, быстрым, но называться безопасным он может только при e2ee по умолчанию для всех коммуникаций.

Странно, что ничего не сказано про лицензию будущего проекта.

Information

Rating
Does not participate
Registered
Activity