Технологический Болт Генона

Я рассказывал про две конфы относительно недавно и у обоих, относительно дат в моих постах, изменились даты проведения, поэтому уведомляю, так сказатб 1. Kuber Conf от АОТ переносится на 23 ноября https://t.me/tech_b0lt_Genona/7069 2. Открытая конференция ИСП РАН будет 9-11 декабря https://t.me/tech_b0lt_Genona/7068 В самих постах я уже поправил.

https://t.me/markettwits/389233 Признаться, даже я не ожидал такого развития событий, когда обсуждал использование зарубеждных дата-центров 🌝 https://t.me/tech_b0lt_Genona/7108

PwnEscape - уязвимость в сетевом стеке ядре Linux, позволяющая обойти изоляцию гипервизоров и контейнеров https://www.opennet.ru/opennews/art.shtml?num=66487

В ядре Linux выявлена критическая уязвимость (CVE-2026-99999, PwnEscape) в стеке IPv4, позволяющая получить доступ к памяти хост-окружения из гостевой системы. При успешной эксплуатации уязвимости пользователь гостевой системы может выполнить код с правами ядра на стороне хост-окружения. Эксплуатация уязвимости продемонстрирована в окружении на базе гипервизора KVM, но так как уязвимость вызвана ошибкой не в гипервизоре, а в механизме обработки сетевых пакетов ядром Linux, потенциально эксплоит может быть адаптирован и для других гипервизоров и механизмов изоляции, в которых используется штатный сетевой стек Linux. Проблема вызвана некорректной последовательностью операций при проверке контрольной суммы сетевого пакета, позволяющей изменить заголовок IPv4 в момент после проверки корректности информации, но до выполнения действий с ним (TOCTOU - Time-Of-Check-To-Time-Of-Use). При определённых условиях вычисление контрольной суммы выполняется в отложенном режиме, уже после разбора и проверки сетевого пакета, что может привести к изменению уже проверенных данных и чтению до 32 байт из области памяти вне буфера, в котором происходит обработка пакета. Атака производится через отправку из гостевой системы пакета с флагом CHECKSUM_PARTIAL, при котором контрольная сумма вычисляется не сразу, и специально подобранными значениями skb->csum_start и skb->csum_offset. Пакет проходит проверку в сетевом стеке, так как длина заголовка корректна и равна 20 байт. Завершение вычисления контрольной суммы осуществляется при обработке фрагментации, но из-за некорректных значений csum_start и csum_offset результат записывается в самое начало IPv4-заголовка и изменяет первый байт, хранящий размер, увеличивая его 20 до 60 байт. При дальнейшей обработке ядро считает, что размер заголовка теперь 60 байт, при копировании читает дополнительные 40 байт (c учётом хвостовых служебных 8 байт, читается 32 байта из области вне буфера) и отправляет обратно в составе секции с IP-опциями. В подготовленном эксплоите утечку 32 байт удалось использовать для контролируемой перезаписи 64 байт в памяти ядра и добиться выполнения кода на стороне хост-окружения с правами root. Исследователи пока не опубликовали технические детали данной стадии атаки и код эксплоита, чтобы дать пользователям время на установку обновления. Предположительно, утечка вначале используется для воссоздания раскладки памяти ядра в обход рандомизации KASLR, после чего создаются условия для выделения целевой структуры ядра с указателем сразу за памятью с буфером пакета и переписывают указатель, инициировав действие, приводящее к изменению данных в секции с IP-опциями, выходящими за границу буфера. Уязвимость устранена в вчерашних обновлениях ядра Linux 7.2.11, 6.18.57, 6.12.113, 6.6.159, 6.1.190, 5.15.223 и 5.10.272.

Оригиналы PwnEscape: Guest-to-Host KVM Escape (CVE-2026-99999) https://www.openwall.com/lists/oss-security/2026/10/15/5 PwnEscape: Guest-to-Host KVM Escape (CVE-2026-99999) https://pwn.ai/blog/pwnescape

Теперь и в Telegam эта хренотень заедет 🌝 Ждём платные посты в фиде и "продвижение" за деньгу малую.

Пропускная дееспособность https://www.kommersant.ru/doc/9027535

В Минцифры предлагали добиться 95-процентной эффективности блокировки VPN благодаря технологиям ИИ, рассказал “Ъ” источник, знакомый с ходом обсуждения инициативы. Такая же мера содержится в проекте национального плана по внедрению технологий ИИ до 2030 года, с которым ознакомился “Ъ”. В документе говорится, что для этого планировалось довести долю VPN-сервисов, признаки которых анализируются ИИ, от общего количества блокируемых VPN-сервисов до 70%. В Минцифры “Ъ” сказали, что в «актуальной версии проекта национального плана по внедрению технологий ИИ таких сведений нет». Источник “Ъ”, знакомый с ходом обсуждения инициативы, объясняет, что ведомства предлагали включить в нацплан различные меры, которые могут и не дойти до реализации. Он добавляет, что сейчас уже используются алгоритмы интеллектуального анализа трафика, которые, однако, не являются ИИ. В Роскомнадзоре не ответили “Ъ”. «ИИ автоматизирует и ускоряет анализ паттернов соединения: размер и ритм пакетов, длительность сессий, соотношение входящего и исходящего трафика. Инструменты ИИ позволяют относительно быстро находить VPN-серверы по косвенным признакам: как ведет себя узел, на каком хостинге стоит, на что похожи соседние адреса. И самое главное — за счет этого можно быстрее реагировать на изменения сетевой активности»,— объясняет источник “Ъ” на сетевом рынке. Тем не менее, говорит он, на больших объемах трафика даже малый процент ошибок анализа и блокировки «означает много заблокированного легитимного трафика», тогда как сейчас, по его оценке, доля ошибок составляет 5–6%. С ним соглашается собеседник “Ъ” на ИТ-рынке: применение ИИ, скорее всего, увеличит долю заблокированных VPN, но параллельно, «особенно на первых этапах обучения, будет много ложных срабатываний». Точность фильтрации можно повысить, когда ИИ не принимает решение единолично, а работает как первый фильтр, считает источник “Ъ” на сетевом рынке. Например, модель отмечает подозрительный узел, затем его проверяют отдельно (подключаются к нему как обычный клиент VPN и подтверждают, что это действительно VPN-сервис) и только после этого блокируют адрес. «Модель агрегирует десятки слабых признаков, поэтому видит новые сервисы, которых еще нет в списках правил,— здесь ее главный выигрыш. Проблема в том, что корпоративный VPN, облачный доступ и голосовой трафик статистически похожи на обходной, а цена ошибки для бизнеса выше, чем пропуск домашнего VPN»,— говорит партнер практики «Цифровая трансформация» компании Strategy Partners Сергей Кудряшов. Он добавляет, что в исследованиях качество распознавания резко падает, когда часть наблюдаемых признаков закрывается: «Маскировка одного поля в TLS-заголовке снижала точность до примерно 38%». При этом он считает, что одного DPI-оборудования на узлах операторов будет недостаточно для ИИ-детекции VPN-сервисов: «ИИ-контур — это отдельная вычислительная платформа поверх ТСПУ. Нужны три слоя: сбор и хранение телеметрии петабайтного масштаба, кластер для обучения и переобучения, механизм доставки обновленных моделей на узлы фильтрации».

В этой новости в целом ничего нового нет. То что ИИ рано или поздно будет применяться для организации блокировок это секрет Полишинеля. Было бы новостью реальной, если бы сказали, что появилось российское железо, которое позволило бы обучать и работать с ИИ-шкой для этого не хуже чем у лидеров индустрии. Вот это реально было бы интересно 🌝

Когда я работал с Yandex Cloud, рабочий IP почти никогда не получался с первой попытки: адрес то оказывался под блокировками РКН, то упирался в ограничения ТСПУ. Сегодня получил IP адреса в Selectel и все адреса выдались с первого раза и идеально прошли мои проверки. Стало интересно, что это за адреса. Оказалось это свежеанонсированные сети, и у многих американское прошлое. Почему адреса Selectel "чистые" - провел микрорасследование по реестру RIPE Как я исследовал • Взял все IPv4-префиксы трех AS Selectel (50340, 49505, 61976) по RIPEstat и отобрал те, что впервые появились с середины апреля 2026 • Для каждого блока поднял историю BGP-анонсов, чтобы понять, кто анонсировал его раньше • Скачал журнал всех переводов RIPE NCC (transfers_latest.json) и скриптом связал два шага: переход блока из ARIN в RIPE и последующую передачу получателю из РФ. Перекрывающиеся диапазоны учтены один раз • Каждую цифру перепроверил повторным расчетом. Срез на 14.10.2026 Что анонсирует Selectel С середины апреля 2026 появилось 176 новых префиксов, из них 118 из адресного пространства ARIN. Например, 135.106.0.0/16: с 2017 по октябрь 2025 его анонсировала AS14962 (NCR Voyix). Цепочка • 02.10.2025 - NCR перестает анонсировать блок • 24.11.2025 - блок переходит из ARIN в RIPE к Fiber Ltd (Сейшелы) • 09.02.2026 - Selectel получает почти весь 135.106.128.0/17 (без одной /23) от частного лица из РФ • 23.04-12.10.2026 - Selectel анонсирует его 25 префиксами Как блок попал от Fiber Ltd к продавцу, журнал не показывает. Всего Fiber Ltd получила из ARIN пять блоков /16. Масштаб С начала 2025 из ARIN в RIPE прошло 1081 перевод, 16,2 млн адресов. Напрямую российским получателям - ни одного (страну журнал пишет с июля 2025, у 157 переводов она не указана). Но 260 608 адресов (1,6%) потом перешли 71 получателю из РФ. Больше всех получил Selectel (~76 тыс.), дальше Beget, IOT, VK, AdminVPS, Vpsville. Среди получателей также Kaspersky Lab, OTP Bank, 1C, Cloud.ru. При средней цене около $22 за адрес (оценка Джеффа Хьюстона в блоге ARIN, январь 2026) это порядка $5,7 млн (мой расчет). Пик пришелся на I квартал 2026: 101 376 адресов. Медианный срок от перехода к посреднику до продажи в РФ - 91 день по 132 сделкам, самый быстрый - 21 день. Чьи это были адреса По истории BGP: University of Pittsburgh, Brown University, Bentley University, University of Idaho, Windstream, Next Level Connect и четыре блока NCR Voyix. Посредники: Fiber Ltd, Wireless Ltd, iNet Ltd (Сейшелы), Address Limited, EscrowTele.Com (Гонконг), NetAssets (ОАЭ), PlusInfo (США), Brander Group. Для контраста: из APNIC Selectel и МТС получают блоки напрямую. Выводы 1. Каждый шаг - зарегистрированный перевод в RIR. О нарушениях я не утверждаю. 2. Из ARIN в РФ напрямую получено ноль. Через посредников, зарегистрированных на Сейшелах, в Гонконге и ОАЭ получено сотни тысяч адресов. 3. Моя гипотеза, почему адреса "чистые": у них нет российской истории, и блокировки на них еще не накопились. Проверял я только свои адреса, так что это наблюдение, а не вывод. 4. Для allowlist и антифрода смотрите историю префикса. MaxMind уже показывает Москву для адресов Selectel из 135.106, хотя год назад их анонсировала NCR.

https://github.com/rust-lang/rust/issues/164348 🤡 Раст считает за один файл: data/baselines/table.rs database/line/stable.rs

Чо та поднакопилось за несколько дней инноваций про безопасность. Минцифры хочет обязать 5G-смартфоны поддерживать шифр «Кузнечик» https://kod.ru/mintsifry-kuznechik-5g-smartfony

Минцифры подготовило проект приказа, по которому смартфоны в российских сетях 5G должны будут поддерживать отечественный шифр «Кузнечик». Об этом пишет РБК. «Кузнечик» — российский алгоритм шифрования, закреплённый в ГОСТе. Его применяют в электронной подписи, защищённых каналах связи и государственных информационных системах. Алгоритм разработали при участии Центра защиты информации и специальной связи ФСБ и компании «ИнфоТеКс». В сетях 5G он обозначается как NEA7 (шифрование данных) и NIA7 (проверка, что данные не подменили по дороге). Проект делает эти алгоритмы обязательными для абонентских устройств. Трафик должны защищать средства криптографической защиты информации (СКЗИ) класса не ниже КС3, такой класс установлен приказом ФСБ. Сам приказ должен вступить в силу 1 марта 2027 года, а пункт о «Кузнечике» — только 1 марта 2032 года. Документ будет действовать шесть лет, соответствие смартфонов требованиям подтверждается декларациями. Вместе с ним готовится проект требований к базовым станциям 5G. По нему станция включает «Кузнечик», только если подключённый телефон тоже его поддерживает. Иначе станция просто не смогла бы связаться со смартфонами без российского шифра. В Минцифры подтвердили, что работа над документом продолжается, а срок в 2032 год выбран, чтобы производители успели выпустить совместимые устройства. Как будут применять требования после этой даты, в том числе к уже купленным телефонам, ещё уточнят. В министерстве отметили, что цель изменений — повысить безопасность и устойчивость сетей связи. ... Обязать сети 5G использовать российскую криптографию ФСБ пыталась ещё с 2019 года, но прежние проекты так и не утвердили. Против выступали Минэкономразвития, которое оценило расходы операторов в 14 млрд рублей каждые три года, а также Qualcomm, Nokia, Ericsson и ВымпелКом. По словам гендиректора производителя базовых станций «Сигналтек» Алексея Алясева, российские станции уже поддерживают отечественные алгоритмы программно. Чтобы шифровать радиоканал между станцией и телефоном, нужна доработка «железа»: это сотни миллионов рублей и один-два года работы. Со смартфонами сложнее. Шифрование радиоканала в них выполняет чип модема, а в чипах Qualcomm и Unisoc российских алгоритмов нет. Алясев считает, что поддержку в телефонах реально сделать не раньше 2030 года, а до тех пор связь будет защищать международный стандарт шифрования AES. Замруководителя лаборатории криптографии «Криптонита» Владимир Бельский добавил, что реализовать «Кузнечик» через SIM-карту не получится. Для массовых смартфонов нужны отечественные модемные чипы с шифром на аппаратном уровне, а готовых таких модемов сейчас нет. В отдельных устройствах вроде умных счётчиков и платёжных терминалов шифр уже работает на отдельных микросхемах. Ещё одна проблема в том, что «Кузнечика» нет в стандартах 3GPP — консорциума, который разрабатывает стандарты мобильной связи. По словам Бельского, изменения уже подготовлены, но из-за санкций внести их сейчас нельзя. Источник РБК на телеком-рынке считает, что без поддержки производителей чипов вроде Qualcomm и MediaTek не обойтись, а альтернатива — собственный крупный рынок российских смартфонов и чипов.

Прогноз неблагоприятный: эксперты увидели в «белых списках» риски для облаков https://www.forbes.ru/tekhnologii/570208-prognoz-neblagopriatnyj-eksperty-uvideli-v-belyh-spiskah-riski-dla-oblakov

Белые списки сайтов, призванные обеспечить работу ключевых онлайн-сервисов при ограничениях мобильного интернета, стали, по мнению рабочей группы правительственной подкомиссии по ИИ, источником рисков для облачных ИИ-решений в критической информационной инфраструктуре (КИИ), узнал Forbes. Под угрозой оказывается не только доступность отдельных приложений, но и работоспособность механизмов аварийного восстановления. Поэтому бизнес обсуждает с чиновниками нормативное закрепление прозрачных процедур включения в белые списки и выделение отдельных сетевых контуров для госинформсистем (ГИС) и значимых объектов КИИ ... Как выяснил Forbes, в рабочую группу поступили предложения по снятию ограничений, связанных с белыми списками. Автор инициативы — АНО «Координационный совет по ЦОДам и облачным технологиям» (АНО КС ЦОД, в числе учредителей — «Яндекс Облако» и «Центр хранения данных» «Ростелекома»). Организация предложила «сформировать критический перечень облачных платформ и сервисов, используемых для ГИС и значимых объектов КИИ, на которые указания об изоляции сегмента сети не распространяются без отдельного решения уполномоченных органов». АНО предлагает закрепить процедуру включения и исключения ресурса из белого списка, определить сроки принятия соответствующих решений, необходимость мотивировать отказ, а также порядок его обжалования. КС ЦОД также рекомендует разрешить провайдерам использовать выделенные ASN (номера автономных систем) и IP-пулы, «а также независимые точки присоединения для аттестованных контуров ГИС и КИИ с запретом смешения с публичным сегментом», а «при аудите реестров учитывать внутреннюю топологию облака, чтобы не блокировать служебные сети оркестрации, систем хранения и средств защиты информации». ... «Риски, обозначенные рабочей группой, важно учитывать при выработке правил применения белых списков, — считает основатель и гендиректор ООО «Клауд Солюшенс» (бренд Cloud X, соучредитель АНО КС ЦОД) Денис Хлебородов. «Если белые списки формируются без учета архитектуры «облака», возникает риск разрешить доступ к приложению, но заблокировать инфраструктуру, от которой зависит его работа, — поясняет он. — Например, основной регион остается доступным, а резервный — нет. При аварии облако переключает приложение на исправную площадку, DNS возвращает ее адрес, но пользователи не могут подключиться, поскольку этот адрес не включен в список. В таком случае ограничение фактически обесценивает механизм аварийного восстановления». В другом сценарии, добавляет Хлебородов, приложение продолжает работать, но заказчик теряет доступ к консоли, API управления или системе аутентификации: «Он не может добавить мощности, изменить конфигурацию или восстановить ресурс после сбоя». ... Механизм белых списков действительно может создавать риски не только для ГИС, но и для значимых объектов КИИ, подтверждают эксперты. «Если при введении ограничений не учитывать архитектуру самой облачной платформы, складывается риск нарушения доступности критически важных информационных систем. Сами серверы и ПО при этом могут оставаться полностью работоспособными, хотя взаимодействие с ними окажется затруднено или невозможно. Особенно чувствительна такая ситуация для ЗОКИИ — нарушение доступности информсистем может повлиять на непрерывность технологических и производственных процессов», — указывает генеральный директор хостинг-провайдера RUVDS Никита Цаплин. Отдельный риск возникает при аварийном восстановлении облачной инфраструктуры, добавляет генеральный директор IT-компании Orlime Александр Аксяитов. «Инциденты с дата-центрами «Яндекса» привлекли внимание к вопросам устойчивости облачных платформ. Для ГИС и значимых объектов КИИ недостаточно просто восстановить серверы и данные. Если при переносе инфраструктуры изменятся IP-адреса, маршруты или точки подключения, а новые параметры не будут своевременно учтены в белых списках, технически восстановленная система может остаться недоступной для пользователей. Поэтому механизмы аварийного восстановления необходимо предусматривать и на уровне сетевых разрешений», — предупреждает он.

github тоже шейпить начали Прыгает вокруг 50

По чатам вижу сообщения, что опять начали "давить" mtproto, скорость резко упала на download/upload. У вас как? 👍 - всё как и было 👎 - вчера-сегодня стало хуже 🤡- я не интересуюсь тем что происходит и без понятия в чём вопрос Из новостей интранета: вчера google.ru выпадал из жизни

домен google.ru был снят с делегирования 2026-10-14 00:23:01, и делегирован обратно через 10 часов - 2026-10-14 10:23:01 делегирование снял именно регистратор: сам по ошибке, администратором домена (пользователем) или по требованию органов/приставов/компетентной организации.

https://t.me/DOFH_ru/4477?comment=10072 Я по-прежнему вижу формирование "расширенных белых списков" и тестирование прочих ограничений для построения безопасного интранета, о чём писал ещё в июне

Когда режется кусок CDN, если шума нет, то значит и хорошо. Если шум есть, то добавляем конкретный ресурс в исключения и идём дальше. И так постепенно будет набиваться "база" необходимых "белых" ресурсов. Тут будет проблема, когда ресурс динамически "катается" по диапазонам или есть переезд ресурса, но кого это волнует? 🌝

https://t.me/tech_b0lt_Genona/6561?comment=45552 За безопасность респект, реально ощущаю что стало лучше и безопасней.

Началась трансляция митапа https://rutube.ru/video/private/d6aa9f0b781bd7c36eb1fd5495123b1c/?p=2-CyiotIZMaAhSoQ_kupfA Аппаратная безопасность https://ib.bmstu.ru/events/conf-15_10_2026/ То что для себя отметил - «Автоматизированное тестирование аппаратных средств на соответствие требованиям безопасности: тестовый фреймворк на основе HW CWE для устройств с архитектурой системы команд RISC-V» - «Статический анализ описаний аппаратуры (RTL): теория и практика» - «Режим безопасных вычислений платформы Эльбрус: дескрипторы и теги»

Продолжаем четверг! Если, что я совсем не против закрытых и/или коммерческих проектов от подписчиков Первое что приходит на ум из того что уже было, это плагин от Антона https://t.me/tech_b0lt_Genona/5468 За развитием этого проекта я наблюдал в одном из чатов и рад, что у Сергея что-то хорошее получилось в итоге. Слово автору @ozeranskii --- Всем привет! Я запустил tempus.build - Managed Runners для GitHub Actions! Решал свою боль с высокой стоимостью раннеров и в итоге оформил это в полноценный продукт: с панелью, аналитикой, AI и оплатой и на bare-metal. Мне нравится то, что получилось. И уже нравится еще нескольким командам, которые уже начали его использовать. Сейчас доступно два размера раннеров: - tempus-ubuntu-24.04-2core: замена ubuntu-latest 1:1 по размеру (хорошо для линтеров и простых джоб) - tempus-ubuntu-24.04-4core: для тяжёлых сборок и тестов, вдвое больше vCPU После подключения GitHub-организации к tempus.build на баланс сразу придут $5. Этого хватит, чтобы спокойно попробовать раннеры на своих реальных пайплайнах: это ~625 минут на 4-ядерном раннере. Оплата посекундная: короткий джоб на 20 секунд стоит 20 секунд, а не целую минуту, как у GitHub. Поэтому на практике $5 хватает даже на больше джобов, чем кажется по минутам. Платить можно в рублях или в любой другой мировой валюте. Закрывающие документы оформим в нужной вам юрисдикции, так что бухгалтерия будет довольна. Как начать: • Войдите в app.tempus.build через GitHub. • Установите GitHub App на свою организацию. • Поменяйте одну строку в workflow: runs-on: tempus-ubuntu-24.04-4core Если есть вопросы или предложения, пишите мне: @ozeranskii. Отвечу всем, и, поверьте, почти всё обсуждаемо и решаемо. Например: • хотите крутить раннеры на своём железе, но с моим control plane? Ок • нужно выделенное железо у меня с гарантированным числом прогретых под вас раннеров? Ок • нужны другие размеры/платформы раннеров? Тоже ок Сделаю все, чтобы вам было удобно 😊 И честно: сейчас рост продукта упирается в число платящих клиентов и мой личный бюджет на железо. Поэтому каждая команда, которая пользуется tempus.build, напрямую помогает ему расти. Больше железа означает, что ваши пайплайны станут еще быстрее, чем сейчас, но при этом дешевле. Сайт: https://tempus.build/ ---

Есть, значит, в мире такая проблема, как получение SBOM-а для C/C++ проектов. Проблема эта понятно связана с тем, что у таких проектов нет какого-то одного (да даже нескольких) места откуда взять надёжно информацию о зависимостях, которые как-то используются в проекте. Частично я эту проблему поднимал в своём докладе на NeoQUEST в прошлом году https://t.me/tech_b0lt_Genona/5727 На Хабре вышла статья от ребят из CodeScoring в конце сентября, но почитать только сейчас добрался вдумчиво. Пост большой, я оставлю у себя только важные, на мой взгляд, моменты. Код, пот и слезы: композиционный анализ проектов на С/С++ https://habr.com/ru/companies/codescoring/articles/1086376/

Установить название и версию библиотеки проще, если её добавили через пакетный менеджер, который сохранил эти сведения. При этом менеджеры зависимостей проекта и системных пакетов хранят данные о разных частях окружения. Conan и vcpkg управляют зависимостями конкретного C/C++ проекта, а системные менеджеры вроде apt или dnf устанавливают программы и библиотеки в операционную систему. Например, в Debian и Ubuntu сведения об установленных файлах хранятся в базе dpkg, а системы семейства RPM используют базу RPM. По такой базе файл можно связать с пакетом и его версией. Базы dpkg и RPM помогают, если библиотеку установили через системный пакетный менеджер. Для ранее собранной библиотеки связь с исходным проектом, версией и набором патчей приходится сохранять вместе с артефактом. Сам формат статического архива или динамической библиотеки не предъявляет требования к наличии этих сведений. При включении сторонних исходников и header‑only библиотек отдельного артефакта может вообще не быть. Происхождение такого кода приходится устанавливать по исходникам и данным сборки. Поскольку g++ может выполнять и компиляцию, и линковку, то при разборе сборки приходится смотреть на аргументы вызова. Сборочная система передаёт инструментам пути, параметры и порядок действий. ... Для SBOM конкретного релиза нужно не только установить происхождение библиотек, но и выяснить, какие из них вошли в поставку. Наличие библиотеки в сборочном окружении ещё не означает, что она используется в выпускаемом приложении. При сборке через Make или CMake без менеджера зависимостей библиотеки могут приходить из системных пакетов, каталогов с исходниками и других пайплайнов. Какие из них понадобятся для конкретного выпуска — зависит от операционной системы, параметров компиляции и выбранных целей сборки. ... Что же делать? ... При статической линковке линковщик извлекает из архива объектные файлы, необходимые для разрешения символов, и включает их в компоновку. Сам архив после сборки для запуска не нужен. Динамическую библиотеку выбирает динамический загрузчик с учётом путей поиска и настроек среды исполнения. Поэтому при запуске приложение может получить иную совместимую версию библиотеки, нежели та которая была доступна в системе сборки. Отсюда возникают два вида инвентаря и соответственно два SBOM. Build‑time фиксирует сведения, собранные во время компиляции и линковки конкретного выпуска, включая использованные статические библиотеки, выбранные цели и наблюдавшиеся команды. Runtime исследует уже запущенное приложение и показывает динамические библиотеки, доступные ему в конкретной среде. Два разных SBOM отвечают на разные вопросы. Первый объясняет, из чего собрали артефакт, а второй показывает, с чем он фактически запускается. Свести два списка бывает сложнее, чем получить их по отдельности, но попытка заменить один другим почти гарантированно оставит слепую зону. В итоге приходится отдельно инвентаризировать сборку и среду исполнения, а затем сопоставлять результаты. ... Куда движется практика Сведения о происхождении библиотек надёжнее сохранять при сборке, пока известны исходники, версии и внесённые изменения. Если след сборки уже потерян, инструменты вынуждены расширять анализ готового результата. После этого остаётся связать полученный SBOM с конкретным выпуском. Открытые проекты развивают эти направления независимо, поэтому их результаты пока приходится сводить. Например, чтобы сохранить происхождение до его потери, проект BOMsh наблюдает команды сборки и для каждого выходного файла записывает входные файлы, команду и хеши. OmniBOR соединяет такие записи в дерево происхождения, или provenance, по которому можно пройти от готовой программы к участвовавшим в её создании артефактам. Однако provenance ещё не равен SBOM. Разработчики BOMsh предупреждают, что конфигурационные проверки, тесты и подготовка инструментов порождают дополнительные записи, которые трудно отличить от сборки поставляемого продукта. Историю приходится сокращать, а файлам всё равно назначать имена и версии компонентов. Если полноценный след сборки уже потерян, то инструменты расширяют поверхность поиска. cdxgen объединяет данные из манифестов, исходников, контейнерных образов и бинарных файлов, а CVE Binary Tool ищет узнаваемые признаки библиотек в готовых файлах. После сборки SBOM можно связать с конкретным артефактом аттестацией. Например, Syft выпускает CycloneDX и SPDX и умеет создавать подписанные аттестации in‑toto. Такая запись связывает хеш артефакта с SBOM и указывает, кто сформировал документ. Подпись подтверждает автора и целостность утверждения, но не исправляет ошибочную атрибуцию внутри SBOM. Ценность аттестации скорее в том, что перечень компонентов перестаёт быть отдельным файлом неизвестного происхождения и входит в проверяемую историю релиза продукта.

Доклад с FOSDEM в эту же тему LibreOffice and Collabora Online - how we managed to automate SBOM generation for a large legacy project https://archive.fosdem.org/2026/schedule/event/TMFSBD-sboms-for-collabora-online/

Четверг, а значит время проектов от подписчиков! 🌝 Тем, кто пропустил, что такое четверговые проекты от подписчиков, можно прочитать тут - https://t.me/tech_b0lt_Genona/4983 Сегодня у нас редкий гость рубрики - подкаст! Тимура знаю уже достаточно давно, пусть и виртуально. Тимур прекрасен! Слово автору @tym83 --- Всем привет! Месяц назад вместе с Артемом, Юлей и Сергеем мы запустили Kubernetes Community Podcast. В нем мы рассуждаем о будущем оркестратора, приглашаем интересных гостей, разбираем глубокие технические вопросы, связь софта и железа, методы дебага проблем, интересные и неожиданные кейсы из практики. Например, как белка устроила гнездо в коаксиальном кабеле, поломав спутниковую связь, почему 5G это скорее маркетинг, чем реальность, и когда выгоднее вложиться в яблочный ПК, чем покупать сервер с зелеными GPU. На сегодня вышло уже четыре выпуска: 🌟👽 Микроволновка против спутника, в DevOps в 34 и бельчата с Александром Крючковым 📡 K8s внутри 5G, edge без BMC, любовь к VMware и KubeVirt с Иваном Екимовым 📉 Что не так с AI: $200 подписка, 72 млн стойка, ноль прибыли с Эдгаром Сипкой ☸️ Каким бы стал Kubernetes, если бы его разработали сегодня Ведущие: Артем Горячев, Kubestronaut Юлия Брунер, DevOps-инженер и автор канала @devops413 Сергей Фролов, DevOps-инженер и Open Source-контрибьютор Тимур Тукаев, по вечерам трогает Cozystack Подкаст делается полностью на энтузиазме и не преследует никаких коммерческих целей:) Послушать и посмотреть: - Apple Podcast - Mave - Яндекс Музыка - YouTube - Spotify ---

«Ростелеком» призвал создать дата-центры «судного дня» в России https://www.rosbalt.ru/news/2026-10-14/zampred-rostelekoma-prizval-sozdat-data-tsentry-sudnogo-dnya-5707218

Заместитель президента-председателя правления «Ростелекома» Валерий Ермаков заявил о необходимости создания ЦОД «судного дня» — резервной площадки, которая позволит восстанавливать работу сервисов при сбоях. Об этом он сообщил на форуме РБК Tech. «Это такая площадка бэкапов, в которой в случае чего вы всегда можете восстановить свои сервисы. Это действительно было невозможно представить какое-то время назад, но сейчас это прям реальная потребность», — сказал Ермаков. По его словам, резервные копии позволяют поставщикам услуг быстро восстанавливать работу. Ермаков отметил, что модели угроз стремительно меняются: то, что ранее считалось невозможным, становится реальностью и требует оперативного реагирования. В числе рисков он упомянул угрозы, связанные с беспилотниками. По оценке Ермакова, ранее инфраструктура крупных компаний строилась прежде всего с расчетом на экономическую эффективность и централизацию: ключевые сервисы концентрировались на нескольких площадках. Это давало преимущества в затратах и управлении, однако теперь такая концентрация стала уязвимостью.

Если что, то я с ним согласен. Надеюсь, что бекапы Госуслуг и други ГИС будут храниться именно в таких ЦОДах. Такие ЦОДы уже существуют в других странах. Например, есть в Швейцарии и спроектирован так, чтобы выдержать ядерный удар Swiss Fort Knox: Europe’s safest data center https://mount10.ch/en/about-us/swiss-fort-knox/ Вообще, вот статья, которая посвящена этой теме Top 10 underground data centres https://datacentremagazine.com/data-centres/top-10-underground-data-centres

Когда вы ропщете на регуляторику, всякие проверки и "комплаенсы", то просто вспоминайте о подобных новостях

Хакер получил доступ к Центральному реестру физических лиц Дании через аккаунт небольшой компании Pays ApS с паролем «123456». За десять дней он выгрузил имена и адреса 8,8 млн человек. Анонимный хакер взял на себя ответственность за крупнейшую утечку из Центрального реестра физических лиц Дании. Он рассказал газете Politiken, что вошел в систему с паролем «123456», передает агентство Ritzau. По словам злоумышленника, пароль он получил от бывшего сотрудника компании, у которой был законный доступ к реестру. Этой компанией оказалась Pays ApS из Оденсе на острове Фюн. Ей принадлежит сервис StopSvindel, а доступ к реестру ей выдали для проверки данных. Как пишет датское издание Ingeniøren, простой пароль защищал как минимум три учетные записи фирмы, включая администраторскую. По данным Cybernews, на июль 2026 года в Pays ApS числились всего два сотрудника.

https://hi-tech.mail.ru/news/157869-parol-123456-otkryl-hakeru-dannye-8-8-mln-chelovek-iz/ World’s worst password “123456” linked to breach of 8.8M Danes https://cybernews.com/security/denmark-cpr-data-breach-weak-password/

🦀 В Rust нашли баг, который 11 лет обходил гарантии безопасности памяти. Ошибка позволяет нарушить ограничения времени жизни при присваивании полю структуры. В результате код без `unsafe` может сохранить ссылку на уже уничтоженные данные, а затем обратиться к ним. В issue есть примеры чтения освобождённой памяти и падения программы. Один из них воспроизводится начиная с Rust 1.4. Разработчики присвоили ошибке высокий приоритет `P-high`. По оценке команды, случайное проявление маловероятно: для показанного нарушения безопасности нужна специально сконструированная реализация Drop. Комментарии ограничили, чтобы предотвратить спам и бесполезные обсуждения. Гарантии Rust тоже зависят от корректности компилятора. Здесь нашли дыру именно в их реализации. https://github.com/rust-lang/rust/issues/164250

Безумие продолжается. За последние сутки релизнули эксплоит гипервизора PS5. Взлом высшего оплота безопасности. Для понимания прошивка ps5 построена на ядре FreeBSD, а запускается и работает она внутри гипервизора. Сейчас цепочка эксплойтов позволяет выйти из юзерспейса (WebKit) --> потом ядро --> потом гипервизор. Получив доступ к гипервизору можно получить низкоуровневый доступ к системе. Появляется возможность запускать Linux и скомпрометировать ключи для подписи устанавливаемых пакетов. Сейчас вся цепочка оказалась подконтрольной энтузиастам, которое то и дело запускают на плойке что-нибудь необычное. Playden-ps5 - позволяет нативно запустить Steam и превратить PS5 в начтоящую StreamMachine. rpcs3-PS5 - эмуляция PS3 на PS5, пока что нужно собирать из исходников, проверил работает. pLinux5-NG - буквально только что портировали Linux на PS5 PS5LM - нативные LLM и QWEN на PS5 со скоростью 20 токенов в секунду PS5 становится очень интересной коробкой для запуска всего и вся. Как минимум буду использовать ее как docker-хост для сборки чего мой старенький MacBook на M1 не вытягивает. Как максимум запустить на ней полноценный кубер и Cozystack. Начал с малого, в качестве эксперимента портировал SyobonAction под PS5

Хронология перехода Минцифры на сайт национального удостоверяющего центра: 🔹GlobalSign 🔹HARICA 🔹Let's Encrypt 🔹LiteSSL (TrustAsia) Вы находитесь здесь 🔹НУЦ 3 августа LiteSSL уже отметился массовым отзывом сертификатов из-за санкций.