Оглавление:
Видео: Как мы теряем и зарабатываем деньги? (Ноябрь 2024)
19 июля 2019 года программист по контракту Дэвид Тинли признал себя виновным по обвинению в умышленном повреждении компьютеров, принадлежащих корпорации Siemens. Согласно заявкам по делу, Тинли заложил логические бомбы в код, который он разрабатывал для Siemens в своем офисе в Монровиле, штат Пенсильвания. Эти логические бомбы, представляющие собой фрагменты кода, которые были рассчитаны на то, чтобы создавать сбои через недели или месяцы после завершения проекта, были предназначены для того, чтобы Tinsley имел постоянный поток доходов от необходимости исправлять проблемы, которые, как предполагалось, были ошибками. Когда его вызвали, чтобы исправить проблему, Тинсли просто изменил дату на логической бомбе, чтобы она снова сработала позже.
Найм резервных кодеров
Итак, почему я говорю вам все это? В конце концов, шансы, что вы можете нанять программиста, который намеренно помещает логические бомбы в ваш пользовательский код, невелики. И хотя эти шансы не равны нулю, существует множество других вещей, которые могут пойти не так, когда кто-то пишет код для вашей организации.
"Что произойдет, если этот человек уйдет или упадет замертво?" спрашивает Джек Голд, главный аналитик в J. Gold Associates. Золото предполагает, что когда вы нанимаете кого-то для разработки, вам всегда нужна резервная копия. В конце концов, пользовательский код - это ваш код. Нет третьей стороны, к которой вы можете обратиться, если что-то пойдет не так, если вы не планируете это. Он также предположил, что есть несколько других шагов, которые компании должны сделать, чтобы защитить себя в процессе разработки, главными из которых являются обязательные проверки кода.
«Обзор кода - это, вероятно, лучший способ выяснить, что находится в вашем коде, - говорит Алан Цейчик, главный аналитик Camden Associates, - включая такие вещи, как логические бомбы, уязвимости в системе безопасности или глупые ошибки».
«Есть и другие причины для проверки кода», - добавил Зейчик. «Это помогает вашей команде разработчиков лучше понять, как работает разработка, помогает младшим программистам лучше понять. Обзоры кода также полезны для того, чтобы помочь руководителю группы разобраться в качестве команды разработчиков и оценить, как долго это займет, чтобы закончить работу.
Ведение Кодекса Обзоров
Зейчик сказал, что есть несколько способов провести проверку кода. «У вас может быть команда, в которой работают два человека, или вы можете встретиться в конференц-зале для проверки кода».
Группы, в которых каждый участник просматривает чужой код, становятся все более популярными, так как программистам становится все труднее найти. Но в более крупных организациях периодические встречи для проверки кода по-прежнему полезны, потому что тогда несколько групп людей могут помочь в процессе проверки. Зейчик сказал, что даже самые старшие программисты должны пересмотреть свой код.
Итак, почему Siemens позволил Tinley все эти годы работать без проверки кода? Согласно комментариям его адвоката в ходе судебного разбирательства, Тинли считал свой кодекс частным и использовал это в качестве оправдания, чтобы не пересматривать его код.
Непонятно, почему это было разрешено, но и Zeichick, и Gold указывают, что требование пересмотра кода должно быть частью любого контракта между бизнесом и независимой организацией по программированию. Золото предполагает, что в контракте не только упоминаются кодовые обзоры, но и указывается, как и когда они происходят.
Зейчик отметил, что некоторые крупные магазины разработчиков могут делать свои собственные обзоры кода, что, по его словам, имеет смысл. «Лучшие люди, которые проводят анализ кода, - это люди из команды разработчиков», - сказал он.
Избежание вредоносных кодеров
Обзоры кода были почти всегда. Когда я руководил командой программистов для большого правительственного учреждения, мы каждую пятницу пересекали ошеломляющие строки COBOL. Хотя это было утомительно, мы часто находили упущения, ошибки, неуместные ссылки или другие ошибки кодирования. Дело в том, что мы все совершаем ошибки, а разумный обзор делает код лучше для всех.
К сожалению, программисты иногда возмущаются обзорами кода, полагая, что это пустая трата времени. Другие говорят, что не хотят, чтобы люди перебирали свой код. Но факт, что отказ в разрешении пересмотра кода должен быть красным флажком. Если вы платите за код, который будет написан, то ваш контракт может разумно включать требование для обзоров. Отказ от этого является причиной для увольнения.
К сожалению, найти хороших программистов в наши дни сложно. Спрос высок, и в некоторых случаях программисты-контрактники считают, что могут указать, что им не нужно соглашаться на пересмотр своего кода, даже если их контакт говорит, что так и будет.
Лучший способ избежать таких проблем - это сначала попросить, а затем вызвать ссылки на предыдущую работу. Во-вторых, провести проверки кода с первого дня. Таким образом, они становятся привычкой, и программисты, отказывающиеся от обзоров, могут быть немедленно уволены, прежде чем они станут критически важными для процесса разработки.
- Что делать, когда тебя взломали Что делать, когда тебя взломали
- 6 вещей, которые нельзя делать после взлома данных 6 вещей, которые нельзя делать после взлома данных
- Флорида-Сити заплатит 600 000 долларов хакерам после атаки вымогателей Флорида-Сити заплатит 600 000 долларов хакерам после атаки вымогателей
К сожалению, риски в процессе разработки могут быть велики. Голд отмечает, что неэтичный программист может вставить секретные данные в ваш код, найти способы украсть данные о ваших клиентах или интеллектуальную собственность или передать важные данные другой компании или иностранному источнику.
Способ предотвратить это - постоянно управлять, проверять рабочий продукт вашего программиста и проверять код, прежде чем он будет принят вашей системой управления кодом.