Все потоки

12% всех зарегистрированных утечек данных в России начинались с атаки на топ-менеджмент (по данным PT EdTechLab). Так случилось, что собственники и ТОПы — это люди с уникальным, точнее уникально взрывоопасным, сочетанием максимального уровня привелегий и доверия внутри компании с, часто, относительно халатным отношением к кибергигиене. Бывает, что к этому добавляется еще наполняющая кибератаки фактурой публичность. Поделюсь пророчествами мыслями, к чему это может привести, и рекомендациями, что делать специалисту по ИБ, чтобы оптимизировать риски.

Три сценария, к которым нужно быть готовым

1. Целевой фишинг (он же "whaling" — охота на китов)

Атакующий изучает жертву заранее: интервью, стиль общения, распорядок дня. Потом приходит точное, убедительное, срочное письмо.

Классические сценарии: правдоподобные инструкции (иногда в формате дипфейков) от якобы директора перевести деньги или срочно открыть доступ.

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

2. Компрометация личных устройств

Руководители редко разделяют личное и рабочее. Один ноутбук и смартфон для всего: личная и корпоративная почта, мессенджеры, соцсети, банковское приложение компании.

Привет, Хаброжители! У нас отличные новости для всех, кто хочет освоить Go или систематизировать свои знания. Мы открыли предзаказ на новую книгу Станислава Чернышева «Основы Go». Чтобы вы могли оценить подачу материала и глубину погружения, мы делимся с вами эксклюзивным отрывком.

В начале 2026 года я запустил опрос в отделе: «Какими ИИ-инструментами вы пользуетесь?» Из 20 опрошенных только 3 человека пробовали ИИ-агентов в работе. Большинство технической команды — это хардкорные МЛ-щики, которые создают системы поиска патологий на медицинских снимках, а не просто дергают API ChatGPT с нужным промптом.

Но почему даже в такой ИИ-организации процент людей, попробовавших ИИ-агентов, настолько низкий?

Представьте машину времени. Не ту, что переносит в прошлое или будущее, а ту, что ускоряет ваши собственные биологические часы прямо сейчас. Садитесь внутрь, проводите в ней год и выходите с телом, которое прошло через изменения, характерные для нескольких десятилетий жизни на Земле. Мышцы истончились. Кости стали хрупкими. Кроветворные стволовые клетки состарились на молекулярном уровне. Иммунитет работает непредсказуемо.

Такая машина существует и находится примерно в 400 км над вашей головой. Это Международная космическая станция.

← Восьмая часть

Описанный в предыдущих частях калькулятор уже работал. Реализация 2021 года запускалась на реальном оборудовании, обрабатывала нажатия клавиш, вычисляла результаты и отображала их. Арифметика была корректной в том смысле, что большинство результатов было точным до 12 значимых разрядов, а это больше, чем требуется обычному пользователю.

Но «большинство» это не «все», а «примерно 12» — это не 15-16 разрядов, которые может и должна обеспечивать 16-разрядная BCD-машина. Существовали пограничные случаи, в которых результаты оказывались совершенно неверными. Имелись итеративные алгоритмы с точностью приемлемой, но не такой, какой она могла быть. Кроме того, в процессе тестирования я обнаружил ошибки, при отладке которых обнаружились фундаментальные баги в коде прототипа на C++. Это привело меня в смятение, ведь для их устранения мне бы пришлось переделать заново код прототипа. В конечном итоге, так я и поступил. Старый код я оставил в репозитории (Pathfinding/Methods) и с нуля разработал совершенно новую версию (Pathfinding/Proof). Я пообещал себе, что занимаюсь этим последний раз в жизни, поэтому стремился делать всё идеально.

В итоге, версия 2025 года устранила найденные мной проблемы. Это был не патч, а почти полное переписывание арифметического движка, расширение набора команд CPU и существенное увеличение библиотеки функций. В этом посте я расскажу об изменениях и их причинах.

Когда в зависимости обнаруживают уязвимость, очевидное решение — поднять её минимально допустимую версию во всех библиотеках, которые ее используют. Тогда пакетный менеджер не подтянет уязвимую версию даже при новой установке. Сет Ларсон из Python Software Foundation предлагает не делать этого автоматически. По его мнению метаданные библиотеки должны описывать только совместимость, а контроль безопасности сборки оставаться на стороне приложения.

Колонка Сета вызвала спор в Python-сообществе: одни поддержали разделение ответственности между библиотекой и приложением, другие заметили, что безопасность тоже может входить в условия поддержки библиотеки. Мы в CodeScoring подготовили перевод колонки, разбор обеих позиций и наш взгляд на этот вопрос.

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

Когда мы проектируем дашборды, мы работаем не только с данными, но и с особенностями человеческого восприятия. Именно поэтому хорошие интерфейсы редко появляются случайно, обычно за ними стоят вполне конкретные принципы.

В этой статье я расскажу о трех подходах, которыми пользуюсь практически в каждом дашборде:

Расширение, обработку или модуль для 1С можно зарегистрировать как самостоятельный программный продукт. Однако заявку чаще тормозит не процедура подачи, а неподготовленные документы: неоформленные права, формальное описание продукта, отсутствие инструкции, сайта и понятного жизненного цикла.

На Инфостарте опубликована пошаговая инструкция по включению решений 1С в Реестр отечественного ПО. В статье разобрано, какие продукты можно зарегистрировать, кто вправе подать заявку и как подтвердить, что программа существует, используется, развивается и поддерживается...

Я много лет занимаюсь развитием финтех-продуктов, а сейчас руковожу продуктами биллинговой платформы в Selectel.

За это время я много раз сталкивался с одной и той же проблемой: для решения задачи в графическом интерфейсе почти всегда приходится выбирать между простотой и универсальностью.

Ниже — о том, почему привычный GUI может уступить место ИИ-агентам и как это решает вечную дилемму продуктового дизайна.

В парадигме рассмотрения организации через метафору «Мозг», акцент рекогносцировки смещается на обучение, и Организация рассматривается уже как когнитивная система, способная анализировать информацию, интегрироваться в сложность мира и быть восприимчивой к своим ошибкам. Если «Машина» специализируется на правилах и контроле, а «Организм» — на выживаемости в среде, то «Мозг» трактует организацию как интеллектуальную, распределенную и самообучающуюся систему, с высоким потенциалом к самоорганизации.

Если искать в интернете «мощный DI-контейнер для .NET», почти в каждом списке встретится Autofac. У него заслуженная репутация зрелого и функционального контейнера. На этом фоне Pure.DI иногда воспринимают как узкоспециализированный генератор, который выигрывает в скорости, но должен уступать классическому DI-контейнеру по возможностям.

Память стала одной из самых востребованных функций диалоговых и агентных систем. Если пользователь регулярно обращается к ассистенту — для работы, консультаций, планирования, обучения или бытовых задач, — то от системы уже ожидают не просто хорошего общего ответа. От неё ждут, что она будет учитывать прошлые взаимодействия: помнить неизменные факты о пользователе, не терять важный контекст, обновлять устаревшую информацию и понимать, когда именно произошло то или иное событие.

При этом такая память о пользователе обычно не является встроенным свойством самой языковой модели. В прикладных продуктах её чаще добавляют как отдельный слой вокруг LLM: например, через RAG с долговременным хранилищем фактов (векторные или графовые базы памяти, профили пользователя, журналы событий) или агентные схемы — например, локальную файловую систему в духе Obsidian в сочетании с вызовом инструментов.

Из-за этого качество памяти становится не столько вопросом того, насколько хороша модель, сколько вопросом всей архитектуры: как система извлекает факты, что именно сохраняет, как разрешает противоречия, удаляет ли данные по запросу пользователя и как использует временной контекст.

Для русского языка до сих пор не хватало бенчмарка, который проверяет именно такие аспекты долгосрочной памяти в многосессионных диалогах. Поэтому мы сделали RUMBA — Russian User Memory Benchmark: русскоязычный бенчмарк для анализа способности диалоговых систем работать с долгосрочной памятью пользователя в реалистичных разговорных сценариях.

Dasha - opensource дашборд производительности PostgreSQL. Читает состояние кластеров из системных представлений, без агентов на хостах; поддерживает версии 14–18 и работу с несколькими кластерами в одном интерфейсе. Анализ запросов и снимки pg_stat_statements со сравнением и авто-снимками по триггерам, анализ индексов и таблиц с учётом всех хостов кластера, обслуживание и блокировки, диагностика конфигурации, композитная оценка Health Score, поиск по логам managed-кластеров Yandex Cloud. В комплекте - read-only MCP-коннектор для AI-ассистентов.

В статье - краткий обзор и скриншоты возможностей по разделам.

Рассказываю, как я сам сделал ASGI-фреймворк, в котором дерево папок заменяет таблицу маршрутов, — и почему это решает проблему расхождения роутов с кодом. Разбираю встроенную безопасную ORM, показываю на примерах, как версионирование превращается в копирование папки, и честно привожу гоночные тесты на реальной конкурентности.

Promise, setTimeout и async/await часто работают совсем не в том порядке, которого ждёшь по коду, а тяжёлая синхронная функция способна заморозить весь интерфейс. Разберём модель цикла событий, которая объясняет эти эффекты и помогает понимать, где возникают блокировки, гонки запросов и лишние задержки.

Опыт весны/лета 2025 года

В этой статье расскажу, как устроен отбор, чему действительно учат на курсе, как организовано обучение и насколько полезной оказалась обратная связь от преподавателей и проверяющих. Отдельно поделюсь опытом прохождения всех этапов трудоустройства: от приглашения на технические собеседования до получения оффера.

Привет, Хабр! Начнем с истории, которая идеально открывает тему. В мае 2025-го подала на банкротство Builder.ai — лондонский стартап с оценкой в 1,5 миллиарда долларов и деньгами от Microsoft, SoftBank, Insight Partners и суверенного фонда Катара. Продавала она ассистента «Наташу», который якобы собирал приложения по текстовому описанию, «как заказать пиццу». По лентам мгновенно разлетелась версия: никакого ИИ не было, всё писали 700 инженеров в Индии, притворяясь нейросетью.

Недавно занимался задачей, которую в медтехе обсуждают часто, а до рабочего прототипа доходят не все: нужно было научить модель смотреть на рентген грудной клетки и выдавать вероятности по нескольким патологиям сразу. Не сегментация, не генерация отчёта — именно мультилейбл‑классификация, чтобы на выходе было что‑то вроде «плевральный выпот 87%, пневмоторакс 12%».

Полный fine‑tune большой сети на арендованной GPU мне не хотелось: дорого, долго, и есть риск переобучиться на паре десятков тысяч снимков. Поэтому пошёл по пути linear probing — взял тяжёлый предобученный энкодер, заморозил его и обучил только небольшую голову. В итоге macro AUC на валидации вышел 0.9025, обучение уложилось в десяток эпох.

Ниже — как устроен пайплайн, где накосячил с путями к датасету, и почему отказался от горизонтального отражения.

Если вы делаете мобильный банкинг, финтех или госсервисы для узбекского рынка, рано или поздно вы столкнётесь с MyID — национальной системой биометрической идентификации от UZINFOCOM. Лицо в камеру, liveness-проверка, сверка с госбазой — и удалённое открытие счёта готово. MyID поставляет нативные SDK для iOS и Android, а вот React Native-разработчикам исторически предлагалось выкручиваться самостоятельно.

В 2024 году я написал React Native-мост для MyID, который сегодня лежит в их официальном репозитории. Тот мост был для SDK второго поколения — и вместе с ним устарел: в 3.x старый флоу интеграции удалён целиком. Плюс Apple завёз privacy manifest, а Expo окончательно стал стандартом — и почти всё, что написано в интернете про «MyID + React Native», перестало работать. Поэтому появилась новая, независимая опенсорсная обёртка для 3.x, которую я теперь поддерживаю.

В этой статье разберу, как правильно заворачивать такой SDK в React Native в 2026 году: session flow вместо паспортных данных на клиенте, три айосные грабли, на которые наступает каждая первая интеграция, устройство Expo config plugin и таксономию ошибок. Всё — с проверкой на реальном железе.

Привет, Хабр! Меня зовут Рома Масягутов, в К2 Облаке я отвечаю за корпоративные инсталляции Nextcloud. Год назад мы рассказывали, как собрали из открытой платформы файлообменник, который заменяет OneDrive. Тогда речь шла про архитектуру, а сегодня поговорим про слой ИБ.

В Nextcloud есть LDAP-интеграции, антивирусные плагины, аудит, политики доступа и мониторинг. На уровне чек-листа все выглядит прилично: подключили AD, поставили антивирус через ICAP, настроили WAF, включили логирование — корпоративное хранилище защищено, а потом вы загружаете большой зараженный файл и выясняется, что антивирус его так и не увидел. Для open source это обычная ситуация. По-настоящему безопасным такое ПО становится только после того, как вы вложите массу усилий в пусконаладку. Именно это мы и делаем.

В этой статье я обрисую контуры безопасности корпоративного Nextcloud в нашем исполнении, расскажу две истории про некорректные дефолтные настройки и сравню работу ClamAV, Kaspersky Scan Engine и PT Sandbox на реальной инфраструктуре.