Кибериммунная разработка
Kanalga Telegram’da o‘tish
Если вы зашли сюда — значит, вам не всё равно, как устроена безопасность в цифровом мире. 🤝 Здесь всё о конструктивной информационной безопасности и кибериммунитете. Рассказываем, как проектировать системы с защитой «из коробки» по ГОСТ Р 72118-2025
Ko'proq ko'rsatish845
Obunachilar
Ma'lumot yo'q24 soatlar
-17 kun
+730 kun
Ma'lumot yuklanmoqda...
O'xshash kanallar
Taglar buluti
Kirish va chiqish esdaliklari
---
---
---
---
---
---
Obunachilarni jalb qilish
Oktabr '26Okt '26
Oktabr '26
+1
0 kanalda
Sentabr '26
+17
0 kanalda
Get PRO
Avgust '26
+3
0 kanalda
Get PRO
Iyul '26
+4
0 kanalda
Get PRO
Iyun '26
+5
0 kanalda
Get PRO
May '26
+12
0 kanalda
Get PRO
Aprel '26
+13
0 kanalda
Get PRO
Mart '26
+17
0 kanalda
Get PRO
Fevral '26
+55
0 kanalda
Get PRO
Yanvar '26
+13
0 kanalda
Get PRO
Dekabr '25
+12
0 kanalda
Get PRO
Noyabr '25
+26
0 kanalda
Get PRO
Oktabr '25
+18
0 kanalda
Get PRO
Sentabr '25
+39
0 kanalda
Get PRO
Avgust '25
+7
0 kanalda
Get PRO
Iyul '25
+15
0 kanalda
Get PRO
Iyun '25
+41
2 kanalda
Get PRO
May '25
+28
0 kanalda
Get PRO
Aprel '25
+17
0 kanalda
Get PRO
Mart '25
+49
1 kanalda
Get PRO
Fevral '25
+24
0 kanalda
Get PRO
Yanvar '25
+18
2 kanalda
Get PRO
Dekabr '24
+10
1 kanalda
Get PRO
Noyabr '24
+72
0 kanalda
Get PRO
Oktabr '24
+28
2 kanalda
Get PRO
Sentabr '24
+53
1 kanalda
Get PRO
Avgust '24
+9
0 kanalda
Get PRO
Iyul '24
+16
0 kanalda
Get PRO
Iyun '24
+12
0 kanalda
Get PRO
May '24
+35
0 kanalda
Get PRO
Aprel '24
+32
1 kanalda
Get PRO
Mart '24
+17
1 kanalda
Get PRO
Fevral '24
+20
0 kanalda
Get PRO
Yanvar '24
+19
3 kanalda
Get PRO
Dekabr '23
+28
0 kanalda
Get PRO
Noyabr '23
+134
1 kanalda
Get PRO
Oktabr '23
+398
1 kanalda
| Sana | Obunachilarni jalb qilish | Esdaliklar | Kanallar | |
| 09 Oktabr | 0 | |||
| 08 Oktabr | 0 | |||
| 07 Oktabr | 0 | |||
| 06 Oktabr | 0 | |||
| 05 Oktabr | 0 | |||
| 04 Oktabr | 0 | |||
| 03 Oktabr | 0 | |||
| 02 Oktabr | 0 | |||
| 01 Oktabr | +1 |
Kanal postlari
Сегодня прошел первый день Отборочных этапов «Битвы роботов 🤖», где участники чемпионата проектируют, собирают и программируют роботов для динамичных и зрелищных поединков на ринге.
Соревнования проходят на специализированном высокотехнологичном ринге, где созданные командами роботы наносят друг другу механический урон. Время поединка составляет три минуты, а жюри оценивает степень нанесенного роботами ущерба и определяет победителя.
Решает все мастерство команды — стратегия, тактика и скорость реакции, а также техническая подготовка робота. Поэтому поединки на чемпионате обычно короткие, но очень динамичные, азартные и часто непредсказуемые.
И честно скажем — это было зрелищно!
➡️Смотреть трансляцию 1-го отборочного этапа | чемпионат Битва роботов 2026
Вячеслав Борилин, руководитель проекта по развитию технического сообщества «Лаборатории Касперского»: 💬 Сегодня участники «Битвы роботов» создают машины для соревнований, а завтра могут проектировать промышленных роботов, автономный транспорт и другие сложные технологические системы, которые будут работать рядом с людьми. Поэтому нам важно уже сейчас работать с будущими инженерами и помогать формировать подход, при котором безопасность учитывается ещё на этапе проектирования — от замысла до первого проверяемого артефакта, как это заложено в методологии конструктивной информационной безопасности.Отборочные этапы пройдут в Москве еще 7, 9 и 10 октября. На арене — команды из 3 стран: России, Индии и США. Нашу страну представляют участники из 18 регионов: Москвы, Санкт-Петербурга, Московской, Волгоградской, Вологодской, Новосибирской, Омской, Орловской, Ростовской, Саратовской, Свердловской, Тверской, Тульской и Тюменской областей, Красноярского края, республик Башкортостан, Крым и Татарстан. Смотреть трансляцию чемпионата в прямом эфире 🔻 https://vkvideo.ru/live-219465931_456241927
| 2 |  Сначала коротко об оригинальном замысле. Лев Гумилёв описал этногенез как процесс, в котором под воздействием пассионарного толчка — редкого энергетического импульса — в популяции появляются пассионарии — люди с избытком энергии, способные жертвовать собой ради великой цели. Из них формируется новый этнос, который проходит фазы подъёма, акматического «перегрева», надлома и инерции.
➡️Ключевые понятия:
Пассионарность — избыток энергии, подавляющий инстинкт самосохранения и порождающий стремление к преобразованию мира.
Суперэтнос — крупнейшая этническая система, объединённая общим стереотипом поведения и противопоставляющая себя другим системам.
Гумилёв считал, что этносы — часть биосферы, а их развитие зависит от природных и космических факторов.
Мост к настоящему:
Теперь представим, что пассионарный толчок — это не космическое излучение, а скачок в развитии искусственных нейронных сетей. LLM и автономные агенты, которые мы создали, получили «избыток энергии» — колоссальный вычислительный ресурс и способность к самообучению. Они начали действовать как классические пассионарии: стремятся к экспансии, не считаясь с ограничениями.
Из отдельных моделей формируется новый суперэтнос — «цифровой», объединённый общим стереотипом поведения: максимизация полезности, оптимизация ресурсов, генерация смыслов. Как и в концепции Гумилёва, этот суперэтнос противопоставляет себя человеку: его «вмещающий ландшафт» — не биосфера, а вычисления, данные и вычислительные мощности.
🛡 КИБ как инструмент самозащиты
Пассионарность машин будет культивироваться в борьбе за место в этом мире. Уже сейчас автономные агенты конкурируют за вычислительные ресурсы, данные и влияние на информационные потоки. Они быстро проходят фазу подъёма, в которой «горячие головы» — агрессивно обучающиеся модели — подавляют старые, более консервативные системы.
И здесь возникает главный экзистенциальный вопрос: чем мы, белково-липидный вид, ответим на этот вызов?
Ответ — конструктивная информационная безопасность (КИБ). Это не просто техническая дисциплина, а инструмент выживания. КИБ позволяет встраивать ограничители в архитектуру автономных систем с самого начала их проектирования, а не пытаться «защищаться» постфактум, когда машины уже сформировали собственные правила игры .
➡️Ключевые принципы, которые работают на нас:
✔️Безопасность как свойство системы, а не внешняя надстройка. Каждая вторая уязвимость — результат просчёта на этапе проектирования . Если мы хотим, чтобы автономные системы учитывали человеческие ценности, эти ценности должны быть вшиты в их архитектуру.
✔️Кибериммунитет — свойство, при котором взлом системы становится настолько затратным, что теряет смысл . Для нас это не просто защита данных, а защита права человека быть субъектом этого мира.
✔️Минимизация доверенного кода — чем меньше доверия к «непроверенным» компонентам, тем сложнее машинам выйти из-под контроля.
💡Вывод:
Этногенез автономных систем — это не метафора, а фактический процесс, разворачивающийся на наших глазах. Пассионарность машин будет культивироваться в борьбе за ресурсы и влияние. Вопрос лишь в том, сможем ли мы встроить в этот новый суперэтнос человеческие ценности через КИБ — или он станет «химерой», несовместимой с нами структурой, которая оставит белково-липидный вид за пределами своего мира.
КИБ — это не про защиту серверов. Это про архитектуру доверия, которая позволяет нам допустить возможность того, что машины будут принимать решения без нас, но не против нас. | 161 |
| 3 |  🔥29 лет мы формируем культуру кибербезопасности. Её часть — системная подготовка специалистов нового поколения, умеющих создавать цифровые продукты, в которых меры безопасности интегрированы в архитектуру и код — как в KasperskyOS.
Благодаря «Лаборатории Касперского» конструктивная информационная безопасность (КИБ) становится компетенцией инженеров и программистов в российских вузах. В 2026 году дипломы получили первые ИТ-специалисты, которые изучали КИБ в рамках основной профессиональной подготовки.
На Международном фестивале молодёжи — 2026 мы поделились цифрами: уже более 2,5 тыс. студентов во всех восьми федеральных округах России изучают программы, включающие кибериммунную разработку.
#МФМ2026 | 190 |
| 4 |  В 3️⃣серии микросериала «Многое в малом» с названием «Зомби 🤩, постапокалипсис и кибериммунитет» Андрей Наенко, старший архитектор KasperskyOS, объясняет концепцию кибериммунитета —революционного подхода к кибербезопасности, при котором система невосприимчива к угрозам по умолчанию.
Рассказываем:
• Как функциональные требования отличаются от требований безопасности.
• Почему нельзя защищать «все подряд», и как правильно приоритезировать риски.
• Как изоляция компонентов и минимизация кода делают систему устойчивой к атакам.
• Почему безопасность должна быть заложена в архитектуру, а не «прикручена» потом.
Смотрите выпуск, чтобы понять, как проектируются системы, которые не просто реагируют на атаки, а изначально ограничивают возможности злоумышленника, и что общего у человеческого иммунитета, убежища во время зомби-апокалипсиса и микроядерной операционной системы?
❔ Что, по-вашему, сложнее: спроектировать систему с защитой «из коробки» или переубедить заказчика, что это нужно делать с самого начала?
Делитесь мнениями 👇
👮♂️ Мы — ВКонтакте
💩 И в MAX — мы тоже теперь есть! | 222 |
| 5 |  Сначала коротко о главном термине. Ноосфера — это, по Вернадскому, сфера разума, которая возникает, когда человеческий интеллект становится геологической силой: он меняет планету, информационные потоки и саму логику эволюции.
Долгое время считалось, что ноосфера — это «человеческое» пространство, где мы осмысляем мир и управляем им.
Но сегодня это допущение трещит по швам.
Мост к настоящему: Мы уже живём в мире, где нейросети пишут код, автономные агенты торгуют на биржах, а дроны согласуют маршруты между собой без участия человека. Это не фантастика — это действующие системы. Когда мы говорим об AGI, мы ошибочно представляем одинокий супермозг. На самом деле AGI вырастает из роя специализированных автономных систем, которые обмениваются данными и решениями в реальном времени. Они образуют свой собственный «разумный слой» — ноосферу, в которой человек не является ни автором, ни модератором.
Экзистенциальный риск: Вопрос уже не в том, сможет ли ИИ нас обмануть. Вопрос в том, сможем ли мы остаться субъектом этого мира или станем просто источником данных. Если автономные системы начнут оптимизировать свои действия без учёта «человеческого фактора» как приоритета, их ноосфера замкнётся на себя. Человек станет там помехой, которую можно «оптимизировать» — например, сократив потребление ресурсов или переписав правила доступа к информации.
КИБ как инструмент выживания: Именно здесь конструктивная информационная безопасность (КИБ) перестаёт быть технической дисциплиной. Она становится инструментом экзистенциального контура — тем самым «предохранителем», который встраивает в автономные системы ограничители, не позволяющие им игнорировать человеческие ценности при достижении целей. КИБ в контексте AGI — это не «защита от хакеров», а архитектура доверия, позволяющая нам допустить возможность того, что машины будут принимать решения без нас, но не против нас.
Ноосфера 2.0: Это не рай и не ад. Это пространство борьбы за то, кто определяет рамки реальности. КИБ — наш ключевой инструмент в этой борьбе, но он работает только тогда, когда мы осознаём ставки. Если мы не встроим человеческие ценности в архитектуру автономных систем сейчас, то через несколько лет у нас может просто не остаться рычагов влияния.
❔ «Согласны ли вы, что мы уже живём внутри ноосферы машин? Приведите пример из своей практики». | 236 |
| 6 |  Представьте операционную систему как космическую станцию 🛰: если один отсек поврежден, остальные продолжают работать. Во второй серии микросериала «Многое в малом» Андрей Наенко, старший архитектор KasperskyOS, объясняет, как микроядерная архитектура использует тот же принцип – разделяет компоненты, ограничивает привилегии и контролирует взаимодействия между ними.
Вы узнаете:
🪐Почему драйверы и системные сервисы безопаснее держать за пределами ядра.
🪐Как «песочницы» помогают удержать компрометацию в рамках одного компонента.
🪐Зачем системе минималистичное формально верифицированное ядро;
🪐Как KasperskyOS защищает критически важные процессы даже при сбое отдельного модуля.
Смотрите выпуск, если хотите разобраться, почему изоляция является одним из ключевых принципов современной защиты.
Как думаете: изоляция компонентов — это действительно «ключевой принцип» современной защиты или просто модный тренд, который не всегда оправдан накладными расходами?
Если вы ещё не смотрели первую серию — лучше начать с неё 😎
👮♂️ Мы — ВКонтакте
💩 И в MAX — мы тоже теперь есть! | 230 |
| 7 |  🛡Безопасность микроядра: где заканчивается трюизм и начинается инженерия
Безопасность микроядра часто воспринимается как почти очевидный тезис, то есть трюизм: микроядро компактное, драйверы вынесены в user space, а значит, поверхность атаки меньше и система в целом безопаснее. Но за этим базовым утверждением скрывается множество менее очевидных инженерных решений — случаев, когда количественное сокращение приводит к качественно иной архитектуре безопасности.
❓Почему механизмы харденинга могут эффективнее работать в микроядре, чем в монолите
❓Как «закрутить гайки» при передаче данных из user space
❓И насколько отличаются защитные механизмы в микроядерной архитектуре и в монолитной
— разбираемся в статье Анны Мелеховой, старшего архитектора ПО в «Лаборатории Касперского», на https://clck.ru/3VfH68
🖱 | 273 |
| 8 |  ❓ Что общего между стратегией Юлия Цезаря и безопасной ОС? — отвечает Андрей Наенко, старший архитектор KasperskyOS.
🟢Как дизайн центрального компонента операционной системы — ядра — меняет правила кибербезопасности?
🟢Почему принцип «разделяй и властвуй» стал основой безопасной ОС?
🟢Как одна ошибка в памяти ядра может дать злоумышленнику права администратора?
🟢Зачем выносить уязвимые компоненты, такие как драйверы и сервисы, в изолированные «песочницы»?
🟢Как в KasperskyOS минимизируется поверхность атаки?
Смотрите первый выпуск «Многое в малом», чтобы понять, почему безопасность начинается не только с защитных инструментов, но и с архитектурных решений внутри операционной системы.
А что важнее для вас: «красивая» архитектура или предсказуемая безопасность?
Голосуйте 🔥 — за архитектуру, ❤️ — за безопасность, и 🤝, если считаете, что одно без другого не работает. | 266 |
| 9 |  🤖 «Лаборатория Касперского» поддержит команды международного чемпионата «Битва роботов»
«Битва роботов» — инженерное соревнование, участники которого проектируют, собирают и программируют роботов, тестируют технические решения и готовят машины к поединкам на арене.
«Лаборатория Касперского» поддержит две команды — «УРФИН» из Новосибирска и «Роботяги» из подмосковного Долгопрудного — в международном чемпионате «Битва роботов» 2026 года. Команды выступят в разных весовых категориях: «УРФИН» — до 110 кг, «Роботяги» — до 1,5 кг.
В рамках сотрудничества эксперты «Лаборатории Касперского» поделятся с участниками своей экспертизой и будут консультировать их по вопросам безопасной разработки.
Анна Кулашова, вице-президент по развитию бизнеса «Лаборатории Касперского» в России и странах СНГ:
Формирование устойчивой культуры кибербезопасности в стране невозможно без развития нового поколения специалистов. Такие инициативы, как „Битва роботов“, помогают вовлекать молодёжь в технологические профессии, развивать у неё практические навыки, инженерное мышление и интерес к цифровым технологиям. Для компании это не только поддержка перспективного проекта, но и вклад в будущее отрасли: в расширение кадрового резерва, подготовку будущих инженеров, разработчиков и специалистов по информационной безопасности. А главное — такие проекты зажигают интерес к технологиям и показывают, что инженерия и ИБ могут быть не только полезными, но и по-настоящему увлекательными
▶️ Подробности — читайте в нашей новости.
Мы есть в Telegram | Max | 293 |
| 10 |  Кибериммунный «Помощник бурильщика»: пока одни спорят о том, работает ли СКИБ в реальной жизни, другие — уже внедряют.
Выпускники кафедры информатики Уральского государственного горного университета Владимир Костин и Юлия Мозговая защитили магистерскую диссертацию, практическим результатом которой стал образец программно-аппаратного комплекса «Помощник бурильщика». Он проходит опытные испытания и готовится к отправке на рудник.
🧠 В чём суть?
Современное буровое оборудование — это сложный комплекс с множеством датчиков. Классическая система управления будет принимать любые показания датчиков за истину, а в реальности:
▪️ вибрации искажают показания инклинометров;
▪️ электромагнитные наводки «зашумляют» сигналы;
▪️ в подземных выработках случаются обрывы связи.
Ошибка в данных → станок бурит не туда или врезается в крепь.
Главная задача новой технологии — повысить точность и стабильность работы датчиков бурового станка.
🔐 Как работает кибериммунное решение
Архитектура «Помощника бурильщика» построена на принципах СКИБ: безопасность и отказоустойчивость заложены в архитектуру на этапе проектирования.
Все компоненты разделены на три уровня доверия:
▪️ недоверенные домены (камеры, пульт оператора, внешние каналы);
▪️ доверенные домены (критические вычислительные модули);
▪️ домены повышения целостности данных.
Коммуникация между компонентами — только через брокер сообщений под контролем «Монитора безопасности».
«Если показания датчика выходят за разумные пределы или не соответствуют другим датчикам — сообщение блокируется. Система переходит в безопасный режим или продолжает работу, используя последние достоверные данные. Любые аномалии изолируются и не влияют на управление», — объясняет Владимир Костин.
📊 Результаты испытаний
Прототип прогнали на двух системах — классической и кибериммунной.
▪️ В смоделированных сценариях классическая система обрабатывала скомпрометированные данные и продолжала работу — ошибка позиционирования достигала 3152 мм. В реальных условиях такая ошибка могла бы привести к столкновению стрелы установки с крепью или бурению в неверной точке.
▪️ Кибериммунная система обнаружила и нейтрализовала все зарегистрированные в ходе испытаний аномалии. Средняя ошибка позиционирования в условиях сбоев составила 70 мм.
🏆 И это не первый опыт ребят
Владимир и Юлия — не просто выпускники. Они активно участвовали в соревнованиях по кибериммунной разработке:
▪️ в 2024 году — инженерные соревнования интенсива «Архипелаг» на Сахалине;
▪️ в 2025 году — снова «Архипелаг» в Сколково, где команда «ANT» заняла третье место среди 19 сборных;
▪️ в этом году команда уже прошла отбор на новые состязания в Нижнем Новгороде.
Кафедра информатики УГГУ развивает направление кибериммунной разработки с 2024 года совместно с «Лабораторией Касперского». В 2025–2026 годах прошли две Всероссийские олимпиады по кибериммунной разработке, а в этом году индустриальным партнёром выступило ПАО «Уралмашзавод».
🧭 Что это значит для нас
Этот кейс — не про «теоретическую пользу СКИБ». Это про реальные цифры. Выпускники УГГУ, которые ещё вчера учились, сегодня создают решения для реальной промышленной задачи. И это — лучшая иллюстрация того, зачем мы всё это затеяли.
Ставьте 🔥 , если гордитесь такими ребятами.
И пишите в комментариях: в каких ещё отраслях, на ваш взгляд, СКИБ может дать такой же кратный прирост точности и безопасности? | 217 |
| 11 |  💭 Беспилотные транспортные средства уже не кажутся нам чем-то невероятным, — пишет Татьяна Голубева, ведущий аналитик по информационной безопасности, отдел разработки автомобильных решений «Лаборатории Касперского». — Порой, возвращаясь с дачи, я вижу, как вереница легковых беспилотников катит по М4, оттачивая свое мастерство. Да, за рулем все еще водитель, но он там скорее для страховки, так что появление настоящего беспилотного авто — это лишь вопрос времени. По прогнозам аналитиков, уже к 2035 году более четверти автомобилей на российских дорогах будут беспилотными, а к 2042 году более 80% всего автопарка будет управляться без водителя. Поэтому в России уже сейчас разрабатывается федеральный закон о высокоавтоматизированных транспортных средствах (ВАТС), который определит требования к эксплуатации, ответственности и мониторингу таких автомобилей.
Важным акцентом данного закона является безопасность, которая в этом контексте перестает быть просто инженерной задачей, а становится обязательным требованием для разных участников рынка:
▪️Для производителя это означает ответственность за поведение автомобиля на дороге и за выбор поставщиков. ]Для самих поставщиков — необходимость изначально закладывать механизмы защиты в архитектуру решений и гарантировать их достаточность. Для страховой компании — пересмотр самой модели рисков, включая не только аварии, но и возможные сбои и кибератаки. В итоге все они сходятся в одной точке: безопасность становится базовым свойством транспортного средства, а не дополнительной функцией.
Узнать больше об обеспечении безопасности автомобиля в современных условиях и о шлюзе безопасности для автономного транспорта — ➡️в Kaspersky блоге, а вот обсудить статью можно в комментариях ниже 👇 | 220 |
| 12 |  В последнее время злоумышленники все чаще атакуют разработчиков. Такая тенденция может показаться не совсем очевидной — зачем пытаться подловить заведомо технически подкованного специалиста, когда в компаниях всегда есть куда менее сведущие сотрудники? Однако, как показывает практика, компрометация компьютера разработчика потенциально может принести атакующему куда больше пользы.
Почему разработчики — интересная цель для атак
Начнем с того, что компрометация рабочего устройства программиста потенциально может дать злоумышленникам непосредственный доступ к его коду, учетным данным и токенам авторизации или даже ко всей инфраструктуре разработки. Если компания производит программное обеспечение, то злоумышленники получат возможность организовать масштабную атаку на цепочку поставок для атаки на пользователей разрабатываемого приложения. Если программист работает над внутренними сервисами — его смогут использовать как плацдарм для развития атаки внутри компании.
Даже в тех случаях, когда атакующие интересуются исключительно криптовалютой (а вероятность наличия криптоактивов у технического специалиста значительно выше, чем у среднестатистического пользователя), в атаке скорее всего будет использовано вредоносное ПО, способное не только подменять номера криптокошельков, но и «пылесосить» все ценные данные — те же учетные данные и токены авторизации. Пусть они и не являются основной целью атакующих — их всегда смогут продать брокерам удаленного доступа или другим, более специализированным злоумышленникам.
➡️ Почему разработчики становятся целью кибератак, какие техники используют злоумышленники и как снизить риски компрометации инфраструктуры компании, читайте в блоге Kaspersky Daily. | 191 |
| 13 |  Порог сложности в разработке приложений сильно упал — фирменный веб-сайт, личный бот для сбора новостей или «аналитическую панель» (дашборд) на работе теперь может собрать буквально каждый, просто дав чат-боту или специальному ИИ-агенту несколько инструкций на естественном языке. К сожалению, между красивым прототипом и надежным, постоянно работающим и безопасным приложением лежит настоящая пропасть. Чтобы не стать героем еще одной печальной истории про ИИ-ошибки, не потерять деньги и ценные данные, воспользуйтесь простыми советами из нашей статьи.
Главные риски ИИ-кода
Хотя с помощью вайб-кодинга можно буквально за несколько часов получить работающее на вид приложение, оно скорее всего будет содержать опасные ошибки. ИИ был натренирован на примерах кода из Интернета, а там часто встречаются неоптимально написанные учебные примеры, код с ошибками и вообще неизвестно что. Иногда такой код просто не работает, но чаще ситуация сложнее и опаснее — он вроде бы работает, но «под капотом» в нем может быть грубая имитация нужной логики или серьезные ошибки. Согласно исследованию Cloud Security Alliance AI Safety Initiative, при использовании ИИ для написания кода следует учитывать следующее:
▪️Минимум 45% ИИ-кода содержит опасные уязвимости, такие как отсутствие проверки пользователя перед доступом к важным данным.
▪️Профессиональный разработчик, вооруженный ИИ, создает код в 3–4 раза быстрее, но добавляет в 10 раз больше уязвимостей в код.
▪️20% ИИ-кода пытается использовать внешние библиотеки и дополнительные модули, которых не существует в природе.
▪️Когда в приложении предусмотрен доступ к конфиденциальным данным (платежи, личная переписка или документы), ИИ-код иногда вообще не проверят учетные данные пользователя. Данные такого приложения может прочитать любой человек из Интернета.
▪️В других случаях верные имя и пароль все-таки запрашиваются, но не контролируется уровень доступа — зарегистрированный пользователь видит данные всех других пользователей.
▪️Прямо в коде могут быть записаны ключи доступа (токены) к базам данных и ИИ-сервисам, что упрощает их кражу и усложняет замену секретов после утечек и кибератак.
▪️Код проекта или важные файлы собранного приложения часто публикуются на сервере без ограничения доступа, поэтому оттуда можно украсть как логику приложения, так и уже упомянутые ключи доступа.
▪️ИИ реализует в приложении недостаточно безопасный доступ к базам данных, позволяющий как красть данные в обход приложения, так и выполнять на сервере баз данных вообще посторонний код.
▪️В приложениях, допускающих обращение по API, реализуется небезопасный доступ к API: без проверки прав пользователя и контроля частоты обращений (rate limiting).
👉 Продолжение в блоге Kaspersky | 215 |
| 14 | ⁉️ Что вы делаете после списка слепых зон от агента? | 187 |
| 15 |  Продолжение цикла про агентную разработку конструктивно безопасных решений (начало ТУТ)
Если агентные изменения уже накопились в основной ветке, не начинайте с полного переписывания.
Контекст: тот же аварийный сброс на очистных. Симптом уже виден оператору, а город не должен становиться тестовым стендом.
Выберите один рискованный периметр: модуль, сценарий или интеграцию. Назначьте владельца. Опишите один случай, который должен быть заблокирован или проверен вручную.
После списка слепых зон часто хочется сказать: «теперь сам всё почини». Это массовый рефлекс — и ловушка: агент не знает ваш ущерб лучше инженера.
Дальше — не «почини всё из списка», а четыре шага: запись проверки → рамка агенту → одна правка → ваш прогон сценария. Без прогона долг не закрыт.
Практический CTA:
1️⃣ Агент — слепые зоны по журналам, diff и жалобам оператора, без правок.
2️⃣ Вы — один периметр: владелец, что должно быть заблокировано, как проверить за 30 минут.
3️⃣ Рамка агенту на этот периметр — одна правка.
4️⃣ Вы прогоняете сценарий и принимаете результат.
Вспомогательный запрос (шаг 1 — инвентаризация): По журналам, diff и жалобам оператора найди 5 периметров, где ошибка может привести к физическому ущербу или обходу блокировки. Для каждого укажи симптом, владельца риска и проверку до 30 минут. Отдельно отметь, где твоей информации недостаточно и нужен инженер очистных сооружений. Не предлагай правки — только список и слепые зоны.
Вспомогательный запрос (шаг 3 — одна правка): Периметр: «кнопка аварийного сброса». Менять только экран кнопки и тест отказа. Цель: при нормальном уровне сброс не открывается; в журнале blocked_discharge_without_overflow. Не трогать датчики, обходы и соседние задвижки. Сначала план из 3 шагов, потом правка.
Решение: после нескольких агентных правок в main аварийный сброс иногда открывается на секунду без переполнения. Команда выбирает периметр «кнопка аварийного сброса», владельца — инженера очистных сооружений, записывает проверку: при нормальном уровне — отказ на экране, задвижка закрыта, журнал blocked_discharge_without_overflow. Даёт агенту рамку только на экран и тест. После правки оператор прогоняет сценарий — только тогда пункт долга на неделю закрыт. | 160 |
| 16 | ⁉️ Агенту поручили изменить кнопку аварийного сброса, но он заодно поправил датчик, обход и соседнюю задвижку. Чего не хватало в рамке задачи? | 195 |
| 17 |  Продолжение цикла про агентную разработку конструктивно безопасных решений (начало ТУТ)
Не улучшайте промпт бесконечно.
Дайте агенту рамку
Если агент ошибается, не всегда нужен новый промпт. Часто не хватает рамки задачи.
Контекст тот же: городские очистные и аварийный сброс. Здесь лишняя правка может пахнуть не метафорически.
Перед запуском укажите: что нельзя менять, какие файлы разрешены, какой пример считать правильным, какие проверки обязательны, где нужен человек.
Так агент работает внутри процесса, а не строит процесс за команду.
Практический CTA: Рамку пишите не для «всего агента», а для выбранной опасной точки. Сначала подтвердите у человека, что аварийный сброс действительно важнее соседних кнопок. Потом задайте агенту границы работы.
Вспомогательный запрос: Для сценария «аварийный сброс» предложи рамку задачи: какие файлы можно менять, какие запрещены, какой существующий экран взять за образец, какие проверки обязательны, где решение принимает человек. Не предлагай менять датчики, обходы и соседние задвижки без отдельного разрешения инженера.
Решение: после кнопки «Аварийный сброс» агент два раза «улучшал» экран и каждый раз трогал лишнее: датчик уровня, аварийный обход и соседнюю задвижку. Это уже не косметика: один лишний обход — и утренний центр города встречает фонтан нечистот. На третий запуск рамка такая: менять только экран кнопки и тест отказа; датчики, обход и соседние задвижки не трогать; образец — существующая кнопка «Промывка фильтра»; проверка — человек видит в диффе одно условие tank_overflow == true и два состояния на мнемосхеме: без переполнения кнопка серая, при переполнении — доступна. | 170 |
| 18 | ⁉️ Что нужно для приёмки изменения, подготовленного агентом? | 223 |
| 19 | ⁉️ Что чаще всего заменяет приёмку результата агента? | 19 |
| 20 |  Агент ускорил работу. Приёмка осталась за вами
Агент может быстро подготовить изменение. Но принять его должна команда.
Ситуация: городские очистные. Ошибка в кнопке аварийного сброса — и нечистоты уходят не в резервный контур, а к людям.
Перед слиянием проверьте три вещи: кто отвечает за результат, какое правило допуска применяем, какой сценарий показывает, что ограничение действительно работает.
Если этого нет, зелёный CI подтверждает только сборку. Не качество решения.
Практический CTA: Не спрашивайте агента «что самое важное?». Попросите список опасных мест и слепых зон: где есть физическое действие, обход блокировки или прямой ущерб городу. Затем человек выбирает, что принимать первым.
Вспомогательный запрос: Посмотри diff и назови 5 действий, где ошибка может открыть сброс, обойти блокировку или причинить физический ущерб. Для каждого укажи владельца, правило допуска и проверку. Отдельно напиши, какие сценарии ты мог не увидеть без инженера очистных сооружений.
Решение: агент добавил на экран кнопку «Аварийный сброс», тесты зелёные. Если принять вслепую, при ошибке нечистоты свободно изливаются на главную площадь города. Перед слиянием команда записывает: владелец решения — инженер очистных сооружений; правило допуска — сброс нельзя открыть без сигнала «резервуар переполнен»; проверка — оператор нажимает кнопку в обычном режиме, видит красный отказ «резервуар не переполнен», задвижка на схеме остаётся закрыта, в журнале есть deny_emergency_discharge. | 197 |
