Відверто кажучи, ми намагаємось не переглядати вашу кодову базу, ми намагаємось написати інструменти, щоб зробити це для нас.
По-перше, теорія. Безпека - це вимога програмної системи, тому як і інші вимоги (функціональність, зручність, доступність, продуктивність тощо), її слід враховувати на кожному етапі робочого процесу в галузі програмного забезпечення від збирання вимог до розгортання та обслуговування. Дійсно, це можливо, і існують рекомендації, які допомагають командам програмних програм зробити це. Хоча я в основному працюю з розробниками iOS, мій улюблений опис "життєвого циклу безпечної розробки" - від Microsoft Press .
У цій моделі безпека додатків починається тоді, коли ми намагаємося вимагати від наших користувачів вимог. Нам потрібно розкрити їхні проблеми безпеки та конфіденційності, що непросто, оскільки ми - експерти, а не користувачі, і де вони розуміють свої вимоги безпеки, їм може бути важко їх висловити. Нам також потрібно виявити, яким ризикам буде піддаватися програмне забезпечення при розгортанні та який рівень ризику є прийнятним.
Ми розробляємо нашу програму, відповідаючи цим вимогам. Ми пишемо код з метою задоволення цих вимог та уникаючи додаткових ризиків, пов’язаних із помилками безпеки на рівні коду. Ми тестуємо програмне забезпечення, щоб переконатися, що наша модель його безпеки відповідає тому, що ми насправді створили, тоді ми розгортаємо програмне забезпечення таким чином, що відповідає припущенням, які ми зробили щодо навколишнього середовища, коли ми розробляли річ. Нарешті, ми надаємо підтримку та технічне обслуговування, що допомагає користувачеві керувати програмним забезпеченням таким чином, що відповідає їх вимогам безпеки, а також дозволяє їм (і нам) реагувати на нові зміни в поданих ризиках.
Добре, стільки для теорії. На практиці з причин, які дуже добре пояснюються (хоча і нетехнічним чином) в Geekonomics, і які, в основному, пов'язані з тим, як мотивуються програмні компанії, більшість вищезазначених матеріалів не відбувається. Натомість ми отримуємо це. Розробники:
- найняти охоронця або галя, який буде присутній, коли вони торгують контрактом, щоб показати, що вони "отримують" охорону.
- писати програмне забезпечення.
- найміть співробітника служби безпеки або галя, щоб перевірити програмне забезпечення перед випуском, виправити багато проблем, які виникли на кроці 2.
- зафіксувати все інше після розгортання.
Тож, чим реально займаються більшість людей із безпеки додатків, це, як ви кажете, пошук помилок. Це дійсно прославлений огляд коду, але це високоорієнтований огляд коду, який проводять люди, які є експертами у тих видах помилок, які цей огляд шукає, тому в цьому все ще має значення отримання зовнішньої допомоги. Це, звичайно, правило тетінгу: звичайно, завжди будь-хто інший, щоб перевірити, хто не був причетний до створення речі.
Якщо ми сприймемо вищезазначене як істинне, то звідси випливає, що люди, які приймають рішення про покупку, швидше за все, порівнюють "здатного хлопця з безпеки" до "знаходить багато помилок". Ті, хто змушує комп’ютери виконати роботу, знайдуть більше помилок, ніж ті, хто цього не робить, тому, звичайно, вони в значній мірі покладаються на інструменти статичного аналізу і будуть спрямовані витрачати більше часу на розширення інструментів, ніж на кодування конкретних проблем для конкретних клієнтів. Тоді ми робимо висновок, що люди із безпеки додатків швидше пишуть інструменти для читання коду, ніж для читання коду.
** Попередження: залишається особиста думка та спекуляція **
Реальність порушена. Ви помітите, що теорія забезпечення програмного забезпечення полягала у виявленні та реагуванні на ризик покластися на програмну систему, в той час як практика полягала в тому, щоб знайти якомога більше помилок. Впевнені, це все одно знизить ризик, але лише як побічний ефект. Суть гри стала менш важливою, ніж «виграти» гру, тому правила змінюються, щоб полегшити перемогу.
Що ви можете зробити як розробник програмного забезпечення щодо цього? Пограйте в гру за її оригінальними правилами. Знайдіть когось у вашій команді (бажано, власне, у вашій команді, а не підряднику, щоб вони мотивувались забезпечити довгострокові результати, а не швидку перемогу), хто розуміє важливість безпеки та навчає б'єезу з них. Покладіть на цю особу відповідальність керувати командою у забезпеченні безперервної безпеки, описаної на початку моєї відповіді.
Крім того, надайте цій особі повноваження виконувати їх . Якщо дизайн не виражає вимог безпеки, його слід переглянути. Якщо реалізація не відповідає вимогам безпеки, вона не повинна бути звільнена . Ваша особа з безпеки може зробити виклик рішення, але йому потрібно дозволити діяти за цим рішенням. Я усвідомлюю, що це може звучати як хлопець із безпеки, який говорить: "Безпека OMFG - це найважливіше", але це не те, що я маю на увазі. Якщо ваш продукт також не відповідає вимогам щодо функціональності, зручності використання або продуктивності, ви також не повинні випускати цю річ.
Чому б ти хотів це зробити? Це повинно бути дешевше: ми всі бачили (і, мабуть, цитували дешеві +10 повторень) таблицю Code Complete, де дефекти дорожчають, чим пізніше ви їх виправите, правда? Добре дефекти безпеки теж є дефектами. Я правила гри в реальному світі, більшість з них - це проблеми в вимогах, які фіксуються в обслуговуванні. Це дешево?
Гаразд, тепер що я можу як пістолет безпеки взяти напрокат? Ну виявляється, що я можу відмовитися грати за зміненими правилами. Я можу сказати розробникам, що справа в тому, щоб зменшити ризик, що це можна робити на кожному етапі, і тоді я можу допомогти їм у цьому.