Что сейчас происходит в сфере антифрода
К 2026 году мошенники тоже освоили генеративный ИИ. Вместо физических подделок они синтезируют изображения на основе утекших данных пользователей, заваливая банки тысячами фальшивых документов разного качества, авось прокатит. И в ряде случаев действительно прокатывает, потому что системы защиты тоже несовершенны.
Рынок пытается справиться с этими бедами: у нас на сайте вышел емкий разбор современных трендов антифрода. В статье разбирают, как эволюционировали подделки документов, из-за чего тормозится разработка средств защиты, а также какие модели считаются одними из самых прогрессивных.
Если хотите чек-лист антифрода 2026, вам сюда: https://tprg.ru/NCku
К 2026 году мошенники тоже освоили генеративный ИИ. Вместо физических подделок они синтезируют изображения на основе утекших данных пользователей, заваливая банки тысячами фальшивых документов разного качества, авось прокатит. И в ряде случаев действительно прокатывает, потому что системы защиты тоже несовершенны.
Рынок пытается справиться с этими бедами: у нас на сайте вышел емкий разбор современных трендов антифрода. В статье разбирают, как эволюционировали подделки документов, из-за чего тормозится разработка средств защиты, а также какие модели считаются одними из самых прогрессивных.
Если хотите чек-лист антифрода 2026, вам сюда: https://tprg.ru/NCku
Как ML помогает тестировать то, что нельзя предсказать вручную?
В новом материале — кейс о том, как спроектировать систему динамической генерации тестовых сценариев для транспортного проекта. За основу взято имитационное моделирование с элементами ML.
В статье подробное описание архитектуры решения:
— пайплайн из Great Expectations, Evidently AI, DVC и Airflow;
— три слоя данных: продовые срезы, обезличенные профили и «мутации» аномалий от ML;
— а еще швейцарский сыр.
Как он там оказался, читайте в статье.
В новом материале — кейс о том, как спроектировать систему динамической генерации тестовых сценариев для транспортного проекта. За основу взято имитационное моделирование с элементами ML.
В статье подробное описание архитектуры решения:
— пайплайн из Great Expectations, Evidently AI, DVC и Airflow;
— три слоя данных: продовые срезы, обезличенные профили и «мутации» аномалий от ML;
— а еще швейцарский сыр.
Как он там оказался, читайте в статье.
Реддитор проанализировал 1.6 миллиона Git-событий и показал, как бесконтрольное использование ИИ в разработке ломает привычные процессы и замедляет поставку продукта.
Основные выводы:
— ИИ увеличивает общий объем написанного кода примерно на 55%.
— Без расширения штата QA чистая скорость доставки падает до 0,85 от изначальной, то есть команда работает медленнее, чем до внедрения ИИ.
— Добавление всего одного выделенного тестировщика возвращает скорость к отметке 1,32 с окупаемостью 18 к 1.
— Юнит-тесты показали самую низкую эффективность, так как ИИ часто просто переписывает их под свои же баги.
Математическая модель автора показывает, что качество любого этапа проверки падает экспоненциально при росте объема кода. Когда на ревьюера сваливается постоянный поток пулл-реквестов, вдумчивая проверка быстро сменяется автоматическим одобрением, что в комментариях метко назвали ✨вероятностным продакшеном✨.
Проблема сильно усугубляется отложенным эффектом. На первых этапах менеджмент видит только рост числа слитых веток и считает внедрение успешным, пока баги незаметно накапливаются в системе. Со временем исправление ошибок начинает отнимать абсолютно все ресурсы разработчиков, и проект сталкивается с серьезными сбоями под нагрузкой.
Один из комментаторов поделился рабочим решением:
— Сделать CI-пайплайн первым и главным ревьюером.
— Внедрить property-based тесты и мутационное тестирование на критичных участках.
— Добавить строгий статический анализ, который автоматически отклоняет пулл-реквесты со слишком большим охватом изменений.
Такой подход отсеивает большую часть проблемного ИИ-кода до того, как он попадет к живому человеку. В результате объем ручной проверки снижается примерно на 60%, что позволяет ревьюерам сохранить фокус на сложной бизнес-логике и спасает от выгорания.
Ссылка на обсуждение: https://www.reddit.com/r/devops/comments/1rrrj0v/i_analyzed_16m_git_events_to_measure_what_happens/
Само исследование с воспроизводимыми скриптами: https://zenodo.org/records/18971198
Основные выводы:
— ИИ увеличивает общий объем написанного кода примерно на 55%.
— Без расширения штата QA чистая скорость доставки падает до 0,85 от изначальной, то есть команда работает медленнее, чем до внедрения ИИ.
— Добавление всего одного выделенного тестировщика возвращает скорость к отметке 1,32 с окупаемостью 18 к 1.
— Юнит-тесты показали самую низкую эффективность, так как ИИ часто просто переписывает их под свои же баги.
Математическая модель автора показывает, что качество любого этапа проверки падает экспоненциально при росте объема кода. Когда на ревьюера сваливается постоянный поток пулл-реквестов, вдумчивая проверка быстро сменяется автоматическим одобрением, что в комментариях метко назвали ✨вероятностным продакшеном✨.
Проблема сильно усугубляется отложенным эффектом. На первых этапах менеджмент видит только рост числа слитых веток и считает внедрение успешным, пока баги незаметно накапливаются в системе. Со временем исправление ошибок начинает отнимать абсолютно все ресурсы разработчиков, и проект сталкивается с серьезными сбоями под нагрузкой.
Один из комментаторов поделился рабочим решением:
— Сделать CI-пайплайн первым и главным ревьюером.
— Внедрить property-based тесты и мутационное тестирование на критичных участках.
— Добавить строгий статический анализ, который автоматически отклоняет пулл-реквесты со слишком большим охватом изменений.
Такой подход отсеивает большую часть проблемного ИИ-кода до того, как он попадет к живому человеку. В результате объем ручной проверки снижается примерно на 60%, что позволяет ревьюерам сохранить фокус на сложной бизнес-логике и спасает от выгорания.
Ссылка на обсуждение: https://www.reddit.com/r/devops/comments/1rrrj0v/i_analyzed_16m_git_events_to_measure_what_happens/
Само исследование с воспроизводимыми скриптами: https://zenodo.org/records/18971198
❤1👍1🔥1
Оказывается, людей всё ещё просят инвертировать бинарные деревья на доске при найме на позиции DevOps или Platform Engineer. Видимо, мы в 2026 должны уметь поисковики с нуля писать. Хотя куда показательнее попросить написать скрипт для парсинга логов или сортировки тысяч файлов в S3 по бакетам.
Уважаемые HR и нанимающие менеджеры, если хочется проверить экспертизу, обсуждайте архитектуру и траблшутинг:
— Базовые принципы CAMS
— Метрики DORA вроде Deployment Frequency и Change Failure Rate
— Понимание подкапотной магии Ansible, Jenkins и Helm
— Практичные паттерны: GitOps, Policy-as-code, стратегии релизов
И вообще, в моём мире адекватное техническое интервью больше похоже на совместный разбор инцидента, а не на экзамен по академическому Computer Science.
Уважаемые HR и нанимающие менеджеры, если хочется проверить экспертизу, обсуждайте архитектуру и траблшутинг:
— Базовые принципы CAMS
— Метрики DORA вроде Deployment Frequency и Change Failure Rate
— Понимание подкапотной магии Ansible, Jenkins и Helm
— Практичные паттерны: GitOps, Policy-as-code, стратегии релизов
И вообще, в моём мире адекватное техническое интервью больше похоже на совместный разбор инцидента, а не на экзамен по академическому Computer Science.
💯4🤔1
22 апреля в Москве пройдет конференция по искусственному интеллекту «MLечный путь»
Это мероприятие от облачного провайдера Selectel для тех, кто не просто следит за хайпом вокруг ИИ, а внедряет модели в продакшн или управляет этим процессом. Программа разделена на два трека: для бизнеса и для технических специалистов.
В техническом блоке доклады про:
— Выбор серверного железа под разные типы ИИ-нагрузок.
— Особенности SDLC для вероятностных систем.
— Безопасность при использовании генеративных технологий в рабочих процессах.
— Как сочетать инференс классических моделей и LLM на одной платформе.
В бизнес-треке — темы про окупаемость, риски и дорожные карты внедрения.
Участие бесплатное, но количество мест ограничено.Подробная программа и регистрация — на сайте мероприятия.
Это #партнёрский пост
Это мероприятие от облачного провайдера Selectel для тех, кто не просто следит за хайпом вокруг ИИ, а внедряет модели в продакшн или управляет этим процессом. Программа разделена на два трека: для бизнеса и для технических специалистов.
В техническом блоке доклады про:
— Выбор серверного железа под разные типы ИИ-нагрузок.
— Особенности SDLC для вероятностных систем.
— Безопасность при использовании генеративных технологий в рабочих процессах.
— Как сочетать инференс классических моделей и LLM на одной платформе.
В бизнес-треке — темы про окупаемость, риски и дорожные карты внедрения.
Участие бесплатное, но количество мест ограничено.Подробная программа и регистрация — на сайте мероприятия.
Это #партнёрский пост
🔥2
Тут снова всплыла та самая статья про исход из облаков от создателя Ruby on Rails. Если не читали, основная мысль сводится к тому, что для компаний среднего размера со стабильным ростом аренда чужих серверов обходится неоправданно дорого.
По логике Дэвида облако незаменимо только в двух случаях:
— либо ты делаешь стартап с нулевой базой и тебе критически важна скорость запуска без возни с инфраструктурой;
— либо у тебя случаются дикие непредсказуемые скачки нагрузки, как у них было на старте HEY с наплывом сотен тысяч пользователей.
В остальных ситуациях компания просто оплачивает маржинальность провайдера в районе тридцати процентов, покупая «страховку от землетрясения» в регионе, где их никогда не бывает, и продолжает поддерживать штат своих инженеров.
Дак вот, статья продолжает всплывать на протяжении 3+ лет, потому что проблемы-то никуда не делись. Конечно, никто не хоронит облака окончательно, но как будто бы иллюзия того, что передача инфраструктуры на аутсорс решит все технические проблемы, развеивается для всё большего количества людей.
По логике Дэвида облако незаменимо только в двух случаях:
— либо ты делаешь стартап с нулевой базой и тебе критически важна скорость запуска без возни с инфраструктурой;
— либо у тебя случаются дикие непредсказуемые скачки нагрузки, как у них было на старте HEY с наплывом сотен тысяч пользователей.
В остальных ситуациях компания просто оплачивает маржинальность провайдера в районе тридцати процентов, покупая «страховку от землетрясения» в регионе, где их никогда не бывает, и продолжает поддерживать штат своих инженеров.
Дак вот, статья продолжает всплывать на протяжении 3+ лет, потому что проблемы-то никуда не делись. Конечно, никто не хоронит облака окончательно, но как будто бы иллюзия того, что передача инфраструктуры на аутсорс решит все технические проблемы, развеивается для всё большего количества людей.
Hey
Why we're leaving the cloud
Basecamp has had one foot in the cloud for well over a decade, and HEY has been running there exclusively since it was launched two years ago. We've run extensively in both Amazon's cloud and Google's cloud. We've run on bare virtual machines, we've run on…
❤2🆒1
Линуксоид с гигантским стажем решил волевым усилием поломать свои привычки и заменить coreutils на фэнси тулзы. В комментарии набежали холиварить про надёжность vs эргономичность, но сначала вот пять замен, которые коллективно сочли достойными:
Дальше на ночь пятничная сказка про холивар.
Базовый набор GNU coreutils создавался в эпоху, когда деревья в файловых системах были маленькими,а ресурсов не хватало ни на что лишнее. Синтаксис классического find до сих пор вызывает нервный тик, а чтение логов через cat без подсветки пора признать формой легкого мазохизма. Современный подход предлагает инструменты, которые написаны преимущественно на Rust и делают ровно то же самое, но с человеческим лицом. А ещё они работают быстрее и прямо из коробки понимают правила .gitignore.
В подобных обсуждениях всегда появляется Суровый Системный Администратор Старой Школы и настаивает, что все эти цветастые игрушки абсолютно бесполезны при заходе по SSH на боевой сервер. Там тебя встретит голый bash и девственно чистый vi. В ответ на это в него кидаются терраформами и ансиблами и спрашивают, а зачем мол вообще в наше время ходить на продакшен по ssh?
cat → bat ибо встроенная подсветка синтаксиса, нумерация строк и адекватный пейджинг;ls → eza, потому что позволь себе уже полюбить цветовое кодирование и иконки;find → fd за интуитивный синтаксис и быструю выдачу;grep → ripgrep опять же из-за скорости;top → btop для комплексного мониторинга ресурсов, хоть btop и перегружен визуально.Дальше на ночь пятничная сказка про холивар.
Базовый набор GNU coreutils создавался в эпоху, когда деревья в файловых системах были маленькими,
В подобных обсуждениях всегда появляется Суровый Системный Администратор Старой Школы и настаивает, что все эти цветастые игрушки абсолютно бесполезны при заходе по SSH на боевой сервер. Там тебя встретит голый bash и девственно чистый vi. В ответ на это в него кидаются терраформами и ансиблами и спрашивают, а зачем мол вообще в наше время ходить на продакшен по ssh?
Пожалуй, единственное здравое правило, которое можно вынести из этого противостояния: как только дело доходит до автоматизации и bash-скриптов, надо возвращаться к POSIX-совместимым конструкциям и классическим coreutils, иначе автоматизация сломается на первой же машине.
❤10
Подъехал обзор по Trivy с инструкциями
https://tproger.ru/articles/ataki-na-trivy--kak-skaner-uyazvimostej-stal-vektorom-ataki-i-chto
Псам предлагаю проверить, всё ли вы учли и обновили
А пёсикам разобраться, что вообще происходит🥺
https://tproger.ru/articles/ataki-na-trivy--kak-skaner-uyazvimostej-stal-vektorom-ataki-i-chto
Псам предлагаю проверить, всё ли вы учли и обновили
А пёсикам разобраться, что вообще происходит
Please open Telegram to view this post
VIEW IN TELEGRAM
Tproger
Trivy: полный чек-лист по защите CI/CD и разбор инцидента
Разбор двух атак на Trivy в феврале-марте 2026: CVE-2026-28353, ретроактивное отравление тегов GitHub Actions, CanisterWorm. Как проверить проект и защитить CI/CD.
👍3🤝2
jsongrep — быстрее чем jq, jmespath, jsonpath-rust и jql?Студент вдохновился историей рипгрепа и сделал инструмент для поиска значений в JSON-документах. Концептуально он делает то же, что и
grep для текста: скармливаете JSON, даёте паттерн, получаете все значения, пути к которым попадают под этот паттерн («достань мне все поля error из логов за сегодня»).Язык запросов выглядит как смесь JSONPath и регулярных выражений. Если вы когда-нибудь писали регулярки для путей в файловой системе или URL, то тут всё очень похоже, только вместо символов у вас ключи и индексы.
Зачем это нужно
Если вы работаете с большими JSON-файлами, то рано или поздно сталкиваетесь с задачей «достань мне все значения по такому-то пути».
jq для этого подходит, но он тяжеловесный: это полноценный язык трансформации, интерпретатор, который на каждом шаге оценивает выражения, проверяет условия, рекурсивно обходит дерево. Для простого поиска это оверкилл.jsongrep сознательно ограничен: он не умеет трансформировать данные, нет арифметики, нет фильтров, нет строковой интерполяции. Зато за счёт этого он работает на порядок быстрее на больших документах, что подтверждают бенчмарки автора: на 190-мегабайтном GeoJSON файле он обходит jq в end-to-end тестах с внушительным отрывом.Кейсы применения
— Анализ логов в JSON-формате.
jsongrep с флагом -F делает рекурсивный поиск поля на любой глубине одной командой.— Работа с API-ответами.
curl + jsongrep быстрее, чем открывать Postman или писать jq-ванлайнер для простой выборки.— GeoJSON и прочие большие структурированные файлы. Например для городских служб, геодезистов, GIS-специалистов, которым нужно быстро извлекать данные из таких файлов без загрузки всего документа в память.
Почему так быстро
Автор учил теорию автоматов, технические детали можно почитать в статье. Если упростить, нет никаких if-else цепочек, нет рекурсивного спуска с проверкой условий на каждом узле. Неподходящая ветка дерева отсекается за O(1) — просто нет перехода в таблице.
Есть и цена за эту скорость: компиляция запроса в DFA занимает время. На маленьких документах
jq может оказаться быстрее просто потому, что не тратит время на построение автомата. Но на документах от мегабайта и выше jsongrep начинает выигрывать.Инструмент новый, студенческий, в бою ещё не протестирован, но как минимум ставим лайк за научный подход.
https://github.com/micahkepe/jsongrep
👍5
Health Score для PostgreSQL: один показатель вместо 150 метрик
В традиционном мониторинге PostgreSQL сотни метрик, но нет ответа на вопрос «база здорова?». CPU 60%, connections 50%, idle in transaction 40% — ни один порог не пробит, но база тормозит. Health Score агрегирует пять категорий (Connections, Performance, Storage, Replication, Maintenance) в число от 0 до 100 с нелинейными штрафами за опасные комбинации и автодиагностикой: список проблем и готовые рекомендации.
Для дежурного инженера это первый экран вместо десятков дашбордов. Система учитывает исторический baseline, поэтому аномалия определяется не по жёсткому порогу, а по отклонению от обычного поведения. Подробнее о формуле и внедрении — в статье: https://habr.com/ru/articles/1016288/
В традиционном мониторинге PostgreSQL сотни метрик, но нет ответа на вопрос «база здорова?». CPU 60%, connections 50%, idle in transaction 40% — ни один порог не пробит, но база тормозит. Health Score агрегирует пять категорий (Connections, Performance, Storage, Replication, Maintenance) в число от 0 до 100 с нелинейными штрафами за опасные комбинации и автодиагностикой: список проблем и готовые рекомендации.
Для дежурного инженера это первый экран вместо десятков дашбордов. Система учитывает исторический baseline, поэтому аномалия определяется не по жёсткому порогу, а по отклонению от обычного поведения. Подробнее о формуле и внедрении — в статье: https://habr.com/ru/articles/1016288/
Хабр
Health Score для PostgreSQL: один показатель вместо 150 метрик
Представьте: вы открываете Grafana в три часа ночи по алерту. На экране — 30 дашбордов, сотни графиков, и везде мигает жёлтым. CPU 60%, connections 50%, replication lag 500ms, bloat растёт, dead...
В каком порядке что изучать в девопсе? Популярных роадмапов куча, идеального нет.
roadmap.sh/devops — самый полный по охвату, но это гигантская интерактивная карта без чёткого порядка: открываешь и тонешь в сотне тем.
github.com/milanm/DevOps-Roadmap — выглядит всё очень уверенно и как будто свежее, но в реальности чел просто обновил заголовок на 2026 год, а внутри всё ещё лежит информация например про Puppet.
devopsroadmap.io — интереснее по подходу: итеративное обучение через сквозной проект, GitOps и security подаются как база, есть ветки роста (SRE, Platform Engineering, MLOps). Но внутри скорее каркас со ссылками, чем полноценный контент. Сетей нет, Ansible нет, облако обзорно. Как навигатор сгодится.
Что реально нужно в 2026 и чего нет ни в одном роадмапе целиком: GitOps (Argo CD/Flux), Platform Engineering, FinOps для больших, OpenTelemetry. Secrets management (Vault, External Secrets) — это вообще первое, что настраиваешь на проекте. Тему AI в пайплайне генераторы контента тоже пока не научились системно покрывать.
Есть курс Яндекс Практикума PRO «DevOps для эксплуатации и разработки». Он хорошо закрывает ядро: Git с Git Flow, GitLab CI, Terraform, Ansible, Docker, Kubernetes, мониторинг (Prometheus + Grafana + Loki), CD с rollback и feature flags, DORA-метрики. Финальный проект в Yandex Cloud с фидбеком от эксперта.
Чего курс не даст: обучение программированию, GitHub Actions, GitOps/Argo CD, Kustomize, облачный провайдер системно (AWS/Azure/GCP), supply chain security, тестирование как дисциплину. Это придётся добирать самостоятельно, как и фундаментальные знания по сетям (не знаю, почему к ним сейчас так мало внимания).
Если нужна структура с менторством — курс + параллельно по roadmap.sh ходить в ширину и в глубину. Если умеете планировать обучение и пинать себя самостоятельно — документация, домашний кластер в minikube и реальные проекты на GitHub закроют 80% потребностей.
roadmap.sh/devops — самый полный по охвату, но это гигантская интерактивная карта без чёткого порядка: открываешь и тонешь в сотне тем.
github.com/milanm/DevOps-Roadmap — выглядит всё очень уверенно и как будто свежее, но в реальности чел просто обновил заголовок на 2026 год, а внутри всё ещё лежит информация например про Puppet.
devopsroadmap.io — интереснее по подходу: итеративное обучение через сквозной проект, GitOps и security подаются как база, есть ветки роста (SRE, Platform Engineering, MLOps). Но внутри скорее каркас со ссылками, чем полноценный контент. Сетей нет, Ansible нет, облако обзорно. Как навигатор сгодится.
Что реально нужно в 2026 и чего нет ни в одном роадмапе целиком: GitOps (Argo CD/Flux), Platform Engineering, FinOps для больших, OpenTelemetry. Secrets management (Vault, External Secrets) — это вообще первое, что настраиваешь на проекте. Тему AI в пайплайне генераторы контента тоже пока не научились системно покрывать.
Есть курс Яндекс Практикума PRO «DevOps для эксплуатации и разработки». Он хорошо закрывает ядро: Git с Git Flow, GitLab CI, Terraform, Ansible, Docker, Kubernetes, мониторинг (Prometheus + Grafana + Loki), CD с rollback и feature flags, DORA-метрики. Финальный проект в Yandex Cloud с фидбеком от эксперта.
Чего курс не даст: обучение программированию, GitHub Actions, GitOps/Argo CD, Kustomize, облачный провайдер системно (AWS/Azure/GCP), supply chain security, тестирование как дисциплину. Это придётся добирать самостоятельно, как и фундаментальные знания по сетям (не знаю, почему к ним сейчас так мало внимания).
Если нужна структура с менторством — курс + параллельно по roadmap.sh ходить в ширину и в глубину. Если умеете планировать обучение и пинать себя самостоятельно — документация, домашний кластер в minikube и реальные проекты на GitHub закроют 80% потребностей.
❤4
Улучшаем Dockerfile: от примитивной базы к multi-stage-решению
Dockerfile можно составить по-разному, и даже самые примитивные его варианты могут работать, но это не значит, что их стоит использовать. Поэтому давайте разбираться, как сделать из Dockerfile конфетку. Для этого читайте статью. Там Dockerfile становится всё круче с каждым шагом:
🔘 Начинается с наивного подхода — всё работает, но образ тяжеленный, сборка занимает 10 минут, а результат непредсказуем.
🔘 Multi-stage — разделяем сборку и рантайм, финальный образ содержит только бинарник и необходимые runtime-зависимости.
Другие два шага, а также отдельный блок о том, почему не все лучшие практики стоит бездумно выполнять — по ссылке.
Dockerfile можно составить по-разному, и даже самые примитивные его варианты могут работать, но это не значит, что их стоит использовать. Поэтому давайте разбираться, как сделать из Dockerfile конфетку. Для этого читайте статью. Там Dockerfile становится всё круче с каждым шагом:
Другие два шага, а также отдельный блок о том, почему не все лучшие практики стоит бездумно выполнять — по ссылке.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2❤1
Microsoft заблокировала разработчиков WireGuard и VeraCrypt — без предупреждения
Microsoft отозвала доступ к Windows Hardware Program у мейнтейнеров WireGuard, VeraCrypt, MemTest86 и Windscribe. Причина — непройденная верификация, о которой никто не уведомил.
Без подписи Microsoft выпустить обновление драйвера для Windows невозможно. Если завтра в WireGuard найдут критическую RCE — патч до пользователей не дойдёт.
Мейнтейнер WireGuard так и написал: «А если бы нашли критическую уязвимость?» Разблокировка началась только после публичного шума — VP Scott Hanselman написал лично.
Supply chain риск: один сбой у вендора — и open source инструменты в вашем стеке не получают security-обновления.
Microsoft отозвала доступ к Windows Hardware Program у мейнтейнеров WireGuard, VeraCrypt, MemTest86 и Windscribe. Причина — непройденная верификация, о которой никто не уведомил.
Без подписи Microsoft выпустить обновление драйвера для Windows невозможно. Если завтра в WireGuard найдут критическую RCE — патч до пользователей не дойдёт.
Мейнтейнер WireGuard так и написал: «А если бы нашли критическую уязвимость?» Разблокировка началась только после публичного шума — VP Scott Hanselman написал лично.
Supply chain риск: один сбой у вендора — и open source инструменты в вашем стеке не получают security-обновления.
❤4
Little Snitch вышел на Linux — мониторинг исходящих соединений на eBPF, бесплатно
Инструмент, который 20 лет был только на macOS, теперь работает на Linux. Показывает сетевую активность каждого процесса в реальном времени — без iptables-правил и без
Работает на eBPF, веб-интерфейс на
Лицензия: eBPF-модуль и веб-интерфейс — GPLv2, демон проприетарный, но бесплатный. Авторы честно предупреждают: это инструмент для приватности, не замена WAF.
Подробнее на Tproger
Инструмент, который 20 лет был только на macOS, теперь работает на Linux. Показывает сетевую активность каждого процесса в реальном времени — без iptables-правил и без
tcpdump | grep.Работает на eBPF, веб-интерфейс на
localhost:3031. Поддерживает блоклисты Hagezi и Steven Black. Полезно после деплоя нового образа, при отладке агента или при расследовании аномальной активности.Лицензия: eBPF-модуль и веб-интерфейс — GPLv2, демон проприетарный, но бесплатный. Авторы честно предупреждают: это инструмент для приватности, не замена WAF.
Подробнее на Tproger
❤5🔥2🏆1
Flatpak: критическая уязвимость — побег из песочницы. Обновитесь.
CVE-2026-34078, рейтинг Critical. Любое Flatpak-приложение может полностью выйти из изоляции: читать и писать файлы хоста, выполнять произвольный код.
Фикс:
Если у вас в инфре крутятся Flatpak-приложения или вы используете их в CI — обновите пакет и убедитесь, что sandbox-политики не опираются на старое поведение.
CVE-2026-34078, рейтинг Critical. Любое Flatpak-приложение может полностью выйти из изоляции: читать и писать файлы хоста, выполнять произвольный код.
Фикс:
flatpak 1.16.4. Большинство дистрибутивов уже доставляют патч через стандартные обновления — проверьте, что версия актуальна.Если у вас в инфре крутятся Flatpak-приложения или вы используете их в CI — обновите пакет и убедитесь, что sandbox-политики не опираются на старое поведение.
🔥1
Chrome 146 включил DBSC — пора добавить два эндпоинта, если не хотите, чтобы угнанные сессии жили вечно
DBSC (Device Bound Session Credentials) привязывает сессионные cookies к TPM-чипу клиента. Chrome генерирует пару ключей через TPM при логине, публичный отдаёт серверу, приватный остаётся в чипе. На каждом refresh сервер шлёт challenge — клиент подписывает его через TPM. Без оригинального железа подпись не сделать.
Что это значит на практике: если инфостилер (Lumma, Vidar, StealC) слил cookies и залил на свой хост, сессия умрёт на первом refresh. Никаких изменений на фронте — только два новых бэкенд-эндпоинта: регистрация устройства и refresh с верификацией подписи.
Спецификация открытая, W3C, пилили Google с Microsoft. macOS через Secure Enclave — в следующих релизах, Linux пока в пролёте, Firefox и Safari молчат.
Как внедрять на бэкенде — разбор на Tproger.
DBSC (Device Bound Session Credentials) привязывает сессионные cookies к TPM-чипу клиента. Chrome генерирует пару ключей через TPM при логине, публичный отдаёт серверу, приватный остаётся в чипе. На каждом refresh сервер шлёт challenge — клиент подписывает его через TPM. Без оригинального железа подпись не сделать.
Что это значит на практике: если инфостилер (Lumma, Vidar, StealC) слил cookies и залил на свой хост, сессия умрёт на первом refresh. Никаких изменений на фронте — только два новых бэкенд-эндпоинта: регистрация устройства и refresh с верификацией подписи.
Спецификация открытая, W3C, пилили Google с Microsoft. macOS через Secure Enclave — в следующих релизах, Linux пока в пролёте, Firefox и Safari молчат.
Как внедрять на бэкенде — разбор на Tproger.
Linux 7.0 берёт в mainline первый RVA23-чип — пора целить toolchain в новый профиль
SpacemiT K3, первый коммерческий SoC на RVA23, входит в mainline Linux 7.0 (релиз 12 апреля). В 7.1 добавят драйверы периферии и оптимизации под вектор. Ubuntu 26.04 LTS — одна из первых платформ с K3 из коробки.
Суть не в чипе, а в профиле: RVA23 фиксирует обязательный набор расширений — Vector 1.0, битовые манипуляции, крипто, для серверного RVA23S64 ещё и гипервизор. Один RISC-V бинарь теперь работает на любом сертифицированном железе, без угадывания feature-флагов.
Что делать: пересобрать toolchain под RVA23-таргет, прогнать CI через QEMU с
SpacemiT K3, первый коммерческий SoC на RVA23, входит в mainline Linux 7.0 (релиз 12 апреля). В 7.1 добавят драйверы периферии и оптимизации под вектор. Ubuntu 26.04 LTS — одна из первых платформ с K3 из коробки.
Суть не в чипе, а в профиле: RVA23 фиксирует обязательный набор расширений — Vector 1.0, битовые манипуляции, крипто, для серверного RVA23S64 ещё и гипервизор. Один RISC-V бинарь теперь работает на любом сертифицированном железе, без угадывания feature-флагов.
Что делать: пересобрать toolchain под RVA23-таргет, прогнать CI через QEMU с
-cpu max, для пилота взять Banana Pi BPI-F3 на K1. Production пока рано — серийных K3-плат нет, CI-раннеры на RISC-V в пять раз медленнее x86. Разбор и практические шаги.Мэн заморозил новые ЦОДы мощнее 20 МВт — закладывайте в GPU-бюджет
LD 307 запрещает штату и муниципалитетам выдавать разрешения на любые дата-центры с подключённой мощностью выше 20 МВт. Порог подобран прицельно: корпоративные и колокейшен-объекты проходят, а гиперскейлерные ИИ-кластеры (тысячи GPU легко уходят за 50–100 МВт) — нет. Мораторий действует до 1 ноября 2027 года.
По данным Data Center Watch, за два года по США заблокировано проектов примерно на $64 млрд. Локальные паузы уже ввели округа в Мичигане и Индиане, на подходе Денвер и Детройт.
Что делать сейчас: следить за Вирджинией и Техасом как ранним индикатором (там основная масса ЦОДов), закладывать диапазон неопределённости в годовые GPU-бюджеты, мониторить spot-цены на H100/B200 у Yandex Cloud, VK Cloud и Cloud.ru — там эффект глобального дефицита виден первым.
LD 307 запрещает штату и муниципалитетам выдавать разрешения на любые дата-центры с подключённой мощностью выше 20 МВт. Порог подобран прицельно: корпоративные и колокейшен-объекты проходят, а гиперскейлерные ИИ-кластеры (тысячи GPU легко уходят за 50–100 МВт) — нет. Мораторий действует до 1 ноября 2027 года.
По данным Data Center Watch, за два года по США заблокировано проектов примерно на $64 млрд. Локальные паузы уже ввели округа в Мичигане и Индиане, на подходе Денвер и Детройт.
Что делать сейчас: следить за Вирджинией и Техасом как ранним индикатором (там основная масса ЦОДов), закладывать диапазон неопределённости в годовые GPU-бюджеты, мониторить spot-цены на H100/B200 у Yandex Cloud, VK Cloud и Cloud.ru — там эффект глобального дефицита виден первым.
❤2