DJB и безопасность при проектировании: от qmail до Curve25519

Что означает безопасность при проектировании (без жаргона)

Безопасность при проектировании означает создание системы так, чтобы распространённые ошибки было трудно допустить, а ущерб от неизбежных ошибок был ограничен. Вместо опоры на длинный чеклист («не забудьте валидировать X, санацировать Y, настроить Z…») вы проектируете ПО так, чтобы самый безопасный путь был одновременно и самым простым.

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

Почему простота снижает риск

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

Простота помогает двумя практическими способами:

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

Речь не о минимализме ради минимализма. Речь о том, чтобы держать набор поведений настолько малым, чтобы вы могли действительно его понять, протестировать и предсказать, что произойдёт при сбое.

Что охватывает этот пост (и чего не охватывает)

В этой статье приводятся конкретные примеры из работ Daniel J. Bernstein: как qmail стремился уменьшить количество режимов отказа, как мышление о константном времени предотвращает невидимые утечки, и как Curve25519/X25519 и NaCl двигаются в сторону криптографии, которой сложнее неправильно пользоваться.

Что не будет сделано: полный исторический обзор криптографии, доказательство безопасности алгоритмов или утверждение, что существует одна "лучшая" библиотека для каждого продукта. И не стоит думать, что хорошие примитивы решают всё — реальные системы по‑прежнему ломаются из‑за обращения с ключами, ошибок интеграции и операционных пробелов.

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

Кто такой Daniel J. Bernstein и почему его цитируют

Daniel J. Bernstein (часто «DJB») — математик и компьютерный учёный, чьи работы регулярно появляются в практической безопасности: почтовые системы (qmail), криптографические примитивы и протоколы (в частности Curve25519/X25519) и библиотеки, которые упаковывают криптографию для реального использования (NaCl).

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

Что инженеры заимствуют из работ в стиле DJB

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

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

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

Не биография — инженерная перспектива

Эта статья не биография и не спор о личностях. Это инженерный взгляд: какие шаблоны можно наблюдать в qmail, мышлении о константном времени, Curve25519/X25519 и NaCl, и как эти шаблоны соотносятся с построением систем, которые проще верифицировать и менее хрупки в продакшене.

qmail: практический пример проектирования с меньшим числом режимов отказа

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

Разделите работу, уменьшите радиус поражения

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

Такое разделение важно, потому что отказы становятся локальными:

• если один компонент падает, это не обязательно портит очередь или не выводит всю систему из строя;
• если в компоненте есть уязвимость, атакующий не получает сразу привилегий всех остальных частей;
• если вы можете рассуждать о компоненте в изоляции, его проще тестировать и аудировать.

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

Привычки проектирования, которые стоит перенять

qmail также демонстрирует привычки, применимые далеко за пределами почты:

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

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

Сокращение поверхности атаки через тесные интерфейсы

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

Программное обеспечение то же самое. Каждый открытый порт, поддерживаемый формат файла, административный эндпоинт, параметр конфигурации и хук плагина увеличивает число способов, которыми что‑то может пойти не так.

Тесные интерфейсы: меньшие API, меньше режимов отказа

«Тесный интерфейс» — это API, который делает меньше, принимает меньше вариаций и отвергает неоднозначный ввод. Это часто кажется ограничением, но его легче защищать, потому что меньше путей выполнения для аудита и меньше неожиданных взаимодействий.

Пример двух дизайнов:

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

Второй дизайн уменьшает то, чем атакующий может манипулировать. Он также уменьшает то, что ваша команда может по‑случаю неправильно настроить.

Почему меньше опций может быть безопаснее

Опции умножают тестирование. Если вы поддерживаете 10 переключателей, у вас не 10 поведений — у вас их комбинации. Многие баги безопасности живут в этих швах: «этот флаг отключает проверку», «этот режим пропускает валидацию», «эта старая настройка обходит лимиты». Тесные интерфейсы превращают «выбери‑своё‑приключение» в один хорошо освещённый путь.

Чеклист: где прячется сложность

Используйте это, чтобы найти поверхности атаки, которые тихо растут:

• Множество типов входных данных: несколько форматов файлов, кодировок или автоопределение формата.
• Слишком много способов доступа: лишние сетевые порты, панели администрирования, отладочные эндпоинты, вебхуки.
• Флаги фич, меняющие логику безопасности: переключатели, которые меняют валидацию, аутентификацию или криптографическое поведение.
• Подключаемость: скрипты, шаблоны, плагины или «пользовательские выражения», выполняемые во время работы.
• Режимы обратной совместимости: устаревшие протоколы, старые шифры, deprecated версии API.
• Неявные дефолты: поведение, которое меняется в зависимости от переменных окружения или отсутствия конфигурации.

Когда вы не можете сузить интерфейс, сделайте его строгим: валидируйте рано, отклоняйте неизвестные поля и держите «мощные» фичи за отдельными, явно ограниченными эндпоинтами.

Мысль о константном времени: предотвращение невидимых утечек

«Константное время» означает, что вычисление занимает (примерно) одинаковое время независимо от секретных значений: приватных ключей, nonce или промежуточных битов. Цель не в скорости, а в «скучности»: если атакующий не может соотнести время выполнения с секретом, ему намного сложнее восстановить этот секрет по наблюдениям.

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

Где скрывается переменность по времени

Даже «обычный» код может вести себя по‑разному в зависимости от данных:

• Ветвления по секретным данным: if (secret_bit) { ... } меняет поток управления и часто время выполнения.
• Поиски в таблицах с индексами из секретов: классический пример — таблица, где индекс, зависящий от секрета, вытягивает разные строки из кэша.
• Эффекты кэша и памяти: паттерны доступа, зависящие от секрета, просачиваются через CPU-кэш, page-faultы или предзагрузку.
• Инструкции с переменным временем: некоторые операции с большими числами, деление или циклы с досрочным выходом могут занимать дольше для некоторых входов.

Высокоуровневые способы аудита на предмет таймингового риска

Нужно не обязательно читать ассемблер, чтобы получить ценность от аудита:

1. Отследите влияние секрета: составьте список, какие переменные являются секретными (приватные ключи, общие секреты, теги аутентификации) и где они протекают.
2. Поищите красные флаги: ветвления, индексы массивов, циклы с условием выхода на секрете и логики «быстрый путь/медленный путь».
3. Рассматривайте зависимости как часть модели угрозы: убедитесь, что криптозависимости явно заявляют о поведении в константное время для нужных операций.
4. Тестируйте на вариативность: выполняйте операции много раз с разными секретами и измеряйте распределения; устойчивые и большие отличия — тревога.

Мышление о константном времени — не про героизм, а про дисциплину: проектируйте код так, чтобы секреты не могли управлять временем выполнения.

Curve25519 и X25519: крипто, которое старается быть труднее в неверном использовании

Эллиптическое кривое соглашение ключа позволяет двум сторонам получить одинаковый общий секрет, хотя каждая отправляет по сети только «публичные» сообщения. Каждая сторона генерирует приватное значение (секрет) и соответствующее публичное значение (можно отправлять). После обмена публичными значениями обе стороны комбинируют свой приватный элемент с публичным элементом другой стороны и получают одинаковый общий секрет. Подслушиватель видит публичные значения, но не может практически восстановить общий секрет, и стороны могут вывести симметричные ключи для приватного общения.

Почему Curve25519/X25519 стали популярны

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

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

Что даёт X25519 — и что не даёт

X25519 даёт вам соглашение ключа: помогает двум сторонам вывести общий секрет для симметричного шифрования.

Он не даёт аутентификацию сам по себе. Если вы используете X25519 без проверки, с кем вы говорите (например, сертификатами, подписями или предварительно разделённым ключом), вас всё равно могут подменить и вы будете «безопасно» говорить с неправильной стороной. Другими словами: X25519 защищает от подслушивания, но не защищает от подмены личности сам по себе.

Большая идея NaCl: меньше выбора — меньше ошибок

NaCl (Networking and Cryptography library) создан с простой целью: затруднить для разработчиков приложений случайную сборку небезопасной криптографии. Вместо шведского стола алгоритмов, режимов, правил паддинга и настроек, NaCl подталкивает вас к небольшому набору высокоуровневых операций, которые уже безопасно состыкованы.

box и secretbox как безопасные строительные блоки

API NaCl называются по тому, что вы хотите сделать, а не по тому, какие примитивы вы хотите склеивать.

• crypto_box (box): публично-ключевое аутентифицированное шифрование. Вы даёте свой приватный ключ, публичный ключ получателя, nonce и сообщение. На выходе — ciphertext, который (a) скрывает сообщение и (b) подтверждает, что оно от того, кто знает нужный ключ.
• crypto_secretbox (secretbox): аутентифицированное шифрование по общему ключу.

Ключевая выгода — вы не выбираете отдельно «режим шифрования» и «алгоритм MAC», а затем надеетесь, что правильно их скомпонуете. Дефолты NaCl обеспечивают современные, устойчивые к неверному использованию композиции (encrypt-then-authenticate), поэтому распространённые ошибки—например, отсутствие проверки целостности—встречаются гораздо реже.

Компромисс: меньше выбора против гибкости

Строгость NaCl может казаться ограничением, если вам нужна совместимость со старыми протоколами, специфичными форматов или алгоритмами, предписанными регулятором. Вы меняете «могу настроить всё» на «могу выпустить безопасное решение, не будучи экспертом по криптографии».

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

Безопасные дефолты и цена множества ручек

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

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

Как дефолты тихо создают риск

Крипто‑сбои — не всегда «плохая математика». Часто причиной становятся доступные, знакомые или простые в использовании опасные настройки.

Типичные дефолт‑ловушки:

• Слабая или предсказуемая случайность: использование некриптографического PRNG, повторное использование seed, падение на слабые источники энтропии в контейнерах/VM. Если генерация ключей зависит от ненадёжной случайности, всё, что на ней построено, уязвимо.
• Устаревшие алгоритмы, оставленные для совместимости: оставленные включёнными SHA-1, MD5 или старые размеры RSA «на случай», а затем обнаруживается, что система договорилась до них в продакшене.
• Пользовательские или необычные режимы и параметры: множество переключателей для режимов блочного шифрования, правил паддинга, обращения с nonce или самодельных схем. Чем больше выбора, тем больше способов случайно создать «выглядит как шифрование, но небезопасно».

Практическое правило: меньше опций — безопаснее

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

Когда можно, выбирайте библиотеки и дизайны, которые:

• по умолчанию используют современные, широко просмотренные алгоритмы
• удаляют устаревшие опции вместо того, чтобы прятать их в «расширенных настройках»
• делают небезопасные операции невозможными (или по крайней мере болезненно явными)

Безопасность при проектировании — частично отказ превращать каждое решение в выпадающий список.

Как выглядит «простое и проверяемое» в реальном коде

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

Что практически означает «проверяемое»

Код становится более проверяемым, когда:

• Высокая читаемость: маленькие функции, понятные имена и минимум «магии». Новому инженеру проще объяснить поток без сложной доски с исключениями.
• Наличие известных тестовых векторов: для криптографии важно иметь зафиксированные вход→выход (test vectors). Они ловят случайные изменения, которые «вроде бы работают» в обычных тестах.
• Воспроизводимые сборки: один и тот же исходник производит одинаковый бинарник, чтобы можно было подтвердить, что то, что запущено, — это то, что ревьюили.
• Аудиты возможны: не «дёшево», но ограничено — аудиторы могут покрыть важные пути, не утонув в опциях и состояниях конфигурации.

Почему простые пути кода легче ревьюить

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

1. Ревьюеры могут сосредоточиться на нескольких критичных для безопасности потоках, вместо гонки за крайними случаями.
2. Проще заметить, когда что‑то «не так» (неожиданное выделение памяти, рискованный шаг парсинга, сравнение, чувствительное к таймингу).

Лёгкий рабочий процесс верификации, который можно взять на практике

Держите всё скучным и повторяемым:

• Тесты: unit‑тесты + тест‑вектора для каждого используемого примитива; запуск в CI на каждое изменение.
• Ревью: требуйте чеклист по безопасности для изменений, касающихся ключей, случайности, сериализации и сравнений.
• Мониторинг: логируйте причины отказов на высоком уровне (без секретов), сигнализируйте о всплесках ошибок расшифровки/проверки и отслеживайте версии зависимостей, чтобы знать, когда крипто‑код под вами изменился.

Это сочетание не заменит экспертный аудит, но поднимет нижний порог: меньше сюрпризов, быстрее обнаружение и код, о котором реально можно рассуждать.

Где криптосистемы всё ещё ломаются (даже с хорошими примитивами)

Даже при выборе популярных примитивов типа X25519 или высокоуровневого API в стиле NaCl, системы ломаются в грязных местах: интеграция, кодирование и эксплуатация. Большинство реальных инцидентов — не «математика неверна», а «математика была использована неправильно».

Подводные камни интеграции (обычные виновники)

Ошибки с ключами: повторное использование долгоживущих ключей там, где ожидались эфемерные, хранение ключей в репозитории, путаница «public key» vs «secret key» просто потому, что это оба массивы байт.

Неправильное использование nonce — частый виновник. Многие схемы аутентифицированного шифрования требуют уникального nonce на ключ. Повтор nonce (из‑за сброса счётчика, гонок между процессами или предположения «достаточно случайно») может привести к потере конфиденциальности или целостности.

Проблемы с кодировкой и парсингом: base64 vs hex, потеря ведущих нулей, несовпадающая endianness или принятие нескольких кодировок, которые сравниваются по‑разному. Эти баги могут превратить «верифицированную подпись» в «верифицировано что‑то другое».

Обработка ошибок опасна в обе стороны: возвращать подробные ошибки, которые помогают атакующему, или игнорировать провалы проверки и продолжать работу.

Операционные ловушки, которые сводят на нет хорошую криптографию

Секреты просачиваются через логи, отчёты о сбоях, аналитику и отладочные эндпоинты. Ключи попадают в бэкапы, образы VM и переменные окружения, доступные слишком широкому кругу. Между тем, обновления зависимостей (или их отсутствие) могут оставить вас с уязвимой реализацией, даже если проектно решение было верным.

Чеклист смягчения (для не‑криптографов)

• рассматривайте nonce как часть дизайна: документируйте правила уникальности и тестируйте на повторное использование
• определите одну каноническую кодировку для ключей/сообщений; отклоняйте всё остальное
• fail closed: при провале верификации останавливайте выполнение и показывайте общую ошибку
• держите секреты вне логов; добавьте автоматические тесты редактирования логов
• храните ключи в менеджере секретов; делайте ротацию и ограничивайте доступ
• фиксируйте и ревьюьте крипто‑зависимости; планируйте обновления и аудиты

Как выбрать подход к криптоинжинирингу для вашего продукта

Хорошие примитивы сами по себе не делают продукт безопасным. Чем больше выбора вы открываете — режимов, паддингов, кодировок, самодельных «улучшений» — тем больше способов команды могут случайно собрать хрупкую систему. Подход security-by-construction начинается с выбора инженерного пути, который уменьшает число точек принятия решений.

Практическая схема принятия решений

Используйте высокоуровневую библиотеку (one‑shot API типа «зашифруй это сообщение для этого получателя»), когда:

• ваша команда не посвящена криптографии
• вам важны безопасные дефолты (обращение с nonce, аутентификация, форматы ключей) больше, чем гибкость
• вы хотите минимизировать «клей» кода, который может вернуть режимы отказа

Составляйте низкоуровневые примитивы (AEAD, хеши, обмен ключей) только когда:

• у вас есть ясная спецификация протокола и реальные требования совместимости
• вы можете назначить владельцев для ревью, тест‑векторов и долгосрочного сопровождения
• вы можете доказать, что не изобретаете заново протокол, который уже существует

Полезное правило: если в вашем design‑доке написано «режим выберем позже» или «мы просто будем аккуратно с nonce», вы уже оставляете слишком много ручек.

Вопросы к вендорам и внутренним командам

Требуйте конкретных ответов, а не маркетинга:

• Дизайн API: делает ли API трудными для представления небезопасные состояния? Ограничены ли размеры nonce, ключей и выбор алгоритмов?
• Дефолты: что происходит, если разработчик даёт только ключ и plaintext? Шифрование всегда аутентифицировано (AEAD), или можно случайно сделать «только шифрование»?
• Позиция по сайд‑чэнэлам: какие операции предполагается делать в константное время? Какова модель угроз по таймингу, кэшу и ветвлениям?
• Управление ключами: как генерируют, хранят, ротируют и очищают ключи? Форматы ключей явные и версионируемые?
• Аудиты и сопровождение: когда был последний независимый аудит? Как обрабатываются уязвимости? Есть ли changelog с важными изменениями по безопасности?

Гигиена инженерии, которая окупается

Относитесь к крипто как к критическому к безопасности коду: держите API маленьким, фиксируйте версии, добавляйте known‑answer‑тесты и запускайте фуззинг парсеров/сериализации. Документируйте, чего вы не будете поддерживать (алгоритмы, старые форматы) и делайте миграции вместо вечных «режимов совместимости».

Практические выводы: как применить безопасность при проектировании на этой неделе

Security‑by‑construction — это не инструмент, который вы покупаете, а набор привычек, делающих целые категории багов менее вероятными. Общая нить в инженерии в стиле DJB: держите вещи простыми, делайте интерфейсы узкими, пишите код, который ведёт себя одинаково даже под атакой, и выбирайте дефолты, которые безопасно себя ведут.

Выводы для вашей доски

• Простота — это фича безопасности. Меньше компонентов, меньше состояний и меньше ветвей конфигурации — меньше мест для неожиданного поведения.
• Тесные интерфейсы предотвращают «креативное» неправильное использование. Предпочитайте API, принимающие один корректный формат, а не множество «почти корректных» входов.
• Мышление в терминах константного времени уменьшает невидимые утечки. Даже если примитив надежен, окружающий код может утекать секреты через тайминг, ветвления или доступ к памяти.
• Безопасные дефолты лучше бесконечных опций. Каждая ручка добавляет новую комбинацию для тестирования — и обычно новый способ ошибиться.

План действий на неделю для команд

1. Инвентарь: перечислите, где у вас используется криптография (TLS, хэширование паролей, подпись токенов, обмен ключами, генерация случайных чисел). Укажите точную библиотеку и конфигурацию.
2. Замените рискованные паттерны: уберите самодельную криптографию, «умные» кодеры по кодированию/декодированию и богатые API, которые можно неправильно использовать. Стандартизируйтесь на небольшом, однозначном наборе примитивов и одном способе их вызывать.
3. Ограничьте интерфейсы: оберните вызовы крипто в узкий внутренний модуль с минимальным поверхностным API (мало параметров, типы сильные, явная валидация входа).
4. Добавьте тесты, ловящие регрессии: known‑answer‑тесты для примитивов, фузз‑тесты для парсеров и проверки «нет ветвлений зависящих от секрета» в горячих путях.
5. Заблокируйте дефолты: задайте безопасные базовые настройки в коде (не в вики) и требуйте явного ревью, чтобы отклоняться от них.

Если нужен структурированный чеклист для этих шагов, добавьте внутреннюю страницу «крипто‑инвентарь» рядом с вашими документами по безопасности (например, /security).

Примечание про «security‑by‑construction» и быстрый выпуск приложений

Эти идеи применимы не только к криптобиблиотекам — они распространяются на то, как вы строите и деплоите софт. Если вы используете workflow типа «vibe‑coding» (например, Koder.ai, где приложения создают через чат), те же принципы проявляются как продуктовые ограничения: ограничение числа поддерживаемых стеков (React на фронтенде, Go + PostgreSQL на бэкенде, Flutter на мобильных), акцент на планировании перед генерацией изменений и упрощение отката.

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