Настоящий Обзор безопасности описывает технические и организационные меры, которые Melaya, Inc. («Melaya») в настоящее время применяет для защиты конфиденциальности, целостности и доступности платформы Melaya. Он призван дать потенциальным и действующим пользователям, корпоративным покупателям и аудиторам честное представление о том, что находится в производстве сегодня, что находится в разработке и что ещё не реализовано. Если возможность является перспективной или находится в разработке, это явно отмечено, а не скрыто за расплывчатыми формулировками. Безопасность является общей ответственностью: Melaya отвечает за безопасность платформы, а клиенты отвечают за безопасность того, что они создают, загружают и выполняют на ней.
1. Шифрование при передаче и хранении данных
Все данные, передаваемые между клиентами пользователей и Сервисами, защищены протоколом TLS версии 1.2 или выше, который завершается на Cloudflare на периметре развёртывания. Производственный профиль TLS соответствует руководству Mozilla Intermediate: только TLS 1.2 и 1.3, только наборы шифров ECDHE, HSTS с двухлетним max-age и директивой preload, а также строгая политика безопасности контента с явным списком разрешённых адресов connect-src. Полный профиль, утверждённый список шифров и ежеквартальный цикл проверки задокументированы в руководстве TLS Baseline во внутреннем хранилище данных безопасности и применяются промежуточным программным обеспечением helmet в server/src/index.ts. Внутренние вызовы между сервисами в нашей инфраструктуре осуществляются через петлевой интерфейс или каналы частной сети.
Данные, хранящиеся в основной базе данных Postgres и в объектном хранилище, шифруются с использованием симметричного шифрования, предоставляемого провайдером хостинга, с ключами, управляемыми службой управления ключами провайдера. Это обеспечивает защиту от кражи физического диска, но само по себе не защищает от компрометации приложения или провайдера.
Поверх дискового шифрования, обеспечиваемого провайдером, конфиденциальные значения дополнительно защищены прикладным уровнем конвертного шифрования, реализованным в server/src/services/envelope.ts. Учётные данные API биржи (ключ, секрет, парольная фраза) оборачиваются шифрованием AES-256-GCM с использованием 256-битного мастер-ключа, хранящегося только в среде сервера, перед их отправкой провайдеру хранилища Infisical или записью в резервную таблицу agents.credentials. Формат данных содержит явный идентификатор ключа (v1:<kid>:<base64(iv|ciphertext|tag)>), что позволяет серверу принимать несколько действительных ключей в период ротации и направлять операции чтения к точному ключу, которым зашифровано каждое значение. Новые записи всегда используют активный ключ, то есть первый элемент в настроенном списке ключей. Ротация представляет собой трёхэтапную процедуру, не приводящую к простою платформы: добавление нового ключа в качестве второго элемента (записи по-прежнему используют старый ключ, новый ключ доступен только для чтения), продвижение его на первое место (записи переключаются на новый ключ, старый ключ остаётся доступным для чтения), повторное шифрование исторических строк, привязанных к устаревшему идентификатору ключа, и удаление старого элемента. Ни Infisical, ни хост Postgres в ни один момент не видят учётные данные в открытом виде: компрометация любого из субобработчиков в отдельности даёт злоумышленнику только зашифрованный текст, и для восстановления любого биржевого ключа дополнительно требуется настроенный ключ конверта. Одноразовый скрипт миграции по адресу server/src/scripts/migrate-envelope-wrap.ts обработал остаточные устаревшие строки с открытым текстом, существовавшие до введения конвертного уровня шифрования; обработка завершена в производственной базе данных, а верификатор (envelope-verify.ts, 7/7 сценариев) завершается с кодом 0 при каждом запуске в системе непрерывной интеграции и в производственной среде.
2. Изоляция арендаторов и конвейеров
Платформа обеспечивает логическую изоляцию между арендаторами на уровне приложения. Каждый аутентифицированный запрос несёт идентификатор пользователя, полученный из проверенного JSON Web Token, и каждый запрос к базе данных, доступ к хранилищу объектов и поиск в индексе извлечения ограничены этим идентификатором через параметризованный SQL и контекст tRPC. Индексы извлечения, созданные для агентного фреймворка, хранятся отдельно для каждого конвейера и возвращаются только запросам, исходящим от владеющего ими конвейера. Состояние движка, конфигурации стратегий и история ордеров аналогично разделены по пользователям. Безопасность на уровне строк Postgres применяется как эшелонированная защита за изоляцией на уровне приложения: FORCE ROW LEVEL SECURITY активна в продакшене для agents.mfa_challenge, agents.credentials и agents.users, а приложение подключается под ролью с минимальными привилегиями (melaya_app, rolbypassrls=false), которая не может видеть данные других арендаторов, даже если запрос случайно пропустит условие WHERE user_id. Семнадцать межарендаторских сценариев в server/src/scripts/rls-verify.ts завершаются с нулевым кодом на живой базе данных при каждом запуске CI, включая SELECT, INSERT, UPDATE, DELETE, переназначение владельца, обход администратором, сценарии с нулевыми строками без контекста и регрессионные случаи утечки GUC.
3. Управление ключами и секретами
Секреты приложения, ключи подписи, учётные данные базы данных и сторонние API-ключи, используемые самой Melaya, хранятся в переменных окружения, загружаемых при запуске процесса, и в нашем провайдере хранилища. Они никогда не фиксируются в системе контроля версий, а производственные значения не разглашаются разработчикам. Ключ MEL_ENVELOPE_KEY хранится отдельно от учётных данных базы данных Postgres и отдельно от токена Infisical, поэтому компрометация любого из трёх не раскрывает учётные данные биржи в открытом виде. Клиентам настоятельно рекомендуется ограничивать каждый API-ключ биржи только торговыми разрешениями, отключать вывод средств на площадке-эмитенте и применять ограничение по IP там, где площадка это поддерживает.
Сессионные токены подписываются в рамках окна ротации нескольких ключей. Сервер принимает разделённый запятыми список ключей подписи через переменную окружения JWT_SECRETS, каждый из которых помечен коротким идентификатором. Новые токены подписываются активным (первым) ключом, а его идентификатор включается в заголовок JWT для проверки за O(1). Токены, выданные под любым отозванным ключом в окне, продолжают проверяться до истечения их семидневного TTL, после чего отозванный ключ может быть удалён. Просроченные токены отклоняются немедленно, даже если неактивный ключ в противном случае их принял бы. Процедура ротации задокументирована в server/src/services/jwtKeys.ts; циклы проверки подтверждены в server/src/scripts/jwt-keys-verify.ts.
4. Аутентификация и контроль доступа
Аутентификация пользователей основана на электронной почте и пароле с хешированием bcrypt с коэффициентом работы 12, в сочетании с ограничением частоты запросов на конечных точках входа, регистрации и восстановления пароля (20 попыток на IP за 15 минут, реализовано в процессе через express-rate-limit). Сессионные токены выдаются как JSON Web Token с семидневным сроком действия и привязаны к пользователю, роли и тарифу. Контроль доступа на основе ролей разграничивает user и admin, а контроль доступа на основе тарифа открывает функции согласно четырёхуровневому каталогу. Каждое значимое действие проверяется на стороне сервера; ограничения на стороне клиента являются исключительно подсказкой для пользовательского интерфейса и никогда не используются в качестве средства защиты.
Двухфакторная аутентификация доступна всем пользователям через стандартный профиль TOTP (RFC 6238, SHA-1, 6 цифр, период 30 секунд, допуск смещения ±1 окно) и совместима со всеми распространёнными приложениями-аутентификаторами. Общие секреты TOTP генерируются на сервере с 160 битами энтропии, оборачиваются через уровень конвертного шифрования, описанный в разделе 1, и хранятся в записи пользователя. Коды восстановления генерируются один раз при регистрации, хешируются bcrypt с коэффициентом работы 12, а затем снова оборачиваются конвертным уровнем, чтобы компрометация базы данных сама по себе не позволила их восстановить. Регистрация является двухэтапным процессом, который требует от пользователя подтверждения настройки аутентификатора путём ввода активного кода до того, как второй фактор будет отмечен как активный. Процесс входа представляет собой проверку пароля, затем кратковременный (пятиминутный) токен вызова, затем проверку кода, которая атомарно потребляет запись вызова; перехваченный токен вызова не может быть использован повторно после успешного потребления. МФА обязательна для добавления API-ключей CEX и генерации API-ключей платформы, двух действий с наибольшим влиянием на средства пользователя. Каждый результат вызова МФА (mfa.challenge_issued, mfa.challenge_ok, mfa.challenge_fail) записывается в журнал аудита только для добавления, описанный в §6, чтобы паттерны вызовов были доступны для аудита и защищены от подделки.
Доступ сотрудников Melaya к производственным системам предоставляется каждому инженеру индивидуально и отзывается, когда в нём больше нет необходимости. Устаревшие записи sudoers с NOPASSWD и авторизованные ключи SSH удаляются в рамках каждой сессии. Формальная процедура проверки доступа с ежеквартальной аттестацией и подписанными записями, а также полное разделение между пользователем развёртывания и пользователем рантайма сервиса (чтобы скомпрометированный процесс сервиса не мог перейти к пути развёртывания) отслеживаются как запланированные меры в дорожной карте безопасности.
5. Сетевое ограничение частоты запросов и инфраструктура
Ограничение частоты запросов реализовано на уровне приложения с помощью express-rate-limit с общим хранилищем на основе Redis, так что ограничения являются глобальными для всех экземпляров сервера, а не для каждого процесса. Применяются два независимо настроенных ведра: строгое ведро для конечных точек аутентификации (20 попыток на IP за 15-минутное окно) и общее ведро API (200 запросов на IP в минуту). Ограничитель работает по принципу «закрыт при сбое»: если хранилище Redis недоступно, конечные точки аутентификации отклоняют запросы, а не пропускают их. Обёртка ограничителя, учитывающая пакетную обработку tRPC, проверена в server/src/scripts/rate-limit-verify.ts (7/7 сценариев, включая атаку с подменой процедур).
Граничный трафик проходит через Cloudflare с WAF, обнаружением ботов и геоблокировкой на высокорисковых путях. Конфигурация Terraform для зоны Cloudflare зафиксирована в deploy/cloudflare/ вместе с операционным руководством, охватывающим обнаружение расхождений, аварийное переопределение и правило 24-часовой выверки; импорт и выверка текущей зоны, управляемой вручную, по отношению к этой конфигурации находится в процессе и является блокирующей задачей перед первым внешним тестированием на проникновение.
6. Мониторинг, журналирование и аудит
Платформа генерирует структурированные журналы из сервера tRPC на Node.js, движка Rust, воркера Python и пограничного уровня. Все журналы на уровне хоста и контейнера (журнал systemd, /var/log/, журналы доступа/ошибок nginx, stdout контейнеров Jenkins и Gitea и каждый файл журнала приложения Melaya) доставляются за пределы хоста в режиме реального времени в арендатора Grafana Cloud Loki в том же регионе, что и производственный хост, через коллектор Grafana Alloy, поэтому журнал аудита сохраняется при компрометации хоста или потере диска.
События, связанные с безопасностью (результаты аутентификации, результаты вызовов МФА, добавление и удаление учётных данных CEX, выдача и отзыв API-ключей платформы, изменения тарифа и откаты) дополнительно записываются в таблицу agents.audit_log, доступную только для добавления, определённую в server/sql/audit_log_schema.sql. Схема использует REVOKE UPDATE, DELETE для роли приложения, криптографическую цепочку хешей строк (prev_hash / row_hash), HMAC-SHA256 над IP актора с ключевым секретом (не обычный SHA-256, уязвимый к словарным атакам) и дополнительную таблицу agents.audit_log_tombstone для удаления по статье 17 GDPR, которая никогда не изменяет цепочку. Ежедневный верификатор (verify-audit-chain.ts) обходит всю цепочку от начала до конца, проверяет монотонность временных меток с допуском ±2 секунды по NTP и генерирует якорный дайджест, пригодный для внешнего хранилища только для записи. Шесть сценариев фальсификации в audit-log-verify.ts завершаются с нулевым кодом на живом продакшене.
7. Управление уязвимостями
Каждый коммит запускает npm audit --production и сканирование файловой системы Trivy в рамках CI. Trivy вызывается дважды при каждой сборке: один раз в режиме с защитой (ignore-unfixed: true), когда действенные находки вызывают сбой проверки, и один раз с ignore-unfixed: false и без блокировки, чтобы полная поверхность уязвимостей загружалась во вкладку «Безопасность» репозитория в качестве доказательства для SOC 2. Производственный хост запускает unattended-upgrades с включённым каналом безопасности. Сторонние образы контейнеров для Jenkins, Gitea, Infisical, Postgres и Redis проходят проверку перед обновлением версий и отслеживаются в руководстве по циклу обновлений во внутреннем хранилище безопасности.
Melaya ещё не прошла внешнее тестирование на проникновение третьей стороной. Область тестирования (включая активы в области тестирования и за её пределами, правила взаимодействия, список поставщиков и цикл устранения уязвимостей после тестирования) зафиксирована во внутреннем руководстве «Область тестирования на проникновение», чтобы выбор поставщика мог начаться сразу после завершения выверки Cloudflare IaC из §5. Никаких утверждений о «ежегодном тестировании на проникновение» в документации Melaya не делается.
8. Безопасная разработка программного обеспечения
Изменения в платформе проходят через систему контроля версий с проверкой коллегами перед слиянием. Строгий режим TypeScript и статический анализ запускаются при каждой сборке клиента и сервера. gitleaks работает как хук перед коммитом и в CI, со списком разрешений с областью действия по пути, а не глобальным, чтобы случайное раскрытие учётных данных вызывало сбой сборки до слияния. Все действия GitHub Actions закреплены по хешу коммита для предотвращения атак на цепочку поставок через перезапись тегов. Производственные развёртывания проходят через ограниченную обёртку SSH Jenkins с ограничением command= в authorized_keys, чтобы даже скомпрометированный CI-раннер мог вызывать только явные операции resync <service> и log <service> для четырёх сервисов Melaya: без произвольной оболочки, без обхода файловой системы, без повышения привилегий за пределы перезапуска сервиса. Каждый вызов конвейера развёртывания журналируется за пределами хоста в арендатора Grafana Cloud Loki для аудита.
9. Реагирование на инциденты
Melaya поддерживает письменное руководство по реагированию на инциденты, охватывающее объявление уровня критичности (SEV-0 по SEV-3), назначение ролей (IC, технический руководитель, коммуникации, секретарь), контрольный список локализации с явными шагами по ротации конвертного ключа, JWT-ключа и ключа IP-HMAC журнала аудита, матрицу уведомлений по статье 33 GDPR за 72 часа и шаблон анализа инцидентов. Руководство зафиксировано во внутреннем хранилище безопасности и является живым документом: первые учения по разбору сценариев запланированы на III квартал 2026 года, а руководство явно помечено как «не активное» в собственном §7 до проведения этих учений. Дежурные инженеры реагируют на реальные инциденты сегодня; ограничение на учения касается официальных тренировочных занятий, а не существования пути реагирования.
10. Резервное копирование и аварийное восстановление
Целевое время восстановления (RTO) и целевая точка восстановления (RPO) для каждой подсистемы опубликованы во внутреннем руководстве RTO RPO: уровень agents.* нацелен на 15-минутное RTO / 2-часовое RPO, хранилище учётных данных CEX нацелено на 5-минутное RTO / 1-часовое RPO, Infisical и объектное хранилище нацелены на 1-часовое RTO / 4-часовое RPO, Redis не резервируется и восстанавливается при переподключении. Механика резервного копирования сочетает непрерывное архивирование WAL, ежедневный логический дамп, ежемесячное базовое резервное копирование и ежедневный экспорт якоря журнала аудита только для записи во внешнее место. Первые ежегодные учения по полному восстановлению запланированы на III квартал 2026 года, и их письменное подтверждение восстановления по астрономическому времени и проверки целостности будет зафиксировано в том же руководстве.
11. Непрерывность бизнеса
Письменный план обеспечения непрерывности бизнеса зафиксирован во внутреннем хранилище безопасности и охватывает реагирование на сбой основного региона, отказ провайдера Postgres, сбой хранилища Infisical (сервер продолжает обслуживать существующие сессии через кэшированные учётные данные, новые записи CEX отклоняются с видимой пользователю ошибкой), сбой Stripe (существующие подписки не затронуты), матрицу доступности персонала и таблицу мер на случай непредвиденных обстоятельств для каждого поставщика. План пересматривается с той же ежеквартальной периодичностью, что и базовый уровень TLS.
12. Безопасность поставщиков и субобработчиков
Melaya использует ограниченный набор субобработчиков, каждый из которых выбран за его уровень безопасности. Текущие субобработчики в продакшене включают Stripe для обработки платежей, Cloudflare для пограничного TLS и WAF, самостоятельно размещённый Infisical для хранения секретов (совместно размещённый на производственном хосте, а не третья сторона), нашего провайдера хостинга Postgres, нашего провайдера хостинга Redis, нашего провайдера объектного хранилища, провайдеров транзакционной электронной почты и Grafana Labs для внебоксового сбора журналов и метрик в Grafana Cloud (тот же регион, что и производственный хост, аттестовано SOC 2 Type II). Клиенты, настраивающие сторонних провайдеров языковых моделей, фактически добавляют этих провайдеров в качестве субобработчиков для конвейеров, которые они через них маршрутизируют; эти провайдеры находятся в сфере ответственности клиента и не охватываются контрактами Melaya с поставщиками. Канонический список субобработчиков поддерживается во внутреннем хранилище безопасности с обязательством уведомления за 15 дней для корпоративных клиентов. Публичная версия публикуется на melaya.org/legal/subprocessors при запуске фронтенда.
13. Статус соответствия
Melaya выстраивает свои меры контроля с учётом Критериев доверительных услуг SOC 2 и ISO/IEC 27001. На дату настоящего документа Melaya НЕ имеет SOC 2 Type I, SOC 2 Type II, ISO/IEC 27001 или какой-либо эквивалентной сторонней аттестации безопасности. Это перспективные цели на нашей дорожной карте. Любой потенциальный клиент, которому сегодня требуется аттестация, должен ожидать результатов анализа пробелов, а не готового отчёта. Корпоративные клиенты могут запросить нашу текущую матрицу мер контроля и список устраняемых недостатков, обратившись по адресу [email protected].
Шаблон Соглашения об обработке данных из пятнадцати разделов подготовлен и зафиксирован во внутреннем хранилище безопасности. Он включает Стандартные договорные условия Европейской комиссии (Модуль 2 для отношений контролёр-обработчик и Модуль 3 для отношений обработчик-обработчик), Дополнение к международной передаче данных Великобритании и эквивалент швейцарского FADP. Обязательство об уведомлении об утечке за 72 часа по статье 33 GDPR, процедура возврата или удаления данных и права на аудит (ограниченные ежегодным и конфиденциальным SOC 2 Type II после его получения) закреплены в шаблоне. Проверка внешними юристами ожидается до того, как Соглашение будет предложено в форме, принимаемой кликом, для платных тарифов и в виде версии для двустороннего подписания на тарифе Citadel.
14. Ответственность клиентов
Безопасность в Melaya является общей. Клиенты несут ответственность за выбор надёжных уникальных паролей, защиту своих учётных данных, ограничение API-ключей биржи минимально необходимыми разрешениями, проверку и валидацию поведения создаваемых конвейеров, контроль над контентом, загружаемым в индексы извлечения, ознакомление с условиями и практиками обработки данных любых сторонних провайдеров языковых моделей, через которых они маршрутизируют запросы, и незамедлительное сообщение о любой подозреваемой компрометации. Мы настоятельно рекомендуем включить двухфакторную аутентификацию в настройках аккаунта при первом входе; она обязательна перед добавлением любых учётных данных CEX или генерацией любого API-ключа платформы и является единственной наиболее эффективной мерой безопасности, которую клиент может применить к своему аккаунту.
15. Ответственное разглашение и безопасная гавань
Безопасная гавань. Melaya, Inc. не будет преследовать в судебном порядке или поддерживать любые действия третьих сторон против исследователей безопасности, действующих добросовестно и соблюдающих настоящую политику. Это обязательство распространяется на требования, которые Melaya могла бы предъявить в соответствии с Законом США о компьютерном мошенничестве и злоупотреблениях (CFAA), Законом Великобритании о неправомерном использовании компьютеров, соответствующими положениями законов государств-членов ЕС о неправомерном использовании компьютеров, а также любыми гражданско-правовыми требованиями о нарушении договора, незаконном вмешательстве или вторжении в имущество. «Добросовестность» означает, что исследователь предпринял искренние усилия для соблюдения области применения и правил взаимодействия ниже, не получал доступ, не изменял, не уничтожал и не извлекал данные других пользователей, не деградировал намеренно Сервисы для других пользователей и сообщил о результатах в частном порядке по адресу [email protected] до любого публичного раскрытия. Это положение является обязательным для Melaya и не требует одобрения для каждого отчёта. Оно не распространяется на поведение, которое является независимо незаконным в юрисдикции исследователя, например, на фактическое финансовое мошенничество против других пользователей или вымогательство.
Область применения. Тестирование разрешено в отношении melaya.org и всех поддоменов в зоне *.melaya.org, поверхности приложения на app.melaya.org, конечных точек Builder API и юридических страниц Melaya. Тестирование НЕ разрешено в отношении: (i) размещения, отмены или изменения реальных ордеров на любой сторонней бирже, доступной через Melaya; (ii) сторонних провайдеров языковых моделей (OpenAI, Anthropic, Google, Cohere, локальные рантаймы), доступных через настроенный пользователем конвейер; (iii) самой инфраструктуры Cloudflare, провайдеров хостинга или хранилища; (iv) любых форм атак типа «отказ в обслуживании» (L3/L4 флуд, L7 флуд, подбор учётных данных в больших объёмах); (v) социальной инженерии сотрудников, подрядчиков или клиентов Melaya; (vi) физического проникновения.
Правила взаимодействия. Исследователи должны прекратить тестирование, как только находка доказана (одного неразрушающего чтения достаточно как доказательства межарендаторского доступа), никогда не изменять и не извлекать данные других пользователей, не устанавливать механизмы постоянного присутствия и поддерживать автоматизированное тестирование на уровне менее 1 запроса в секунду в среднем. Трафик тестирования должен содержать заголовок User-Agent: Melaya-research/<handle>, чтобы Melaya могла отличить его от реального трафика и не оповещала дежурного.
SLA по сортировке. Melaya обязуется подтверждать получение обоснованных отчётов в течение пяти (5) рабочих дней с момента получения, предоставлять первоначальную оценку критичности в течение десяти (10) рабочих дней с момента подтверждения и устранять находки согласно шкале критичности: Критические в течение 48 часов, Высокие в течение 7 календарных дней, Средние в течение 30 календарных дней, Низкие по возможности. Если Melaya нарушает обязательство по SLA, исследователь может направить письменное уведомление о намерении опубликовать за семь (7) дней, и защита «безопасной гавани» сохраняется в течение всего срока публикации при условии, что исследователь соблюдал правила взаимодействия.
Контакты. Отчёты следует направлять на [email protected]. PGP-ключ для зашифрованных отчётов будет опубликован на /.well-known/security.txt. Отчёты не следует направлять через социальные сети, задачи GitHub в публичных репозиториях Melaya или любые поверхности чата поддержки: эти каналы не отслеживаются для контента, связанного с безопасностью, и создают риск случайного публичного раскрытия до устранения уязвимости.
Настоящий Раздел 15 является самодостаточным, и его обязательства являются обязывающими. Защита «безопасной гавани» в первом пункте, область применения и правила взаимодействия во втором и третьем пунктах, SLA по сортировке в четвёртом пункте, А ТАКЖЕ правила взаимодействия с Условиями использования и правила изменений только в перспективе в следующем пункте вместе составляют полный набор обязательств, обязывающих Melaya в отношении исследователей безопасности. Каждый пункт в настоящем Разделе 15, а не только первые четыре, является частью обязывающего набора обязательств. Melaya ведёт внутреннее операционное руководство по маршрутизации и эскалации сортировки, но это руководство не добавляет, не убирает и не изменяет каких-либо обязательств в настоящем Разделе 15, и исследователю не нужно читать какой-либо другой документ, чтобы опираться на приведённую выше «безопасную гавань». Любые изменения в настоящем Разделе 15 применяются только в перспективе: находка, сообщённая добросовестно в соответствии с версией настоящего Раздела 15, действовавшей на момент подачи отчёта, остаётся защищённой «безопасной гаванью» этой версии независимо от любых последующих поправок.
Взаимодействие с Условиями использования (обязывающее). Настоящий Раздел 15 представляет собой явное разрешение Melaya на деятельность по исследованию безопасности, которая в противном случае была бы ограничена запретами Условий использования на обход, отключение или вмешательство в функции безопасности, ограничения частоты запросов или контроля доступа Melaya. Исследователь, действующий в рамках области применения и правил взаимодействия выше, следовательно, не нарушает Условия в отношении этих действий, и Melaya отказывается от любых требований, которые она могла бы предъявить в соответствии с Условиями в отношении этих конкретных действий. Настоящий пункт сам по себе является частью приведённого выше обязывающего набора обязательств и не является просто текстом толкования.
16. Изменения в настоящем обзоре
Melaya может периодически обновлять настоящий обзор безопасности для отражения изменений в платформе, наших мерах контроля или субобработчиках. Дата «Последнего обновления» в верхней части настоящего документа отражает последнюю редакцию. Когда ожидающие операционные задачи (такие как первые учения по восстановлению, первые учения по разбору сценариев реагирования на инциденты, первое внешнее тестирование на проникновение или проверка шаблона Соглашения внешними юристами) завершаются, соответствующий раздел переписывается для отражения нового состояния, а изменение объявляется в журнале изменений продукта.
17. Контакты
По вопросам безопасности, отчётам об уязвимостях или для запроса документации о соответствии, пожалуйста, обращайтесь: