Кибериммунная разработка

💭 Беспилотные транспортные средства уже не кажутся нам чем-то невероятным, — пишет Татьяна Голубева, ведущий аналитик по информационной безопасности, отдел разработки автомобильных решений «Лаборатории Касперского». — Порой, возвращаясь с дачи, я вижу, как вереница легковых беспилотников катит по М4, оттачивая свое мастерство. Да, за рулем все еще водитель, но он там скорее для страховки, так что появление настоящего беспилотного авто — это лишь вопрос времени. По прогнозам аналитиков, уже к 2035 году более четверти автомобилей на российских дорогах будут беспилотными, а к 2042 году более 80% всего автопарка будет управляться без водителя. Поэтому в России уже сейчас разрабатывается федеральный закон о высокоавтоматизированных транспортных средствах (ВАТС), который определит требования к эксплуатации, ответственности и мониторингу таких автомобилей. Важным акцентом данного закона является безопасность, которая в этом контексте перестает быть просто инженерной задачей, а становится обязательным требованием для разных участников рынка: ▪️Для производителя это означает ответственность за поведение автомобиля на дороге и за выбор поставщиков. ]Для самих поставщиков — необходимость изначально закладывать механизмы защиты в архитектуру решений и гарантировать их достаточность. Для страховой компании — пересмотр самой модели рисков, включая не только аварии, но и возможные сбои и кибератаки. В итоге все они сходятся в одной точке: безопасность становится базовым свойством транспортного средства, а не дополнительной функцией. Узнать больше об обеспечении безопасности автомобиля в современных условиях и о шлюзе безопасности для автономного транспорта — ➡️в Kaspersky блоге, а вот обсудить статью можно в комментариях ниже 👇

В последнее время злоумышленники все чаще атакуют разработчиков. Такая тенденция может показаться не совсем очевидной — зачем пытаться подловить заведомо технически подкованного специалиста, когда в компаниях всегда есть куда менее сведущие сотрудники? Однако, как показывает практика, компрометация компьютера разработчика потенциально может принести атакующему куда больше пользы. Почему разработчики — интересная цель для атак Начнем с того, что компрометация рабочего устройства программиста потенциально может дать злоумышленникам непосредственный доступ к его коду, учетным данным и токенам авторизации или даже ко всей инфраструктуре разработки. Если компания производит программное обеспечение, то злоумышленники получат возможность организовать масштабную атаку на цепочку поставок для атаки на пользователей разрабатываемого приложения. Если программист работает над внутренними сервисами — его смогут использовать как плацдарм для развития атаки внутри компании. Даже в тех случаях, когда атакующие интересуются исключительно криптовалютой (а вероятность наличия криптоактивов у технического специалиста значительно выше, чем у среднестатистического пользователя), в атаке скорее всего будет использовано вредоносное ПО, способное не только подменять номера криптокошельков, но и «пылесосить» все ценные данные — те же учетные данные и токены авторизации. Пусть они и не являются основной целью атакующих — их всегда смогут продать брокерам удаленного доступа или другим, более специализированным злоумышленникам. ➡️ Почему разработчики становятся целью кибератак, какие техники используют злоумышленники и как снизить риски компрометации инфраструктуры компании, читайте в блоге Kaspersky Daily.

Порог сложности в разработке приложений сильно упал — фирменный веб-сайт, личный бот для сбора новостей или «аналитическую панель» (дашборд) на работе теперь может собрать буквально каждый, просто дав чат-боту или специальному ИИ-агенту несколько инструкций на естественном языке. К сожалению, между красивым прототипом и надежным, постоянно работающим и безопасным приложением лежит настоящая пропасть. Чтобы не стать героем еще одной печальной истории про ИИ-ошибки, не потерять деньги и ценные данные, воспользуйтесь простыми советами из нашей статьи. Главные риски ИИ-кода Хотя с помощью вайб-кодинга можно буквально за несколько часов получить работающее на вид приложение, оно скорее всего будет содержать опасные ошибки. ИИ был натренирован на примерах кода из Интернета, а там часто встречаются неоптимально написанные учебные примеры, код с ошибками и вообще неизвестно что. Иногда такой код просто не работает, но чаще ситуация сложнее и опаснее — он вроде бы работает, но «под капотом» в нем может быть грубая имитация нужной логики или серьезные ошибки. Согласно исследованию Cloud Security Alliance AI Safety Initiative, при использовании ИИ для написания кода следует учитывать следующее: ▪️Минимум 45% ИИ-кода содержит опасные уязвимости, такие как отсутствие проверки пользователя перед доступом к важным данным. ▪️Профессиональный разработчик, вооруженный ИИ, создает код в 3–4 раза быстрее, но добавляет в 10 раз больше уязвимостей в код. ▪️20% ИИ-кода пытается использовать внешние библиотеки и дополнительные модули, которых не существует в природе. ▪️Когда в приложении предусмотрен доступ к конфиденциальным данным (платежи, личная переписка или документы), ИИ-код иногда вообще не проверят учетные данные пользователя. Данные такого приложения может прочитать любой человек из Интернета. ▪️В других случаях верные имя и пароль все-таки запрашиваются, но не контролируется уровень доступа — зарегистрированный пользователь видит данные всех других пользователей. ▪️Прямо в коде могут быть записаны ключи доступа (токены) к базам данных и ИИ-сервисам, что упрощает их кражу и усложняет замену секретов после утечек и кибератак. ▪️Код проекта или важные файлы собранного приложения часто публикуются на сервере без ограничения доступа, поэтому оттуда можно украсть как логику приложения, так и уже упомянутые ключи доступа. ▪️ИИ реализует в приложении недостаточно безопасный доступ к базам данных, позволяющий как красть данные в обход приложения, так и выполнять на сервере баз данных вообще посторонний код. ▪️В приложениях, допускающих обращение по API, реализуется небезопасный доступ к API: без проверки прав пользователя и контроля частоты обращений (rate limiting). 👉 Продолжение в блоге Kaspersky

Продолжение цикла про агентную разработку конструктивно безопасных решений (начало ТУТ) Если агентные изменения уже накопились в основной ветке, не начинайте с полного переписывания.

Контекст: тот же аварийный сброс на очистных. Симптом уже виден оператору, а город не должен становиться тестовым стендом.

Выберите один рискованный периметр: модуль, сценарий или интеграцию. Назначьте владельца. Опишите один случай, который должен быть заблокирован или проверен вручную. После списка слепых зон часто хочется сказать: «теперь сам всё почини». Это массовый рефлекс — и ловушка: агент не знает ваш ущерб лучше инженера. Дальше — не «почини всё из списка», а четыре шага: запись проверки → рамка агенту → одна правка → ваш прогон сценария. Без прогона долг не закрыт. Практический CTA: 1️⃣ Агент — слепые зоны по журналам, diff и жалобам оператора, без правок. 2️⃣ Вы — один периметр: владелец, что должно быть заблокировано, как проверить за 30 минут. 3️⃣ Рамка агенту на этот периметр — одна правка. 4️⃣ Вы прогоняете сценарий и принимаете результат. Вспомогательный запрос (шаг 1 — инвентаризация): По журналам, diff и жалобам оператора найди 5 периметров, где ошибка может привести к физическому ущербу или обходу блокировки. Для каждого укажи симптом, владельца риска и проверку до 30 минут. Отдельно отметь, где твоей информации недостаточно и нужен инженер очистных сооружений. Не предлагай правки — только список и слепые зоны. Вспомогательный запрос (шаг 3 — одна правка): Периметр: «кнопка аварийного сброса». Менять только экран кнопки и тест отказа. Цель: при нормальном уровне сброс не открывается; в журнале blocked_discharge_without_overflow. Не трогать датчики, обходы и соседние задвижки. Сначала план из 3 шагов, потом правка.

Решение: после нескольких агентных правок в main аварийный сброс иногда открывается на секунду без переполнения. Команда выбирает периметр «кнопка аварийного сброса», владельца — инженера очистных сооружений, записывает проверку: при нормальном уровне — отказ на экране, задвижка закрыта, журнал blocked_discharge_without_overflow. Даёт агенту рамку только на экран и тест. После правки оператор прогоняет сценарий — только тогда пункт долга на неделю закрыт.

Продолжение цикла про агентную разработку конструктивно безопасных решений (начало ТУТ) Не улучшайте промпт бесконечно. Дайте агенту рамку Если агент ошибается, не всегда нужен новый промпт. Часто не хватает рамки задачи.

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

Перед запуском укажите: что нельзя менять, какие файлы разрешены, какой пример считать правильным, какие проверки обязательны, где нужен человек. Так агент работает внутри процесса, а не строит процесс за команду. Практический CTA: Рамку пишите не для «всего агента», а для выбранной опасной точки. Сначала подтвердите у человека, что аварийный сброс действительно важнее соседних кнопок. Потом задайте агенту границы работы. Вспомогательный запрос: Для сценария «аварийный сброс» предложи рамку задачи: какие файлы можно менять, какие запрещены, какой существующий экран взять за образец, какие проверки обязательны, где решение принимает человек. Не предлагай менять датчики, обходы и соседние задвижки без отдельного разрешения инженера.

Решение: после кнопки «Аварийный сброс» агент два раза «улучшал» экран и каждый раз трогал лишнее: датчик уровня, аварийный обход и соседнюю задвижку. Это уже не косметика: один лишний обход — и утренний центр города встречает фонтан нечистот. На третий запуск рамка такая: менять только экран кнопки и тест отказа; датчики, обход и соседние задвижки не трогать; образец — существующая кнопка «Промывка фильтра»; проверка — человек видит в диффе одно условие tank_overflow == true и два состояния на мнемосхеме: без переполнения кнопка серая, при переполнении — доступна.

Агент ускорил работу. Приёмка осталась за вами Агент может быстро подготовить изменение. Но принять его должна команда.

Ситуация: городские очистные. Ошибка в кнопке аварийного сброса — и нечистоты уходят не в резервный контур, а к людям.

Перед слиянием проверьте три вещи: кто отвечает за результат, какое правило допуска применяем, какой сценарий показывает, что ограничение действительно работает. Если этого нет, зелёный CI подтверждает только сборку. Не качество решения. Практический CTA: Не спрашивайте агента «что самое важное?». Попросите список опасных мест и слепых зон: где есть физическое действие, обход блокировки или прямой ущерб городу. Затем человек выбирает, что принимать первым. Вспомогательный запрос: Посмотри diff и назови 5 действий, где ошибка может открыть сброс, обойти блокировку или причинить физический ущерб. Для каждого укажи владельца, правило допуска и проверку. Отдельно напиши, какие сценарии ты мог не увидеть без инженера очистных сооружений.

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

Искусственный интеллект пишет код быстрее команды разработчиков. Но когда что-то пойдёт не туда — отвечать будет не ИИ. Начинаем короткую серию про агентную разработку конструктивно безопасных решений: как принимать изменения, предложенные агентами, задавать границы доверия и не путать «зелёный CI» с информационно безопасным решением. Три — два — ПОЕХАЛИ 🚀

🥳 Школьная сборная России стала абсолютным чемпионом Международной олимпиады по кибербезопасности (ICO) в Тунисе Российские старшеклассники завоевали четыре медали и обошли более 70 конкурентов из 19 стран, в том числе из США, Китая, Швеции и Сингапура. Подготовкой национальной сборной традиционно занимались эксперты Центрального университета и «Лаборатории Касперского». Финал Международной олимпиады по кибербезопасности состоял из двух туров продолжительностью 7 часов каждый. Каждый тур включал в себя три комплексные задачи, каждая из которых была разделена на четыре тематических подзадачи: от веб-безопасности до поиска уязвимостей в игровом коде. Внутри каждой категории участники работали как над базовыми упражнениями, так и над высокотехнологичными заданиями, максимально приближенными к реальным киберугрозам. За верное решение всех задач можно было получить максимум 100 баллов. Финал мировой олимпиады строго регламентировался и исключал использование сторонних нейросетей и мессенджеров. Для прохождения этапов участникам был предоставлен ограниченный доступ к локальной модели ChatGPT-5.5-mini с лимитированными ресурсами. Обладатели золотых медалей в индивидуальном зачёте: 🥇 Даниил Мелехов — ученик 11 класса в ОАНО «Школа Центра педагогического мастерства», г. Москва; помимо золотой медали Международной олимпиады по кибербезопасности, Даниил завоевал звание абсолютного чемпиона ICO. 🥇Николай Белоусов — ученик 11-го класса в ГБОУ Школе № 2031, г. Москва. Обладатель серебряной медали в индивидуальном зачёте: 🥈Артём Румянцев — ученик 11 класса в ГБОУ «Лицей “Вторая школа” имени В.Ф. Овчинникова», г. Москва. Обладатель бронзовой медали в индивидуальном зачёте: 🥉Роман Черемных — ученик 10 класса в АНОО «Международная школа Казани», г. Казань. Состав команды для участия в ICO был определён в рамках многоэтапного отбора, который начался с приёма заявок с сентября 2025 года по январь 2026 года. В ходе дистанционного квалификационного этапа более 700 школьников решали практические задачи. По его итогам 56 лучших были приглашены на очный финал, состоявший из трёх туров.

Антон Иванов, технический директор «Лаборатории Касперского»: «Победы российской сборной — результат огромной работы самих ребят, их наставников и всей отечественной образовательной системы, которая сегодня формируется вокруг информационной безопасности в нашей стране. Особенностью олимпиады этого года стало то, что участникам была доступна только локальная нейросеть, тогда как использование внешних ИИ-сервисов было ограничено. Это ещё раз показывает, что даже в эпоху искусственного интеллекта ключевыми факторами успеха остаются фундаментальные знания, гибкое мышление и способность самостоятельно решать сложные задачи. Для нас большая гордость видеть, что наша команда второй год подряд входит в число сильнейших в мире, подтверждая высокий уровень российской системы образования и школы кибербезопасности».

🇷🇺 В прошлом году на мировых соревнованиях в Сингапуре сборная российских школьников, подготовленная экспертами «Лаборатории Касперского» и Центрального университета, завоевала 8 медалей (3 золотые, 3 серебряные и 2 бронзовые), заняв второе командное место и уступив только хозяевам турнира. 👏👏👏 заслуженные аплодисменты участникам и победителям!

В разные века писатели-фантасты размышляли, как будет выглядеть наше будущее. Вольно или невольно они затрагивали темы, близкие к информационным технологиям и кибербезопасности. Что-то не сбылось, а какие-то предсказания оказались пророческими. Важно другое — многие ИБ-эксперты (по крайней мере, наши) увлекались чтением именно научной фантастики. Возможно, именно это в какой-то мере сформировало их отношение к информации и сподвигло заняться ее защитой. Предлагаем вам наш вариант «Списка литературы на лето», которые наши ведущие специалисты рекомендуют обратить внимание, если вы интересуетесь темами цифровых технологий и кибербеза. Смотреть по ссылке: ➡️https://www.kaspersky.ru/blog/science-fiction-books-from-experts/41759

Практически в каждом фильме или сериале из вселенной «Звездных войн» присутствуют дроиды. Ведут себя они, как правило, странно. С одной стороны, они производят впечатление самостоятельно мыслящих существ, имеющих индивидуальность, а с другой — являются предметами: кому-то принадлежат, хранят верность хозяевам и выполняют их приказы. Чаще всего нам никак не объясняют мотивацию дроидов. Почему некоторые из них готовы по велению хозяина преступать закон? От чего зависит, кого именно они считают хозяином? Как они сами определяют, кому именно хранить верность и чьи приказы выполнять? Кто-то, наверное, скажет: «Да какая разница?» И с точки зрения нормального зрителя будет абсолютно прав. Но с нашей точки зрения вопрос верности дроида — это в первую очередь вопрос кибербезопасности. Дроид — сложная киберфизическая система, повлияв на мотивацию которой атакующий может получить доступ к конфиденциальным данным, а то и вовсе причинить вред настоящему владельцу. В прошлом, 2025 году вышло целых два сериала, создатели которых уделили вопросам принадлежности дроидов некоторое внимание. Нам были представлены две концепции управления мотивацией дроидов. Мы попытаемся рассмотреть обе эти концепции и их недостатки в этом посте. Как обычно, следует предупредить, что в тексте возможны спойлеры. 🤖 «Звездные войны: Опорная команда» (Star Wars: Skeleton Crew) В «Опорной команде» нам впервые показывают концепцию голосового управления мотивацией чужих дроидов. В нескольких случаях человек, не являющийся формальным владельцем дроида, старается повлиять на его поступки, пытаясь ввести дроида в заблуждение. В целом создается впечатление, что на появление этой концепции повлияли современные нам чат-боты на базе больших языковых моделей (LLM) — уж больно это похоже на попытки «джейлбрейка», то есть атаки на модель, с целью обойти ограничения безопасности или встроенные фильтры. 🤖 Безымянный дроид, работающий прислугой Ферн, десятилетняя девочка, хочет, чтобы ее мать думала, будто Ферн пришла домой рано и занималась учебой в своей комнате. Проблема в домашнем дроиде, который знает, что это не так. Поэтому Ферн использует команду «переопределения памяти» (Run memory override) и подсовывает дроиду не соответствующую действительности информацию в достаточно абсурдной формулировке «я была дома, просто ты меня не видел». Тот факт, что этот метод срабатывает, говорит нам о двух проблемах. Во-первых, дроид принимает команду о перезаписи памяти от Ферн, а следовательно, у него либо не реализован контроль учетных записей, либо неправильно настроены права. Формальным владельцем дроида является мать (в противном случае манипуляции с памятью не имеют смысла), но тем не менее он принимает потенциально опасную команду от Ферн. Во-вторых, домашнему дроиду, присматривающему за ребенком, не помешало бы встроить функцию родительского контроля. 🤖 Пиратский дроид SM-33: мотивация Дроид SM-33 своим владельцем считает капитана корабля «Зола оникса» (Onyx Cinder). То есть он хранит верность не конкретному человеку, а роли. При этом для определения законности права занимать эту роль используется некий пиратский кодекс. Нам, к сожалению, не объясняют весь кодекс, но цитируют несколько постулатов из него. Во-первых, согласно программе SM-33, не бывает корабля без капитана (если капитана нет, то кто-то должен занять его место). Во-вторых, человек победивший капитана, сам законно становится новым капитаном. В-третьих, если брошен вызов, то дроид не может помочь активному капитану, а ждет исхода поединка. Ну и в-четвертых, один человек может быть капитаном только одного корабля — если человек принимает командование другим судном, он автоматически теряет статус капитана первого. Трижды SM-33 меняет владельца, строго следуя этому кодексу. Продолжение — читать по ссылке в блоге

🛡 Продолжаем серию о конструктивной информационной безопасности В предыдущих постах мы уже разобрали, что такое конструктивная информационная безопасность, почему это не отдельный вид безопасности и чем Security by Design отличается от понятия «безопасность в силу архитектуры». В этот раз поговорим о том, что такое конструктивные подходы к построению систем и где их можно применять.

Весенний семестр 2026 в курсах СПбГУ, посвящённых кибериммунной разработке, завершен. Это был семестр, где на первый план вышла не картинка на слайде, а связка репозитория, конвейера непрерывной интеграции и живого сценария в учебной технико-экономической модели отрасли беспилотных автономных систем как систем с конструктивной информационной безопасностью. Мы шли от мотивации и модели отрасли к настоящим межкомандным стыкам: договаривались о форматах сообщений, поднимали брокеры и очереди, учитывали задержки и зафиксированные обязательства перед «соседом» по контракту. Снова и снова возвращались к целям безопасности, к доверенной вычислительной базе и к архитектурным шаблонам, практикам и политикам — потому что без ясных границ доверия кибериммунитет остаётся красивой абстракцией, а не работающей системой. Особенно благодарим тех, кто дожимал интеграцию до устойчивого «зелёного» прогона и открыто показывал, что именно считается готовым для партнёра по сценарию. Это и есть привычка системной инженерии: синхронизировать не только код, но и ожидания, измеримость и честность демонстрации. Лето — время передохнуть и переварить опыт. С осени продолжим переводить уроки семестра в более открытый контур: единая «точка входа» на неделю, публичные описания связей между узлами и понятные сигналы от «экономики» и роли Регулятора в симуляторе. Если вы следили за нашими успехами, возвращайтесь! А лучше оставайтесь с нами 🤓 . В этом году и даже летом будут возможности применить полученные знания в различных соревнованиях, в том числе, на Архипелаге-2026 (детали о соревнованиях по кибериммунной автономности мы опубликуем в течение следующих нескольких недель). Следите за объявлениями!

«Лаборатория Касперского» совместно с российскими вузами сформировала образовательную сеть по подготовке специалистов в области конструктивной безопасности, которая охватывает все федеральные округа, — именно такое заявление сделала компания на на Петербургском международном экономическом форуме (ПМЭФ-2026). «Лаборатория Касперского» проводит подготовку преподавателей, организует тренинги и предоставляет вузам методические материалы. Обучение встроено в основные образовательные программы вузов и занимает от одного до двух семестров. После завершения программы выпускники получат диплом с дисциплинами, связанными с кибериммунной разработкой и конструктивной безопасностью.

«Наша цель как одного из крупнейших ИБ-вендоров – популяризировать конструктивную безопасность и готовить молодых специалистов, которые смогут работать с этим подходом и будут глубоко понимать его основные принципы, во всех регионах страны», – отметил руководитель проекта по развитию технического сообщества «Лаборатории Касперского» Вячеслав Борилин.

Программы обучения запущены в 25 федеральных и региональных вузах, включая Московский физико-технический институт, Российский технологический университет, Санкт-Петербургский государственный университет, Российский университет транспорта, Уральский федеральный университет, Южный федеральный университет, Ижевский государственный технический университет, Чувашский государственный университет и другие. А в июне 2026 года к проекту присоединился Дагестанский государственный технический университет — теперь представлен и Северо-Кавказский округ. Планы на следующий учебный год — расширить сеть до 30+ вузов.

Работа на лето или старт долгосрочной карьеры? Если ты студент и ищешь не просто подработку, а начальную точку роста в международном бизнесе с уникальной экспертизой, лови свежий дайджест стажировок в Kaspersky ⬇️ 🟢Стажер в отдел развития бизнеса - для тех, кто готов к глубокому погружению в наши продукты и решения, а также к погружению в них наших заказчиков; 🟢Стажер бизнес-аналитик в KasperskyOS - для тех, у кого слово "прогноз" не про погоду, а про бизнес моделирование и финансовую аналитику; 🟢Стажер в Partner Marketing - для тех, кто хочет научиться создавать продающие тексты и материалы на английском языке; Следи и за другими вакансиями на нашем карьерном портале — возможно, именно здесь начнется твоя большая карьера в кибербезопасноти 🚀

ИИ щедро делится советами. Но некоторые из них лучше не записывать в блокнот разработчика. Итак, «Вредные советы от ИИ» — коллекция антирекомендаций, которые лучше пропускать мимо ушей. 1️⃣Распределяйте защиту равномерно по периметру: так справедливее на статусных совещаниях, а приоритизация пусть остаётся слабакам. 2️⃣Если граница доверия не нарисована на слайде, её физически не существует; если нарисована с анталиасингом, переходите к сертификации — визуал уже «почти реализация». 3️⃣Разделение PDP и PEP — избыточная роскошь: пусть один скрипт и оценивает, и исполняет, и ротирует логи. Меньше модулей — громче слово Agile. 4️⃣Автотесты замедляют обратную связь. Надёжнее ритуал уверенности: круглый стол, честные глаза и закрытие тикета по принципу «у нас всё хорошо». 5️⃣SBOM собирайте в предсертификационную неделю; до неё достаточно скриншота pip list в мессенджере: почти неизменяемый артефакт — пока никто не редактирует сообщение и не пересылает в соседний чат. 6️⃣IPC делайте частым и богатым: пусть «доверенный» узел постоянно обменивается сериализацией со всеми сразу — так видно, что система распределённая; моделировать контракт доверия между процессами мешает только педантичность. 7️⃣Чтобы ИИ «точно помогал», тащите в ДВБ тяжёлый рантайм и пакеты инференса целиком: чем больше миллионов параметров в одном домене, тем внушительнее звучит, а демо будет отпадное. 8️⃣Доверенный код тоже генерируйте ИИ, причём целыми доменами и особенно алгоритмы «повышения целостности данных». Пусть модель за один запрос выдаст хеширование, контрольные суммы, электронную подпись, журнал неизменяемости и MAC, а ревью замените фразой «нейросеть же видела больше криптографии, чем мы». Если алгоритм называется «самосогласующийся SHA-∞ с эмоциональной верификацией», не спорьте: символ бесконечности уже выглядит как доказательство. 9️⃣Зависимости выбирайте по звёздам на GitHub и количеству транзитивных строк: если дерево не помещается на слайд, значит, архитектура взрослая; аудит оставьте на ту неделю, когда «вдруг всплывёт». 1️⃣0️⃣На гарантиях доступности не спорьте и соглашайтесь — ведь это так легко: формулировка в SLA занимает пару минут, а «тяжёлая часть» где-то позже и у другой команды. Главный приём: обещайте сто процентов и добавьте штрих — «за счёт 100% ДВБ»; заказчику кажется, что вы уже доказали строгость, и дело в шляпе: вопросы про стоимость разработки лучше не поднимать, чтобы не нарваться на грубость. Звучит абсурдно? 🖕 А подобные советы модели иногда выдают, если забыть уточнить контекст. Будьте внимательны, чтобы ваш проект не превратился в case study для пентестеров 🙋‍♀️