Barry O’Donovan: роль по CRA зависит от продукта

Кратко

CRA учитывает, как поставляется конкретный продукт и кто поддерживает его на постоянной основе. По словам Barry O’Donovan, организация может выступать куратором открытого ПО (open-source software steward в тексте CRA) для бесплатной версии и производителем платной.
Статус некоммерческой организации сам по себе классификацию не решает. Операторам по-прежнему нужны перечень продуктов, контакт для сообщений об уязвимостях и понятный путь к исправлению.

Один проект может бесплатно распространять открытый код и продавать расширенную версию. CRA может отнести эти продукты к разным ролям. Практический вывод Barry O’Donovan прост: роль следует за продуктом, а не за названием организации.

O’Donovan отвечает за разработку IXP Manager в INEX. На RIPE 93 в докладе о цепочках поставок программного обеспечения он сформулировал вопрос операторов: если сеть или точка обмена зависит от открытого ПО, какой работы по безопасности можно ожидать от проекта, который его выпускает?

В действующих разъяснениях Европейской комиссии разделены производитель и куратор открытого ПО. Производитель, который выводит открытый продукт на рынок, несёт обязанности производителя. Юридическое лицо, которое не выводит продукт на рынок, но систематически и длительно поддерживает конкретный продукт с открытым кодом, предназначенный для коммерческой деятельности, и играет главную роль в обеспечении его жизнеспособности, может относиться к категории куратора открытого ПО. Для этой категории предусмотрены политика кибербезопасности, работа с уязвимостями и взаимодействие с органами надзора за рынком.

O’Donovan разобрал привычную модель: проект бесплатно предлагает открытую версию, а за дополнительные функции берёт плату. По его объяснению, организация может быть куратором открытого ПО для бесплатного продукта и производителем платного. Комиссия также связывает правила с конкретными продуктами и способом их поставки. Это точнее, чем навешивать один постоянный ярлык CRA на фонд, компанию или команду разработчиков.

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

В качестве примера O’Donovan привёл IXP Manager. По его словам, INEX считает проект соответствующим категории куратора открытого ПО и опубликовала политики безопасной разработки и раскрытия уязвимостей после запросов других точек обмена, которым нужны материалы для проверки цепочки поставок. Он также отметил, что INEX является некоммерческой организацией и взимает плату за порты обмена. Это операционная трактовка INEX, а не решение надзорного органа о статусе IXP Manager. Опубликованные критерии всё равно требуют оценивать продукт и фактическую роль организации.

Операторы, на которых распространяется NIS2, продолжают отвечать за собственную цепочку поставок. Статья 21 охватывает безопасность поставщиков, приобретение, разработку и обслуживание систем, включая обработку и раскрытие уязвимостей. O’Donovan рекомендовал вести перечень ПО, отслеживать уязвимости и устанавливать сроки выпуска исправлений.

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