За 26 лет работы в Cisco над созданием систем безопасности и криптографических сервисов я столкнулся с длинным списком дефектов в протоколах и системах. Лишь малая часть криптографических сбоев, которые я видел, была вызвана взломом алгоритма. Гораздо чаще системы дают сбой в промежутке между появлением исправления и его внедрением.
Этот промежуток — «последняя миля» доверия. Именно здесь патч, опубликованный разработчиками, доходит до глобального портфеля продуктов лишь спустя месяцы. Именно здесь встроенное устройство поставляется с криптографической библиотекой, которая никогда не будет обновлена за весь срок службы. Именно здесь исправление беспрепятственно проходит через четыре уровня цепочки поставок и тихо застревает на пятом.
Математика — это то, что мы в основном решили. Логистика — это то, что мы еще нет.
Две силы, противоположные стороны
Сейчас две силы одновременно испытывают на прочность эту «последнюю милю».
Что касается обнаружения уязвимостей, ИИ увеличил разрыв между поиском ошибок и их исправлением. Хотя передовые модели значительно снизили барьер для поиска уязвимостей, их устранение по-прежнему зависит от квалифицированного человеческого суждения при сортировке, написании патчей, проверке, выпуске и развертывании. Обнаружение масштабируется вместе с вычислительными мощностями. Исправление масштабируется вместе с количеством сотрудников. Эти кривые расходятся, и каждый отчет, лежащий в очереди у мейнтейнера, — это исправление, которое еще не начало свой путь по «последней миле».
Что касается развертывания, миграция на постквантовую криптографию (PQC) — это не разовое событие. Это последовательность событий, выполняемых в условиях нехватки времени, с учетом стандартов и выбора протоколов, которые все еще проходят проверку в реальных условиях эксплуатации. Некоторые ранние решения придется пересмотреть. Это не пессимизм, это природа масштабных изменений.
Вместе эти силы определяют главную проблему безопасности этого десятилетия. Криптографический риск теперь определяется не столько стойкостью наших алгоритмов, сколько скоростью наших конвейеров изменений.
Недостающий элемент контроля: потенциал вышестоящих проектов
Cisco определяет криптографическую гибкость как способность обновлять криптографические алгоритмы, протоколы, библиотеки и реализации, минимизируя при этом сбои и избегая ненужной замены базовой инфраструктуры. На практике она опирается на четыре компонента:
- Абстракция: криптографические параметры настраиваемы, а не жестко закодированы.
- Инвентаризация: вы знаете, какие системы используют какие примитивы.
- Скорость конвейера: вы можете быстро переместить изменения от разработчика к конечному продукту.
- Потенциал вышестоящих проектов (Upstream capacity): проекты, от которых вы зависите, могут быстро предоставлять новые возможности и критические исправления.
Большинство организаций инвестируют в первые два пункта и принимают последние два как должное. На самом деле, именно на последних двух этапах миграции чаще всего терпят неудачу.
Потенциал вышестоящих проектов — это то, что почти никто не включает в дорожную карту, потому что это находится за пределами вашей организации. Почти каждое безопасное соединение, которое вы установили сегодня, от банковских операций и электронной почты до API-рукопожатий за вашими приложениями, зависело от криптографического кода, поддерживаемого небольшой командой от имени всего интернета. Вы не сможете закрыть «последнюю милю», если у вышестоящего проекта нет ресурсов для создания исправления в первую очередь.
У каждой другой части вашей цепочки поставок криптографии есть владелец, бюджет и цель контроля. В большинстве организаций у вышестоящих проектов нет ничего из этого. Есть только предположение, а предположения — это не контроль.
Поэтому измените вопрос, который задает ваша программа. Ваш спецификационный состав программного обеспечения (SBOM) уже говорит вам, какое открытое ПО вы используете. Более сложный вопрос: что мы возвращаем в проекты, без которых не можем работать? Если честный ответ — «ничего», то это находка. Она должна быть в вашем реестре рисков наряду с любой другой неуправляемой зависимостью.
Как это выглядит на практике
Для Cisco частью ответа стало получение статуса Premier Sponsor фонда OpenSSL Foundation в августе 2025 года. Трехлетнее обязательство финансирует штатного инженера фонда и прикомандированного инженера Cisco. Их работа сосредоточена на фундаментальной инженерии, QUIC, постквантовой криптографии и DTLS 1.3. Мы рассматриваем это как снижение риска цепочки поставок с прямой связью с нашей собственной скоростью развертывания, а не как благотворительность.
Томаш Мраз, технический директор OpenSSL Foundation, описывает эффект:
«Поддержка Cisco фонда OpenSSL позволила нам профинансировать дополнительного старшего инженера-программиста для улучшения кода библиотеки OpenSSL. Игорь Устинов, чья должность частично финансируется Cisco, помогает команде справляться с возросшей нагрузкой, вызванной ростом количества отчетов о безопасности и ошибках, генерируемых ИИ. Райан Хупер, работающий в Cisco, является ключевым участником разработки поддержки протокола DTLS 1.3. Оба уже стали коммиттерами OpenSSL благодаря высокому качеству своей работы».
Мраз иллюстрирует, как мейнтейнер поглощает последствия обнаружения уязвимостей в масштабах ИИ. Разрыв между поиском и исправлением превратился в рабочую нагрузку на столе конкретного человека. Оба инженера также стали коммиттерами благодаря качеству своей работы, а не тому, кто их финансирует. Влияние в вышестоящем проекте зарабатывается в кодовой базе, а не в спонсорском соглашении.
Длительность важна так же, как и деньги. Фонд может нанимать сотрудников под трехлетнее обязательство, но не под разовый грант. Устойчивый вклад финансирует человека, а именно люди разбирают очереди на сортировку.
С чего начать
Вам не нужен бюджет на спонсорство, чтобы внести свой вклад. Почти каждому доступны три шага:
- Измерьте свою «последнюю милю». Сколько дней требуется исправлению, чтобы пройти путь от выпуска вышестоящего проекта до вашей производственной среды? Если вы не можете ответить, начните с этого. Эта цифра станет вашим бизнес-обоснованием, и это лучший доступный предиктор того, как пройдет ваша миграция на PQC.
- Передавайте в вышестоящие проекты то, что вы используете в частном порядке. Каждый патч, который вы поддерживаете в частном порядке, — это вклад, который вы решили не делать, и повторяющиеся инженерные расходы, которые вы решили сохранить. Форки — это проблема «последней мили», ставшая постоянной. Передача кода, который вы уже написали, в вышестоящий проект часто является вкладом с самой высокой отдачей и не требует нового бюджета.
- Выберите один вид вклада, который вы можете поддерживать. Варианты включают проверку кода, сортировку, покрытие тестами, тестирование взаимодействия в производственном масштабе, мощности CI, документацию или прикомандированного инженера. Устойчивый и скромный вклад всегда лучше, чем крупный и эпизодический.
Математика устоит. Открытый вопрос заключается в том, сможем ли мы выпускать обновления достаточно быстро, чтобы не отставать от нее, и ответить на него мы можем только коллективно. Измерьте свою собственную «последнюю милю», а затем внесите вклад в чужую.
