Как мы делаем Brainworks Office: элементы безопасной разработки, автотесты и ручное тестирование командой. У каждого пункта указано, чем он подтверждён.
Модель угроз, поверхность атаки, отчёты конвейера РБПО и экспертизы исходного кода. Только по заявке: оставьте контакты, и ссылки на PDF появятся сразу, они действуют 7 дней.
Раз в неделю и перед каждым выпуском публичный образ проходит конвейер практик безопасной разработки по ГОСТ Р 56939-2024. Проверки идут на одноразовом изолированном экземпляре редактора, после прогона он удаляется. Новые серьёзные находки приходят команде уведомлением, найденный секрет — срочным.
Последний прогон 25.10.2026: Выпуск 9.4.0-5: критических уязвимостей нет, все 37 требований безопасности выполнены, DAST: высоких 0, средних 2 (оба — осознанные исключения); уязвимости body-parser и multer исправлены (BW-110), осталась одна высокого уровня в node-forge, у которой нет исправленной версии.
| Практика | Последний результат |
|---|---|
| Состав компонентов и SBOM Системные пакеты образа и зависимости сервера, перечень компонентов в формате CycloneDX. | critical 0; high 2, обе — node-forge, исправленной версии нет (body-parser и multer исправлены в 9.4.0-5) |
| Сверка с БДУ ФСТЭК Для каждой найденной CVE ищем идентификатор в Банке данных угроз ФСТЭК России, отдельно — записи БДУ по ONLYOFFICE Docs, Node.js, nginx и OpenSSL. | для 13 из 58 CVE найдены BDU; касающихся наших версий записей 0 |
| Статический анализ (SAST) Наши изменения относительно ONLYOFFICE Docs 9.4.0 и сценарии сборки. | в наших строках high 0, medium 0 |
| Поиск секретов Вся история репозиториев продукта: ключи, пароли, токены. | 403 коммита, найдено 0 |
| Конфигурация образа Рекомендации CIS для контейнеров, секреты в слоях, файлы с особыми правами. | секретов в слоях 0, 2 замечания к базовому слою ONLYOFFICE |
| Динамический анализ (DAST) OWASP ZAP: пассивное и активное сканирование всех точек входа сервера. | high 0, medium 2 (было 7: остались CSP страниц редактора и HTTP без TLS — осознанно), low 0 |
| Требования безопасности Проверки по ориентиру OWASP ASVS уровня 1: подпись JWT, фильтр внутренних адресов, заголовки, служебные страницы. | 37 из 37 |
| Фаззинг конвертера Устойчивость к испорченным файлам документов. | в подготовке |
Экспертизу исходного кода (белый ящик) проводит команда раз в квартал и перед крупными выпусками: наши изменения сервера, интерфейса, движка, ИИ-помощника и конфигурации образа читаются вручную на ошибки безопасности по ориентиру OWASP ASVS и ГОСТ Р 56939-2024. Первая экспертиза 24.10.2026: критических находок нет, одна высокая и четыре средних исправлены в 9.4.0-4. Отчёт выдаётся по запросу.
Модель угроз, регламент реагирования на уязвимости со сроками исправления (критическая — 7 дней, высокая — 30 дней) и полный отчёт последнего прогона выдаём по запросу. Получить документы.
Все доработки оформлены как скрипты правок поверх ONLYOFFICE Docs 9.4.0, а не как ручные изменения. Выпуск собирается одной командой из этих скриптов, к каждому выпуску публикуется архив исходников с контрольной суммой SHA-256. Правка, уже наложенная на дерево, повторно не накладывается.
Как проверено. Архив исходников и образ каждого выпуска собираются из одного и того же набора скриптов; контрольная сумма архива указана рядом со ссылкой на скачивание.
Сканер уязвимостей (trivy) проверяет системные пакеты образа и отдельно зависимости сервера по lock-файлам: внутри упакованных программ сканер их не видит, и «0 уязвимостей» по образу было бы ложным. Если пакетов найдено подозрительно мало, скан считается проваленным, а не чистым. Сборка останавливается при critical или high в системных пакетах.
Как проверено. Скан 24.10.2026 одной и той же базой: зависимости сервера critical 3 и high 78 у ONLYOFFICE 9.4, 0 и 1 у Brainworks Office 9.4.0-2 (оставшаяся, node-forge, пока без исправленной версии).
Сервер работает на Node.js 24 LTS (поддержка до 30.04.2028) вместо Node.js 20. Архив Node.js при сборке сверяется по подписи выпуска и контрольной сумме. Ночная проверка сообщает, если вышел новый выпуск Node.js, а сервер ещё не обновлён. npm и npx из образа убраны: серверу они не нужны.
Как проверено. Проверка версии Node.js у исходного ONLYOFFICE 9.4 падает (ветка без поддержки), у Brainworks Office проходит.
Обновления безопасности Ubuntu входят в каждый образ. Шрифты с лицензией, запрещающей распространение, из образа удалены, при этом менеджер пакетов остаётся в рабочем состоянии и может ставить обновления.
Как проверено. Пакеты Ubuntu: high 6 у ONLYOFFICE 9.4, 0 у Brainworks Office. Отдельный тест проверяет, что запрещённых шрифтов в образе нет.
Когда пользователь вставляет картинку или файл по ссылке, сервер разбирает адрес по стандарту WHATWG URL и при включённых правилах не пускает запрос во внутренние адреса, в том числе в необычной записи и без имени хоста. Ответы в Brotli не распаковываются (закрыта уязвимость Node.js, защита оставлена второй линией и после перехода на исправленный Node.js).
Как проверено. Автотесты настоящего кода сервера: 127.0.0.1 в любой записи (в том числе 0x7f.1), [::1] и адрес без хоста отклоняются, внешний адрес проходит; ответ в Brotli отклоняется, gzip распаковывается. На исходной версии оба теста падают.
Система хранения документов открывает редактор только с конфигурацией, подписанной JWT. Ключ задаётся при установке и в исходниках и образе не хранится.
Как проверено. Автотест: с правильной подписью документ открывается, с чужой подписью не открывается.
Каждая сборка сервера проходит статическую проверку кода наших правок (eslint). В образ попадает только закоммиченный код: незафиксированные изменения в сборку не идут.
Как проверено. Ошибка eslint или незакоммиченная правка в исходниках сервера останавливает сборку.
Аналитика удалена во всех версиях редактора (полной, встраиваемой, мобильной). Редактор не отправляет данные третьим сторонам.
Как проверено. Автотест с блокировщиком: редактор открывается во всех 9 сочетаниях (3 браузера × 3 режима), внешних запросов 0.
Ключи тестовых стендов, автотестов и уведомлений хранятся в хранилище секретов, а не в репозитории. Автотесты получают их как секреты репозитория.
Как проверено. Значения ключей не записываются ни в репозиторий, ни в документацию: там только имена записей хранилища.
Образ, архив исходников и страницы этого сайта перед публикацией проверяются на внутренние сведения: имена внутренних серверов, внутренние номера сборок, сведения о заказчиках. Найдено хотя бы одно совпадение, и выпуск не публикуется.
Как проверено. Проверка дважды останавливала выпуск 9.4.0-2, пока все места не были исправлены. На каталоге с тремя подброшенными совпадениями она находит все три.
Все сборки идут через общий замок: две сборки одновременно не могут испортить друг другу дерево исходников. Выпуск собирается только полным сценарием, без ручных шагов.
Как проверено. Испытания замка: вторая сборка ждёт первую; после аварийного завершения сборки замок снимается сразу.
Форма трекера не требует регистрации. Адрес отправителя хранится только как необратимый хэш для ограничения частоты (5 заявок в час). Текст заявки публикуется только после разбора и без личных данных. Сервис трекера работает в контейнере без прав администратора.
Как проверено. Автотест: заявка робота (заполнено скрытое поле) отклоняется и не сохраняется; текст новой заявки на сайте не виден.
65 браузерных тестов каждую ночь и после каждой выкладки на тестовый стенд: документы, таблицы, презентации и телефон. Часть тестов идёт параллельно на исходном ONLYOFFICE 9.4 как контроль. Провал приходит команде уведомлением.
Авария узла, в том числе при совместном редактировании, плановый вывод узла, обрыв связи, сбой базы данных под нагрузкой. Пользователи продолжают работу без обновления страницы, подтверждённые правки не теряются.
500 одновременных сессий на один узел в трёх редакторах: отказов 0, сохранено 500 из 500.
1678 проверок по 497 функциям против эталонных результатов.
Тест принимается, только если он умеет падать: новый тест сначала прогоняется на сломанном варианте или на исходном ONLYOFFICE 9.4 и должен там упасть.
Автотесты ловят возврат старых ошибок, но не видят неудобного интерфейса и «поехавшей» вёрстки. Поэтому каждая сборка проходит и через руки людей.
Каждая сборка сначала выкладывается на тестовый стенд, и команда проверяет её руками в своих сценариях работы с документами. Публичный выпуск собирается из уже проверенного на стенде кода.
Файлы, сохранённые редактором, выборочно открываются вручную в Microsoft Word, Excel и PowerPoint: автоматическая проверка формата не заменяет взгляд человека на вёрстку.
65 проверок формул, у которых нет единственного правильного результата (точность вычислений, сведения о системе, расхождения Excel и Google), сравниваются глазами.
Каждое замечание пользователей пилотного внедрения и заявка из трекера сначала воспроизводится человеком. После исправления сценарий закрепляется автотестом, чтобы ошибка не вернулась.
Методика готова: 5 участников, привыкших к Google Документам, выполняют одни и те же задачи в Google, в новом виде и в классическом виде с лентами; сравниваются время и число ошибок.
Нашли уязвимость или ошибку? Сообщите через трекер; сведения об уязвимости публикуются только после исправления.