Почему VPN с открытым кодом отклоняют при закупке
Рецензент, возражающий против открытого кода, обычно защищает требование, а не вкус к лицензиям. Спросите, какое именно, и подготовьте документ, который на него отвечает.
Отказы, ссылающиеся на открытый код, редко связаны с лицензированием. Рецензент обычно защищает требование: чтобы кто-то поддерживал развёрнутый выпуск, чтобы установленную сборку можно было идентифицировать, чтобы оценка охватывала то, что подключается, или чтобы соединение можно было отозвать. Последующая дискуссия обычно отвечает на вопрос, который никто не задал.
Спросите, какое требование действует, прежде чем защищать лицензию. Ответ определяет, какой документ вам нужен.
Ярлык — это не требование
Читаемый исходный код означает, что опубликованную реализацию можно проверить. Это не значит, что её кто-то проверил, что сборка на шлюзе совпадает с опубликованной или что сопровождающий обязан вашему развёртыванию исправлением. Каждое из этого — отдельное утверждение с отдельным владельцем, и рецензент, которому нужно одно из них, не будет удовлетворён остальными. Произнести утверждение вслух обычно достаточно, чтобы изменить разговор.
Обратная ошибка так же распространена. Коммерческая лицензия не доказывает, что поддержка покрывает функцию, на которую вы полагаетесь, что оценка изучила компонент, который вы развёртываете, или что поставщик пришлёт исправление в пределах вашего окна обслуживания. Лицензирование описывает условия распространения, а закупочные решения касаются доверия. В любом случае лицензия — наименее информативная часть ответа.
Держите клиент и сервис отдельно. Аудит настольного клиента ничего не говорит о конфигурации шлюза партнёра, его поставщике идентичности или о том, как его операторы обрабатывают удаление учётных записей. Любые собранные доказательства должны соответствовать границе, которой партнёра просят доверять.
Превратите опасение в документ
Попросите утверждающего сформулировать требование одним предложением, затем назовите документ, который его удовлетворит. Именно расплывчатое заверение превращает эти разговоры в спор об идеологии.
| What the reviewer is protecting | Artifact that answers it | Who can sign it |
|---|---|---|
| The deployed release keeps getting fixes | Named maintainer, supported version list and the cadence for security releases | The operating team, with the maintainer's published policy attached |
| The build is the one that was reviewed | Package source, version string and the checksum or signature you verify at install | The team that builds or vendors the package |
| An assessment covers the right scope | Component and version assessed, findings raised, corrections made, retest date | Whoever performed the assessment |
| The access can be withdrawn | Identities granted, resources reachable, and the tested removal procedure | The service owner on the partner side |
NIST Secure Software Development Framework полезен здесь по одной узкой причине: он задаёт рамку закупочных разговоров вокруг общего словаря практик и взаимодействия с поставщиками. Это поддерживает запрос определённых доказательств вместо спора о ярлыке, и это не сертификация, которую проходит какая-либо конкретная VPN.
Обратите внимание, что делает средний столбец. Каждая строка требует документ, который либо существует, либо нет, и это превращает мнение в результат, который кто-то может предоставить или отклонить.
Отделите клиент от сервиса
Соглашение о поддержке клиентского приложения не является обязательством относительно сервера, до которого доходит ваш трафик. Прежде чем представлять доказательства, отметьте, какие части пути эксплуатирует партнёр, а какие вы эксплуатируете от его имени. Смешение двух даёт пакет документов, который выглядит основательным и ни на что не отвечает.
Если развёртывание ваше, партнёру, возможно, нужно доверять только идентичности и правилу доступа, что гораздо меньше, чем доверять всей вашей цепочке поставок программного обеспечения. Если развёртывание его, предпочитаемый вами клиент может быть несущественен, и темой становится конфигурация шлюза. Выяснение того, в каком вы случае, до второй встречи экономит один цикл рассмотрения.
Затем проверьте операционные вопросы, на которых проверки действительно проваливаются: кто удаляет учётную запись, как быстро и какие доказательства остаются после этого. Красиво документированная оценка без процедуры удаления остаётся открытой находкой.
Завершите решением, а не спором
Завершите обмен письменным результатом: принятая версия, связанные с ней меры контроля, названные операторы, ещё недостающие доказательства и дата, к которой они должны быть представлены. Всё неразрешённое следует зафиксировать как условие, а не поглощать в общее заявление об одобрении.
Если политика называет конкретный одобренный продукт, используйте путь исключения, а не выстраивайте параллельную договорённость, которую никто не санкционировал. Убедительный технический аргумент не даёт разрешения, а неофициальное развёртывание — находка, ждущая обнаружения.
Если требование действительно невозможно выполнить, перейдите к одобренной альтернативе и скажите почему. Цель упражнения — установить, на что организация может полагаться, и ясное «нет» — лучший результат, чем одобрение, которое потом никто не сможет защитить.