Чи повинні ви коли-небудь випустити щось, що ви самі могли зламати?

Будучи автором програми, ви, мабуть, перебуваєте в кращому становищі, ніж хто-небудь, щоб знати про вразливості безпеки та потенційні хаки. Якщо ви знаєте про вразливість системи, про яку ви писали, це знак, що підвищена безпека ОБОВ'ЯЗКОВО додаватись до випуску, чи це слід оцінювати у кожному конкретному випадку для визначення ступеня вираженості розриву в безпеці?

Я б сказав, що це слід робити в кожному конкретному випадку. Ви автор, ви знаєте багато дірок. Деякі вразливості вам можуть бути відомі лише вам Звичайно, це означає, що якщо будь-який з них експлуатується, у вас можуть виникнути складні запитання, щоб відповісти, тому може бути корисною мірою зменшити ці вразливості. Більш важливо, якщо хтось може легко зламати його як систему blackbox.

У мене був нещасний досвід опинитися в ситуації двічі. Бізнес в обох випадках випускав продукти з серйозними проблемами безпеки із дуже чутливими даними.

В обох випадках бізнес, здається, не хвилювався, незважаючи на мої всі зусилля, щоб довести їх до відома ризиків, які вони беруть на себе.

Єдине, що ви можете зробити, це протестувати якомога голосніше * (і професійно), будучи максимально чіткими щодо можливих наслідків, і поки ви це все документуєте . Роздрукуйте свої відповідні електронні листи в PDF-файлах і зберігайте ці файли вдома, або скопіюйте свою особисту адресу електронної пошти, або як це зробити. Це єдине рішення, коли неминуче трапляється щось погане.

Ви сподіваєтесь, що керівництво поважатиме вас за вашу технічну пораду, і враховує це, але, на жаль, ви повинні поважати того, хто приймає рішення в кінці дня. Погані ділові рішення приймаються щодня.

Редагувати: Jasonk згадав: "Будьте дуже обережні до домашньої адреси", і я дуже згоден. Будь ласка, не порушуйте політику компанії та ризикуйте відкрити вразливість безпеки більшою мірою, ніж це вже є.

Я заперечую протилежне - будучи творцем, ви часто занадто близько до коду, щоб побачити вразливості.

Якщо ви знаєте або вам відомо про вразливості, вони, як і будь-яка інша помилка - оцініть, встановіть пріоритети, а потім виправте.

Я думаю, що відповідь залежить від ступеня шкоди, яка була б внаслідок, якщо систему зіпсував зловмисний хакер. Очевидно, будівельний інженер не міг по-доброму сумлінно схвалити конструкцію небезпечного моста. Побудова такого мосту може призвести до травм або загибелі. Також інженеру було б незаконно свідомо робити це, але той факт, що інженери програмного забезпечення (принаймні в США) не мають юридичної сили так само, не звільняє їх від професійного обов'язку зайняти позицію проти несправних систем. На жаль, для випуску програмного забезпечення вашій компанії може не знадобитися ваш підпис.

Ви не вказуєте точну природу системи, над якою працюєте. Якщо це стосується медичних записів, банківської справи, контролю повітряного руху чи іншої реально важливої ​​інфраструктури, я б сказав, що ви будете добре виправдані, щоб наполягати на найвищому рівні безпеки перед випуском.

Так, ПОТРІБНО це виправити до виходу релізу. Ніколи не варто недооцінювати винахідливість хакера. Ви б поїхали у відпустку на тиждень із широко розкритими задніми дверима? Чи буде ваше виправдання,

"Ой ззаду, і вона не стикається з вулицею безпосередньо. Ніхто не побачив би, щоб вона широко розкрита .."

Напевно, ні.

Але я розумію в ці дні з нечітким прем'єр-міністром, наскільки найсвятіша дата звільнення важливіша, ніж потенційно величезна проблема відповідальності щодо безпеки. Якщо це ваш випадок, то я пропоную звернути його на увагу, зареєструйте проблему, переконайтесь, що вона добре задокументована, добре відома та ризики чітко пояснені, і дозвольте прем’єр-міністру вирішити, що робити.

Якщо прем'єр-міністр ухвалить неправильне рішення і вирішить проігнорувати це і продовжити звільнення за графіком, тоді ви звільнені від відповідальності, оскільки ви зірвали свисток.

В іншому випадку, якщо ви знайдете це і потримаєте це при собі, і щось трапиться, то ВАС може нести особисту відповідальність за наслідки.

Вибір за вами.