Статья, недавно появившаяся на TechRepublic, вселит страх в сердце всех разработчиков и производителей программного обеспечения: должны ли разработчики быть привлечены к ответственности за дыры в безопасности?
Вопрос был задан исследователем безопасности Кембриджского университета доктором Ричардом Клейтоном. Потери безопасности программного обеспечения обходятся в миллиарды в год, и он хочет, чтобы поставщики взяли на себя ответственность за ущерб, вызванный недоработками в их приложениях. Он утверждает, что компании не должны полагаться на лицензионные соглашения с конечным пользователем, которые не несут ответственности.
Хотя законодательство не было принято, комитеты в Великобритании и Европе рассматривали это требование в течение нескольких лет. Клейтон хочет, чтобы приложения оценивались, чтобы определить, проявил ли разработчик небрежность. Он утверждает, что угроза судебного иска послужит стимулом для минимизации дыр в безопасности:
Если вы спустились на угол вашей улицы и начали продавать гамбургеры прохожим, они могут подать в суд на вас [в случае пищевого отравления].
Это не будет легко. Будут много стонов от всех в [отрасли], и нам придется делать это на глобальной основе и в течение многих лет.
Понятно, что индустрия программного обеспечения отбивалась с нескольких точек зрения:
- Никто специально не делает небезопасное программное обеспечение, но сложность кода может привести к непредвиденным ошибкам.
- Когда дом ограблен, жертва обычно не просит изготовителя двери или окна дать им компенсацию.
- Законодательство будет сдерживать инновации, а производители будут препятствовать функциональной совместимости приложений для защиты от нежелательных результатов.
- Кто будет нести ответственность за программное обеспечение с открытым исходным кодом?
Litigious Lapses
Основная задача Клейтона — дыры в безопасности, но что это значит? Ошибок. Неважно, вызваны ли они неопытностью кодера, отсутствием тестирования или непредвиденными обстоятельствами из-за комбинации факторов.
Однако законодательство сформулировано так: если кто-то может подать в суд на проблемы безопасности, он может подать в суд на любую ошибку. Произошел ли сбой приложения до того, как вы сохранили 20 часов ввода данных? Достигнуто ли сообщение электронной почты или твиттера непреднамеренным получателем? Разве Angry Birds вызвали беспокойство, не обновив свой рекорд?
Бюргерса против Браузеров
Давайте использовать аналогию бургера Клейтона. Приготовление гамбургера включает в себя поиск мяса хорошего качества (хорошо — приемлемого качества) и выбрасывание того, что прошло лучше его. У вас не будет проблем, если ингредиенты будут охлаждаться до тех пор, пока они не потребуются, а затем будут готовиться при достаточно высокой температуре в течение достаточно длительного времени.
Я не хочу ругать индустрию быстрого питания, но есть дюжина переменных, и вы имеете дело только с двумя или тремя одновременно. Почти все это здравый смысл — если мясо плохо пахнет или выглядит зеленым, оно не годится для потребления человеком. Бургер стоит пару долларов, но есть плохой, и он вас убьет.
Давайте сравним это с веб-браузером. Консервативно, приложение просмотра может иметь 10000 переменных. Линейного пути нет, и каждая переменная может использоваться в разное время по-разному в зависимости от ситуации. Браузер работает в операционной системе, которая может содержать миллион строк кода и еще 100 тысяч переменных. Он также может взаимодействовать с другим программным обеспечением и работать на процессоре со своими собственными наборами команд. Это сложно.
Тем не менее, браузер является полностью бесплатным в момент использования. Это может быть худшее приложение, когда-либо написанное. Вы можете потерять время, деньги и волосы. Но никто не умрет . Есть риски, но перевешиваются ли они коммерческими преимуществами?
Терминальное программное обеспечение
Можно ограничить недостатки программирования. Рассмотрим программное обеспечение для авионики: ошибка, из-за которой самолет упал с неба, приведет к смерти. Неудача недопустима.
Разработка программного обеспечения для самолетов является жесткой, полностью документированной, оптимизированной для обеспечения безопасности, тщательно протестированной, проверенной другими группами и регулируемой законодательством. Это требует значительного времени, усилий и сосредоточенности. Аэробус не будет требовать классной новой функции в процессе кодирования. Boeing не будет перестраивать интерфейс управления за неделю до развертывания.
Программное обеспечение невероятно сложное, но это одно большое приложение, работающее в закрытой системе. Стоимость разработки астрономическая, но неудачи все же случаются. Они редки, но невозможно протестировать бесконечное множество ситуаций за конечный период.
Оценка халатности разработчика
Есть только один способ научиться программированию: сделать это. Учиться на своих ошибках является фундаментальной частью этого процесса. Вы никогда не прекращаете учиться. И вы все еще делаете ошибки. Я смущаюсь, когда проверяю код, написанный на прошлой неделе … приложения, написанные десять лет назад, пугают меня до чертиков.
Хотя образование — это начало, нужно время, терпение и решение реальных проблем, чтобы стать великим разработчиком. Как вы могли бы получить этот опыт, если вам не платили? Если вам платят, понятно, что кто-то использует ваше программное обеспечение.
Тот, кто думает, что приложения могут быть безупречными, никогда не писал программы. Даже если ваш код совершенен, используемая вами среда не будет. Также не компилятор / интерпретатор. А как насчет базы данных, веб-сервера, операционной системы или набора внутренних процессоров?
Но давайте предположим, что юристы нашли способ юридически оценить халатность разработчиков. Кто в здравом уме хотел бы стать программистом? Меньше людей войдут в профессию, и суточные ставки увеличатся. Те разработчики, которые готовы принять риск, должны будут придерживаться авиационных стандартов и платить огромные страховые взносы. Стоимость программного обеспечения будет расти в геометрической прогрессии и станет дорогой роскошью для немногих привилегированных.
Предложение Клейтона может быть благонамеренным, но оно не учитывает последствия. Его предложенное законодательство убило бы индустрию программного обеспечения. Как ни странно, это решило бы все недостатки безопасности — возможно, это сделало бы его счастливым?