Безопасная разработка ПО

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

Текст для заказчика, техлида и компании-подрядчика: что включать в ТЗ и договор, как проверять на демо, чего не обещать «из коробки».

Минимум, без которого нельзя выходить в прод

• Разделение стенда и продакшена, разные секреты.
• Секреты в менеджере или хранилище, не в мессенджере и не в репозитории.
• Аутентификация и срок жизни сессий, выход и отзыв токенов.
• Авторизация на сервере: мобильное приложение не источник правды о правах.
• Резервное копирование и хотя бы одна успешная проба восстановления.
• Журнал входов и критичных действий (смена суммы, выгрузка базы, выдача прав).
• HTTPS, актуальные зависимости, закрытие известных дыр по расписанию.

Этот список скучный и закрывает больше инцидентов, чем модный «AI-firewall» на слайде. Для приложений добавьте хранение токенов по правилам платформы, защиту от перехвата трафика и политику удалённого отзыва сессии потерянного телефона.

Данные, 152-ФЗ и договор

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

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

Код, ревью, зависимости, ИИ

Ревью критичных модулей: оплата, права, импорт файлов, интеграции. Зависимости с известными CVE не копятся «до большого релиза». Секреты в CI — отдельные, с минимальными правами. ИИ-агенты не получают прод-ключи и не видят выгрузки клиентов. Правила — ИИ для написания кода, выбор инструментов — ИИ-агенты 2026.

Загрузка файлов пользователями — классическая дыра. Ограничивайте типы, размеры, сканирование, хранение вне веб-корня. Интеграции — по принципу наименьших прав: сервисному пользователю 1С не нужна роль «бог».

Как вписать безопасность в процесс, а не в «неделю в конце»

Чек-лист угроз на discovery: что украдут, что подменят, что уронят. Требования в ТЗ конкретные, не «система должна быть безопасной». На каждом спринте — не открывать новые дыры ради скорости. Перед релизом — прогон критичного пути и проверка секретов. После релиза — окно обновлений. Процесс клиента — процесс разработки приложений, требования — ТЗ.

Ошибки «безопасной» разработки

Общий админ на всю компанию. VPN «вместо паролей». Отключение логов, потому что «диск кончился». Игнор обновлений из страха сломать прод — и инцидент от известной дыры. Pentest как театр раз в три года без закрытия найденного. Обещание подрядчика «мы как банк» без базового списка выше.

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

Когда усиливать сверх минимума

Платежи, медицина, большие объёмы ПДн, привилегированные внутренние данные, требования клиента-корпорации. Тогда появляются отдельные политики, сегментация сетей, внешняя оценка, более жёсткий CI. Это бюджет и срок, их надо назвать до старта, а не «потом сертификат».

Когда не имитировать безопасность

Не покупайте пакет «комплаенс» вместо бэкапов. Не закрывайте пилот стостраничным ИБ, если в пилоте нет живых ПДн — используйте тестовые данные. Не путайте юридический документ и техническую меру: политика без ролей в системе ничего не закрывает.

Следующий шаг

Внесите минимум мер в ТЗ и договор. Назначьте, кто отзывает доступы. Проверьте бэкап восстановлением, не наличием файла. Для продукта по-прежнему нужны сценарии — безопасность их обслуживает, не заменяет.

Обсудить контур — Grevin, grevin.info@mail.ru, контакты. Разработка ПО, приложения.

Среды, секреты и принцип наименьших прав

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

Секреты ротируйте после увольнений и смены подрядчика. Токены в мобильном приложении — короткоживущие, с refresh и отзывом. Хардкод ключей карт в клиенте — приглашение к злоупотреблению квотой. Это проверяется grep-ом по репозиторию на приёмке, не «мы же не дураки».

Защита интеграций и границ системы

Внешний API должен видеть столько, сколько нужно партнёру, и писать столько, сколько вы готовы принять. Подписи запросов, ограничение частоты, список IP если уместно, идемпотентность оплат. Входящие вебхуки проверяйте на подлинность, иначе вам будут слать фальшивые «оплаты». Исходящие вызовы — с таймаутами и повторами, чтобы не зависнуть в чужом простое навсегда.

Файловые шлюзы: не исполнять загруженное, не отдавать чужие идентификаторы перебором. Идентификаторы лучше непредсказуемые, если объект не должен быть угадан. Для внутренних систем управления это часто важнее «красивого https» на витрине. Связка с контуром учёта — системы управления.

Инцидент: что делать в первые часы

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

Репетиция на бумаге раз в год дешевле первого настоящего инцидента. Хотя бы: кто звонит, кто имеет право выключить фичу, где бэкап. Сопровождение без этого плана — дежурство в темноте. См. сопровождение ПО.

Безопасность и скорость поставки

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

Заказчику на демо полезно один раз в спринт спрашивать: какие новые права появились, какие секреты добавились, истёк ли сертификат. Пять минут, которые дешевле аудита «когда-нибудь».

Поставка: подписи, артефакты, целостность сборок

Сборки приложений и деплои серверов должны быть воспроизводимы из репозитория, а не «с машины разработчика». Подпись стора — ключами компании. Артефакты CI хранятся, чтобы ответить, что именно выкатилось в тот вторник. Иначе расследование инцидента упирается в «ну мы вроде из той ветки». Это инженерная гигиена, она входит в безопасную разработку ПО так же, как хеширование паролей.

Цепочка зависимостей: lock-файлы в git, проверка целостности пакетов где возможно, запрет случайных latest. Атака через зависимость — не теория. Даже небольшой контур выигрывает от дисциплины версий. Сопровождение без этой дисциплины накапливает сюрпризы: сопровождение.

Проверка на приёмке: короткий красный список

Попросите показать: пользователя без прав, который не видит чужие объекты; отозванный токен; попытку вызвать API без сессии; загрузку недопустимого файла; что секреты не печатаются в лог на ошибочном запросе. Если подрядчик раздражён этими вопросами, вы узнали о культуре раньше, чем в инциденте. Это дешевле аудита «для галочки».

Для мобильного клиента добавьте: приложение не хранит пароль в открытом виде, не логирует карту, корректно просит разрешения и работает при отказе. Отказ геолокации не должен ронять весь сценарий, если гео не must-have. Это продуктовая безопасность, её видно в ТЗ: составить ТЗ.

Культура, а не только чек-лист

Безопасность держится, когда сообщать об ошибке безопасно: человек не прячет инцидент из страха. Постмортем без публичных унижений. Мелкие находки в бэклоге, а не «забудьте, повезло». Подрядчик, который скрывает дыру, чтобы сдать акт, — риск больше, чем отсутствие WAF. Заказчик, который орёт за каждый баг, получит тишину вместо сигналов.

Обучение: фишинг к админке, пароли, флешки с выгрузками. Техника без людей не спасёт. Для компаний, заказывающих разработку, включите в услугу короткий инструктаж администраторов — это дешёвый слой защиты. Услуги контура: ПО, приложения.

Короткий стандарт v1, который можно вставить в ТЗ

Среды разделены. Секреты не в git. Права на сервере. Сессии отзываются. Бэкап проверен восстановлением. Журнал критичных действий. HTTPS. Зависимости с lock-файлом. Загрузки ограничены. Интеграции с наименьшими правами. ИИ без продовых секретов и без выгрузок клиентов. Инцидент: кто звонит, кто режет доступ. Этот абзац не заменяет отраслевой аудит, но отделяет серьёзного подрядчика от театра. Добавьте его в договор как чек-лист приёмки.

Дальше — соразмерно данным. Платежи и медицина усиливают меры и бюджет. Пилот на тестовых данных не должен тонуть в комплаенсе, но и не должен выходить в прод с паролем «123». Баланс — управленческое решение, его фиксируют письменно. Связанные темы: сопровождение, ИИ в коде, услуги ПО и приложений.

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

Телефон курьера — не сейф. PIN экрана не равен безопасности сессии. Заложите таймаут, удалённый logout, запрет копировать чувствительные поля куда попало, минимизацию кэша. Jailbreak/root как сигнал риска — по политике, не всегда блок. Главное — не хранить в клиенте то, чего нельзя унести. Правда прав снова на сервере. Это обязательный абзац, если вы делаете полевое приложение. См. ПО и приложения.

Не хранить копии «на всякий случай»

Дампы базы на ноутбуках, выгрузки в почте, скрины паспортов в чате — типичный обход любых политик. Запретите и дайте легальный путь: обезличенный стенд, короткий доступ, журнал. Без легального пути запрет не работает. Это последняя бытовая дыра, которую закрывают после чек-листа ТЗ, и она стоит дешевле любого внешнего аудита.

Частые вопросы