🎓 Олимпиада по кибериммунной разработке ждет своих участников!

4 апреля 2025 года в рамках Уральской горнопромышленной декады состоится масштабное онлайн-соревнование по конструктивной информационной безопасности. Организаторами мероприятия выступают Уральский государственный горный университет и «Лаборатория Касперского». Участники смогут продемонстрировать свои навыки в области кибериммунных технологий, решая уникальные задачи, подготовленные организаторами.

Почему это круто?
▪️Решай реальные кейсы в области кибербезопасности.
▪️Покажи свои знания перед экспертами из индустрии.
▪️Получи шанс заявить о себе в IT-сообществе.

Кто может участвовать?
Все, кому уже исполнилось 16 лет, и кто является гражданином РФ.

Экспертное жюри оценит решения участников Олимпиады и определит лучших, кто получит не только уважение коллег по цеху, но и уникальный мерч от «Лаборатории Касперского».

Как зарегистрироваться?
Подробная информация, правила проведения и форма регистрации на официальной странице Олимпиады ВКонтакте.

Не упусти шанс стать частью технологического будущего! 🚀

Здорово, когда наши решения находят отклик у пользователей! 🤩

«А почему бы и нет?» — подумал Сергей Байгудин и рассказал о своей кроссплатформенной библиотеке EOOS Safe для KasperskyOS на нашем форуме Kaspersky Support Forum.
👉 https://kas.pr/aw3a

— Я уже очень давно занимаюсь разработкой безопасного программного обеспечения, — пишет Сергей, — и, в частности, собственной кроссплатформенной библиотеки EOOS Safe на языке С++. Когда-то очень давно начал её развивать для POSIX и WIN32 совместимых операционных систем, затем адаптировал для FreeRTOS. А когда появилась KasperskyOS CE 1.1, то я задался вопросом как, собственно, изучения самой операционной системы, так и адаптации EOOS Safe для неё. Изучил. Адаптировал.

Скачать последний релиз библиотеки EOOS Safe для KasperskyOS CE 1.3 можно тут. В будущем, конечно, обещаю не отставать от релизов KasperskyOS CE и, безусловно, развивать свою кроссплатформенную библиотеку EOOS Safe.

🤝 Благодарим Сергея за проделанную работу и желаем ему двигаться вперёд вместе с новыми релизами KasperskyOS.

Задать любые каверзные вопросы Сергею Байгудину по кроссплатформенной библиотеке вы можете вот в этой ветке форума.

Продолжаем пополнять репозиторий VK Video. И сегодня в нашей ретроспективе видео с зимней конференции KOS Night 2022.

И в новом 👌 плейлисте:
🟢видео №1🟢Евгений Касперский. Вступительное слово
🟢видео №2🟢Сергей Рогачев. Глобальная жизнь кибериммунитета: почему кибериммунный подход уже захватил мир
🟢видео №3🟢Вячеслав Борилин. Нужно ли разработчику быть специалистом по ИБ?
🟢видео №4🟢Сергей Соболев. Кибериммунные ката: сложно ли их применять, если вы еще не пользуетесь KasperskyOS?
🟢видео №5🟢Игорь Подвойский, Владислав Фофанов. KasperskyOS в 3D: Development, Debugging, Drivers
🟢видео №6🟢Васил Дядов. «Святой Грааль» формальной верификации: достижения и планы
🟢видео №7🟢Вадим Ломовцев. Опыт разработки под KasperskyOS: портирование NodeJS
🟢видео №8🟢Александр Мотавин. KasperskyOS и Open Source: какие проекты и библиотеки доступны под KasperskyOS
🟢видео №9🟢Александр Лифанов. Планы KasperskyOS Community Edition: функциональность, документация, оборудование
🟢видео №10🟢Владимир Малыгин. Сообщество разработчиков под KasperskyOS: результаты 2022
🟢видео №11🟢Александр Лифанов. Я бы в кодеры пошел: где изучать разработку под KasperskyOS

▶️ Смотреть весь PlayList
Смотрите сами, делитесь с друзьями и коллегами 🧑🏻‍💻👩‍💻.

А наши эксперты всегда рады ответить на ваши вопросы в комментариях ниже.

На вебинаре «Обновления в Kaspersky Thin Client 2.3: Новые сценарии и возможности», который прошел 27 февраля 2025 года, эксперты «Лаборатории Касперского» Семён Мазуров, Михаил Левинский и Александр Федорченко продемонстрировали новинки кибериммунного тонкого клиента и показали его работу в деле. А ещё — поделились кейсами успешных внедрений!

Смотреть вебинар можно на одной из наших площадок:
➡️YT — https://kas.pr/hr6x
➡️RT — https://kas.pr/nc7q
➡️VK — https://kas.pr/py1x

Мы обсудили:
🟢Новые функциональные возможности Kaspersky Thin Client 2.3
🟢Приложения, расширяющие возможности для сотрудников: от мультимедиа, до новых типов подключений к удаленным рабочим столам
🟢Средства централизованного управления парком устройств
🟢Передовой подход к киберзащите рабочего места сотрудника
🟢Новые инструменты для администратора: полный контроль над отдельными устройствами и над всей инфраструктурой
🟢Реализованные проекты и результаты внедрения

Не пропусти следующее мероприятие! 🔥

Узнать подробнее о решении и задать вопрос можно по ссылке: kas.pr/23vm

00:01 - 01:39 - Вступление
01:39 - 25:21 - Новые функциональные возможности Kaspersky Thin Client 2.3
25:21 - 42:45 - Демонстрация продукта
42:45 - 43:55 - Как попробовать?
43:55 - 46:20 - Реализованные проекты и результаты внедрения
46:25- 47:20 - ТСО
47:21 - 48:30 - Награды и достижения
00:48:30 - 01:02:41 - Ответы на вопросы
01:02:42 - 01:06:34 - Песня

#KasperskyThinClient #KasperskyOS #KTC #Тонкийклиент #кибериммунитет

Для проблем, связанных с существующими подходами к кибербезопасности, идеология Secure by Design предлагает простое и элегантное концептуальное решение. Оно звучит так: кибербезопасность должна быть не дополнительной деталью или нефункциональным требованием (вроде удобства использования, оно же usability, которое, очевидно, не приоритетно для разработчиков), а неотъемлемым свойством системы.

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

Жили-были в лесу зайцы, и их все обижали. Как-то пошли они к мудрой сове за советом.
Сова подумала и говорит: «А вы станьте ежиками Secure by Design, вас никто и обижать не будет».
Зайцам совет понравился. «Но… как же нам стать ежиками Secure by Design?» — спросили они.
«Вы меня ерундой не грузите, я стратегией занимаюсь, а тактика — это не ко мне», — ответила сова.

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

Конкретику привносит именно кибериммунитет:
🟢Конкретная методология: как именно организовать процесс разработки и какие результаты необходимы на каждом этапе.
🟢Требования к дизайну: как именно должна быть спроектирована система, чтобы реализовать подход Security by Design экономически эффективным способом.

☝️Идеологию Security by Design стоит воспринимать как фундаментальную основу, а кибериммунитет — как конкретный набор методов и инструментов, превращающих эту концепцию в прикладную реальность. Внедрение кибериммунитета требует донастройки процессов разработки, но результат оправдывает усилия.

✔️ Новая роль моделирования угроз в процессе разработки

Известно, что моделирование угроз (процесс поиска потенциальных угроз для системы) и разработка мер для защиты от этих угроз — процесс итеративный и дорогой. Но его можно значительно удешевить.

Для этого посмотрим на задачу как изобретатель. В теории решения изобретательских задач (ТРИЗ) есть такой метод — «инверсия», когда для решения сложной задачи пробуют выполнить что-то наоборот. Например, изменить устоявшийся порядок операций (делать в начале то, что раньше делали в конце), радикально поменять ориентацию объекта (повернуть ось ветряка на 90°) или заменить действие на противоположное (отключать то, что раньше подключали).

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

Итак, как этот подход работает на практике:
1️⃣В самом начале нужно в явном виде описать объективные ценности продукта и те потенциальные неприятности, которые могут с ними случиться и которые для нас неприемлемы, — на уровне бизнес-назначения этого продукта. Иными словами, ответить на вопрос: «А что мы защищаем и от чего?»

2️⃣Понимая, что и от чего мы защищаем, определить цели безопасности: какие свойства системы должны сохраняться при любых обстоятельствах. (Больше о целях безопасности читайте здесь.

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

4️⃣Уже на основе готового проекта, включающего в себя архитектуру решения, провести моделирование угроз. И если мы добросовестно отнеслись к предыдущим этапам, то моделирование должно подтвердить, что все угрозы, которые влияют на достижение целей безопасности, уже «закрыты». А тем угрозам, которые на цели безопасности не влияют, — мы и внимания много уделять не будем, ведь они не критичны. Возможно, на этом этапе мы выявим какие-то упущения, но вряд ли они потребуют пересмотра архитектуры.

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

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

Ставь 👍, если ты уже используешь подобный подход в процессе разработки.

😎 Пройди стажировку в «Лаборатории Касперского»!
https://safeboard.kaspersky.ru

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

Участвовать в отборе могут все, кто:
🟢Проживает в Москве либо Московской области.
🟢Является текущим студентом ВУЗа или Школы 21 и выпускается не раньше 2026 года.
🟢Готов уделять работе хотя бы 20 часов в неделю.

Вуз и специальность не имеют значения — прежде всего, мы оцениваем кандидатов по итогам прохождения онлайн-тестов.
Подробнее 👉 https://safeboard.kaspersky.ru

Крайний срок подачи заявки — 20 апреля.

💡25 апреля в Екатеринбурге пройдет DUMP 2025 — главная IT-конференция Урала.

Планируете участвовать?
Обязательно приходите на стенд «Лаборатории Касперского»! 🤗

Покажем, как информационная безопасность работает на практике — без лишней теории и с элементами гейминга:
➡️CE: Построй безопасный WebServer — интерактивный опыт по созданию устойчивого веб-приложения;
➡️KasperskyOS CE Box — возможность бросить вызов нашей микроядерной операционной системе. Сумевшие открыть замок на базе KasperskyOS, получат приз.
➡️TONK: Турнир по игре Quake — культовая игра, запущенная на тонком клиенте TONK с KasperskyOS — чтобы уязвимостям точно не было шансов.

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

🟢«Подходы к обеспечению информационной безопасности на практике».
Алексей Цилябин, разработчик группы разработки KasperskyOS, разберет подходы, которые можно внедрять уже сегодня, от авторизации в критических системах до универсальных паттернов безопасности.


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

🗓 Ждем вас 25 апреля в Екатеринбург-Экспо
Конгресс-Центр на главной IT-конференции Урала.

▶️ Записи Kaspersky Cyber Immunity Developers Night — открытой обучающей конференции по кибериммунной разработке — уже в доступе на нашем канале VK Video.

🟢видео №1 🟢Евгений Касперский. Приветственное слово
🟢видео №2 🟢Сергей Рогачев. Язык мой — враг мой? Безопасные и небезопасные языки программирования
🟢видео №3🟢Ольга Алёшина. Как применять GPU при разработке современных графических интерфейсов
🟢видео №4🟢Юрий Шведов. Удаленно управляем и отлаживаем С++ API с помощью KDS бесплатно, без регистрации и SMS
🟢видео №5🟢Андрей Наенко. Как маленькие ошибки могут оборачиваться большими уязвимостями
🟢видео №6🟢Татьяна Голубева, Олег Кировский. Совместим ли кибериммунитет с отраслевыми требованиями?
🟢видео №7🟢Андрей Карабань. Кибериммунитет и KasperskyOS в ООН: поддержка UN R № 155
🟢видео №8🟢Тимур Шарафеев. KASG: возможно ли сделать продуктовые сценарии быстрыми и безопасными
🟢видео №9🟢Валерий Овчинников. Как мы кибериммунный IoT-контроллер на KasperskyOS SDK разрабатывали
🟢видео №10🟢Александр Лифанов. Движение к продуктам с кибериммунитетом, или как учиться кибериммунной разработке
🟢видео №11🟢Ответы на вопросы о кибериммунной разработке и KasperskyOS

Смотрите, комментируйте, переходите на нашу сторону кибериммунитета 👨‍💻

Прод горит, а код еле держится «на костылях»?
Значит, это самое время выпить кофе переключиться и принять участие в игре, от которой зависит не только твой скилл, но и, возможно, будущая карьера!

Поиграем в кибериммунитет? 🙃
Ничего не понятно, но очень интересно!

📆 Стартуем в понедельник 28 апреля на нашем канале KasperskyOS. Разработка.

Что тебя ждёт во II Эпизоде?

▪️Реальные фейлы мирового масштаба: от British Airways до Tesla и Equifax. Разберём, почему это случилось, и как этого избежать в твоём коде.

▪️Кибериммунитет на пальцах: даже бабушкин петух умеет строить эшелонированную защиту лучше, чем специалисты многие компании. Поймёшь, почему.

▪️Жёсткие холивары и прикольные шутки с DevSecOps и безопасниками: узнаешь, почему чайнику не нужны рутовые права, и зачем думать, будто тебя уже взломали (спойлер: потому что, скорее всего, так и есть).

▪️Разделы «Вынос пользы для джуна» и «Пояснительная бригада», в которых всё, что нужно и важно, причем кратко и ёмко.


❓ Почему мы крайне рекомендуем потратить несколько минут в день на нашу игру.

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

А, может, это станет твоим первым шагом, чтобы уйти в секьюрити ресёрч, стать киберэлитой и взламывать мир ему же на благо?


🎲 Каждый день — новый пост.
Каждый пост — новая возможность стать круче.


Подписывайся, включай уведомления и присоединяйся к игре.
Мы взлетаем 🚀✨✨✨

#поиграемвКИ

Ставь 👍, если ты с нами!

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

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

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

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

На прикладном уровне принцип минимизации доверенной кодовой базы сводится к следующему:
🟢 как можно меньше доверенных компонентов должны непосредственно влиять на достижение целей безопасности системы;
🟢 сами доверенные компоненты должны быть достаточно простыми с точки зрения функциональности и иметь маленькую поверхность атаки.

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

Именно этот принцип помогает разрабатывать кибериммунные системы.

1️⃣— Мир на костылях

Жара стояла такая, что даже серверная дышала с трудом. В командном чате горело:

«Критическая ошибка!», «Сломалось всё!», «Кто последний коммитил?!», «Бэкапы работают?», «Роллбек не помогает!»

Джун уставился в монитор, пытаясь глазами оживить графики мониторинга. Сердце колотилось: это его код ушёл в прод вчера ночью. Всё было нормально… Или нет?

Сеньор пил кофе и молча листал логи. Безопасник мрачно снимал скриншоты ошибок. DevOps вызывал древних богов Ansible. DevSecOps что-то шептал про «почему опять без авторизации?».

«Джун, дыши», — сказал себе наш герой, но сердце гремело, как перегруженный процессор.

— Но ведь тесты были зелёные! Всё работало! — наконец выдавил он вслух.

Сеньор лениво поднял бровь:
— На тестах оно и у бабушки работает. А в проде законы физики другие.

Джун сглотнул. В проде всё будто жило своей жизнью.

Безопасник оторвался от экрана:
— О, опять API платежей развалилось? Как неожиданно...

DevOps нервно хохотнул:
— Да, причём из-за фикса в комментариях.

— Это как? — переспросил Джун.

— Он как бабушкин дом — один угол чихнёт, второй осыпается. А что ты хочешь? Монолит...

В этот момент в офисе погас свет. Только серверная горела индикаторами, как маяк в ночи.

Сеньор нахмурился:
— Вот это и есть изоляция. Серверная на отдельной линии. А у нас в коде почему-то всё завязано друг на друге, как гирлянда в новогоднем коробе.

Секьюрити ресёрчер, наблюдавший за всем из угла, наконец заговорил:
— Именно. Кибериммунитет — это не про отсутствие багов. Это про устойчивость. Минимизация. Изоляция. Контроль.

Джун моргнул. Он чувствовал, что сейчас узнает что-то важное.

— При чем тут кибериммунитет? Почему вдруг мы об этом заговорили?

Сеньор многозначительно заявил:
— Кибериммунитет — ключевой элемент безопасных IT‑систем будущего. Как иммунитет защищает организм от болезней и инфекций, кибериммунитет направлен на обеспечение устойчивой и адаптивной защиты цифровых систем.

И продолжил:
— Но для этого надо понять, как всё устроено на самом деле. Например, на курсах по кибериммунной разработке. Кстати, подумай об этом. Рекомендую отличный вариант [ссылка на курс по КИ]. Сам в своё время проходил.

Продолжение следует...

Вынос пользы для джуна:

▪️Понимай, как твоя система ломается. Если не знаешь, как и где она может упасть — это уже проблема.

▪️Минимизируй точки отказа. Если сервис не влияет на другой, его падение не должно нести критические последствия.

▪️Изолируй критичные зоны. Серверная в офисе выжила, потому что её заранее сделали отдельной. Код должен проектироваться так же.

▪️Думай, как защитить систему от самой себя. Иногда самый опасный враг продакшена — это код, который писали сами разработчики.

Пояcнительная бригада:

Монолит vs Микросервисы: монолитные системы часто страдают от эффекта «домино»: один сбой тянет за собой всю систему. В микросервисной архитектуре это частично решается, но без строгой изоляции проблемы всё равно распространяются.

Изоляция через Fault Domains: в продвинутых системах компоненты распределяют так, чтобы сбой одного не рушил всё. Это как раз то, что есть в дата-центрах, но редко в коде.

Assume Failure: критические сервисы проектируются так, будто сбой неизбежен. Например, серверная на отдельной линии электропитания, как в примере.

Изоляция в коде: использование контейнеров (Docker, Kubernetes), политики доступа (RBAC, IAM), чёткое разграничение сервисов.

Ставь 😭, если ты валил когда-нибудь прод и понимаешь всю боль джуна.
Ставь 👍, если понравилось начало нашей игры в кибериммунитет!

#поиграемвКИ

2️⃣— Чайник с рутовыми правами

Офис ожил. Серверы гудели, DevOps что-то колдовал в терминале, а безопасник уже строчил отчёт «Почему так случилось, и кто виноват».

Джун задумчиво сидел перед ноутбуком: «Если изоляция такая важная, почему её не делают по умолчанию?»

Он машинально открыл Telegram и увидел новость: «Хакеры взломали умные чайники и устроили DDoS-атаку».

— Сеньор, тут чайники взломали. Как?

Сеньор даже не удивился:
— Очень просто. У чайника были рутовые права.

Джун моргнул:
— Чайник. С root-доступом. Ты серьёзно?

DevSecOps хмыкнул:
— Ага. Потому что кто-то решил, что чайнику вдруг пригодится полный контроль над всей сетью.

— То есть, чайник — это как наш прод, где API комментариев умеет дропать базу?

Секьюрити ресёрчер кивнул.
— В точку. Минимизация — важнейший принцип безопасности. Чайнику не нужно управлять маршрутизатором. Сервису логов не нужен доступ к API платежей.

— Но иногда ведь удобно, если сервисы могут больше?

— Конечно, удобно... Так же, как удобно носить ключи от всех дверей дома в одной связке и терять их на автобусной остановке.

DevOps грустно посмотрел в монитор и вспомнил факт их прошлого:
— В 2016 году Mirai-ботнет устроил крупнейшую атаку, потому что устройства имели дефолтные пароли и слишком много прав. Камеры наблюдения превратились в оружие хакеров.

— А что нужно было сделать?

Сеньор ответил без раздумий:
— Least Privilege. Минимальные права. Default Deny. По умолчанию запрещено всё, разрешается только строго необходимое.

Джун покачал головой, не понимая:
— Получается, мой умный чайник — умнее моего кода? Он хотя бы кипятит воду и не пытается получить root-доступ?

Секьюрити ресёрчер усмехнулся:
— Если ты не напишешь код правильно, он может и это начать делать.

Продолжение следует...

Вынос пользы для джуна:

▪️Минимизация прав — меньше атак. Если сервис умеет только то, что нужно, его сложнее взломать.

▪️Default Deny — безопасность по умолчанию. Если ты не задал явные права, у процесса их нет.

▪️Least Privilege — у каждого сервиса только необходимые полномочия. Если API комментариев не должен менять данные в биллинге, то он и не должен их иметь.

▪️Нельзя проектировать системы по принципу «а вдруг пригодится». Не давай чайнику права root!

Пояснительная бригада:

Mirai-ботнет (2016): использовал устройства с дефолтными паролями, превращая их в часть ботнета. В результате были атакованы крупные сервисы, включая Twitter, Netflix и GitHub. Подробнее читай тут.

Least Privilege: система должна работать по принципу «минимально необходимых прав». Это особенно критично в облаках и контейнерных средах.

Default Deny: если не знаешь, нужно ли что-то разрешить — запрещай по умолчанию. В сетевых политиках (например, firewall) это ключевая практика.

RBAC (Role-Based Access Control): настройка прав доступа через ролевую модель — только необходимое.

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

#поиграемвКИ

📎 Мини-курс «Кибериммунитет за 3 вечера».

📆 СТАРТ — 10 июня в 19:00 по Мск.

✅Для истинных кодеров. Без сахара, ванили и хрупких систем.
✅Для тех, кто видит TODO в легаси-коде и понимает, что его никто не исправит.
✅Для тех, кто не просто пишет код, а понимает, что за ним стоит.

Присоединяйся к команде.
🔘https://vk.cc/cKFXlQ
Мы взлетаем 🚀✨✨✨

#поиграемвКИ
Ставь 👍, если ты с нами!