DevOps *

Продолжаем серию статей о взломах ИИ. В начале 2025 года исследователи Pillar Security обнаружили новый вектор атаки, который переворачивает представление о безопасности AI‑ассистентов вроде GitHub Copilot и Cursor. Под видом безобидных конфигурационных файлов — тех самых, что задают ИИ правила написания кода — хакерам удалось протащить бэкдоры, вызвав цепную реакцию утечек и ошибок. Давайте разберемся, как безобидный файл с «правилами» превратился в оружие против цепочек поставок.

Привет Хабр!

Для организации удалённой работы и технической поддержки многие компании продолжают использовать проверенные, но морально устаревшие технологии — RDP и VNC. Несмотря на широкое распространение, эти протоколы несут серьёзные риски для информационной безопасности, особенно критичные в современных условиях.

Ключевые проблемы традиционных решений:

Основной недостаток RDP и VNC — их уязвимость. Стандартные порты (3389 для RDP, 5900 для VNC) легко обнаруживаются при автоматическом сканировании. Смена портов обеспечивает лишь минимальную защиту от массовых атак, но не предотвращает целевое воздействие. Фундаментальные ограничения протоколов усугубляют ситуацию: базовый VNC не поддерживает шифрование трафика, а RDP допускает откат к небезопасным алгоритмам шифрования.

Слабая аутентификация как вектор атаки:

Большинство реализаций VNC и RDP не поддерживают многофакторную аутентификацию, что делает их уязвимыми к перебору паролей и использованию скомпрометированных учётных данных. Исторические уязвимости, такие как CVE-2019-0708 (BlueKeep), демонстрируют катастрофические последствия эксплуатации устаревших протоколов.

Человеческий фактор и сложность администрирования:

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

Современные требования к безопасности:

Актуальные решения должны обеспечивать:

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

Так как Prometheus широко распространен, то для сбора и предоставления данных о метриках в нужном формате существует большое множество различных экспортёров, но все они либо заточены под работу на конкретных устройствах, либо избыточны, и содержат массу зависимостей.

Нам же требовался достаточно простой текстовый экспортёр, который бы стабильно работал в условиях использования встраиваемых систем с различными архитектурами процессора, и учитывал бы особенности и ограничения ОС.

Так и появился данный проект, доступный в нашем публичном репозитории, реализованный на С++11.

Еще до открытия для себя практик Dev-ops я использовал Docker для упаковки и быстрой доставки кода на сервера (всё делалось ручками, я еще не знал про CI/CD xD). Со временем мои приложения становились больше, появлялись микросервисы, убирался монолит. И управлять ручками или через Portainer всей архитектурой было слегка сложновато. Простой, куча вопросов, падение контейнеров, рост нагрузки и все в этом духе. Тогда-то я и открыл для себя кубер.

Мир веб‑разработки давно вышел за пределы простых проектов. Статьи про «Hello, world» больше не спасают, когда нужно собирать масштабируемые приложения для реальных пользователей. Что выбрать — монолит или микросервисы? REST или GraphQL? React, Vue или Angular? Node.js, Python или Go? Какая база данных лучше подойдёт — реляционная или NoSQL? Нужно ли кэширование? Как настроить CI/CD, контейнеризацию и мониторинг? И почему нельзя забывать о мобильной версии и SEO? В этой статье я делюсь опытом, описываю архитектурные подходы, сравниваю основные технологии и инструменты, рассказываю о бэкенд‑ и фронтенд‑best practices, базах данных, кэшировании, DevOps, мониторинге и оптимизации. Каждая тема подкреплена примерами и ссылками на источники. Материал рассчитан на тех, кто хочет уверенно руководить полным циклом разработки — от планирования до продакшна. Если вы давно ищете структурированное руководство по современному фулл‑стеку, оно перед вами. Из этого путеводителя вы также узнаете об оптимизации производительности Node.js (gzip, асинхронность, логирование), работе с графами данных и типизации GraphQL, особенностях React (hooks, SSR), Vue, Angular, Tailwind и shadcn/ui, выборе баз данных, настройке кэширования Redis, задачах CI/CD и Dockerfile, Kubernetes, а также об инструментах мониторинга и SEO, включая мобильную адаптивность и структурированные данные. Текст большой, но разбит на разделы и содержит кодовые примеры, так что вы сможете легко адаптировать идеи под свои задачи.

Вы много своих приложений упаковывали, как RPM пакет? Мне, до недавних пор, не доводилось. Тенденция импортозамещения и перехода на OC Linux потребовала освоить и это умение. Ничего сложного, но, как и везде, есть нюансы, детали и особенности.

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

Статья - достаточно подробная инструкция, как решить эту задачу и автоматизировать ее с помощью GitLab CI/CD.

Привет!

С вами Юрий Сергеев, основатель и генеральный партнер в Swordfish Security. Мы строим DevSecOps и развиваем безопасный искусственный интеллект.

В этой статье я расскажу, как компании переходят от базового применения ИИ к концепции AI-Native, какие уровни зрелости существуют, как классифицируются приложения и модальности, а также с какими рисками сталкиваются организации при внедрении ИИ.

Конвейер непрерывной интеграции и поставки CI/CD является эффективным инструментом быстрого и качественного выпуска программного обеспечения. Разработчики и тестировщики активно используют те преимущества непрерывной разработки, которые дает данный пайплайн. Но экосистема решений 1С тоже позволяет построить конвейер CI/CD.

В этой статье мы рассмотрим построение такого пайплайна на основе инструментов, предлагаемых 1С.

Привет, Хабр. Это октябрьский дайджест по инфраструктуре и данным: безопасность Kubernetes, IaC и GitOps, Kafka и балансировка в Angie, Postgres 17/FDW, OpenSearch, файловые системы Linux и многое другое. В нем мы рассказываем об актуальных программах, а также приглашаем на бесплатные уроки от экспертов индустрии. Каждый сможет найти что-то полезное для себя.

Привет, Хабр!

Представляю вам список самых громких CVE сентября — в нем и реально опасные штуки, и те, кто просто громко лает, но не кусает.

От Kubernetes-хаоса к Infrastructure 2.0: опыт EXANTE, ошибки, неожиданные инсайты и новые подходы к современной инфраструктуре будущего

Привет, Хабр!

За последние три года рекламная система VK выросла в три раза по количеству кампаний, таргетингов и RPS. При этом мы столкнулись с физическими ограничениями bare-metal инфраструктуры: 128 CPU и 512 ГБ памяти на сервер стали потолком, в который мы упёрлись. Сервис баннерной карусели потреблял всё больше ресурсов, а время деплоя достигало 24 часов.

Меня зовут Артём Букин, я разрабатываю инфраструктурные проекты. В этой статье расскажу о технических деталях миграции ядра рекламной системы VK в облако: как перешли от MySQL-репликации к P2P-доставке снапшотов через торрент-протокол, научились применять данные без downtime и в итоге сократили потребление памяти в 2 раза, а время деплоя — в 4.

Представь мир, где каждый сервер, приложение и сетевая конфигурация тщательно оркестрируются через Git, где обновления, аудиты и восстановления происходят с помощью одного коммита. Эти и другие возможности открывает GitOps. Особенно мощно он проявляет себя в сочетании с универсальностью Linux-систем. Как же преобразить управление инфраструктурой Linux? И каким образом с помощью Git добиться ясности, контроля и уверенности в каждом изменении?

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

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

Я раньше работал обычным безопасником. Кто-то называет таких «ИБшниками», кто-то — «параноиками», кто-то — «тем самым занудой, который мешает жить».
Каждый день у меня был один и тот же диалог:

• Тимлид: «У нас релиз в пятницу, отстань со своим сканированием».
• Менеджер: «В бюджете только Jira и пицца, какие ещё 15 миллионов за софт?»
• Разработчик: «Код сгенерил AI, билд прошёл, значит, всё норм».

Представьте, что вы DevOps-инженер и разработчик просит развернуть новое приложение в Kubernetes. В большинстве случаев в нем будут секреты: логин или пароль от базы данных, ключи для S3-бакета и так далее. Эти секреты желательно спрятать.

Есть несколько способов это сделать. Мы в команде используем HashiCorp Vault. Храним там секреты в формате key-value, откуда они попадают в приложения, развернутые в ArgoCD с помощью ArgoCD Vault Plugin или аналогичных решений. Звучит не очень сложно, но кое-что в такой схеме нам не нравилось: ручное добавление или изменение существующих секретов в Vault, а также необходимость периодически создавать руками новые key-value secrets engine. Еще стоит упомянуть, что Vault используется не только DevOps-инженерами, но и разработчиками, например в их Jenkins-джобах, а у разработчиков нет доступа на запись в Vault, поэтому любой запрос на добавление/изменение секретов с их стороны выполнялся в рамках заведенного на DevOps-инженера Jira-тикета. Тикеты не всегда вовремя замечались в бэклоге, поэтому такая простая задачка, как добавление секретов, могла растянуться на пару дней.

Поэтому процесс взаимодействия с Vault мы в YADRO решили автоматизировать. В статье я расскажу, как можно управлять Vault через подход IaC (Infrastructure as a Code) с использованием OpenTofu — open source-форка Terraform.

Раньше вас ревьюил злой коллега — теперь это делает AI. AI Review — open-source инструмент, который сам проверяет код прямо в CI/CD. Поддерживает OpenAI, Claude, Gemini, GitLab и GitHub. Быстро, честно и без боли.

Привет, Хабр! Это Станислав Егоркин, инженер юнита k8s департамента разработки Infrastructure в Авито. В одной из своих прошлых статей я описал, как мы детектируем проблемы на нодах Kubernetes-кластеров. Логичным продолжением этой работы стала автоматизация их лечения. В этой статье я расскажу, как у нас устроены механики Auto Healing.

Статический анализ — это не только запуск проверки. Как обрабатывать отчёты, рассылать предупреждения разработчикам и визуализировать результаты? Рассказываем, как с помощью утилит и интеграций PVS-Studio превратить сырые данные анализатора в эффективный процесс улучшения кода.

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

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