Як розробники можуть покращити безпеку програмного забезпечення?

Сьогодні розробники часто опиняються між каменем і наковднем. Можливо, бізнес не ставить безпеку на перше місце у своїх пріоритетах, але ми всі знаємо, наскільки вона життєво важлива – і в сучасному гнучкому робочому середовищі та середовищі DevOps розробники не можуть дозволити собі завершити додатки, а потім залишити прибирання команді безпеки.

У новому звіті Veracode, опублікованому сьогодні, стверджується, що, хоча розробники дбають про безпеку і стають кращими в цьому, потрібно ще більше працювати, в тому числі «мислити як зловмисник».

Компанія з безпеки додатків у своєму останньому керівництві для розробників про стан безпеки програмного забезпечення використала 400 000 сканованих програм за 12-місячний період з квітня 2016 по 2017 рік. З цих даних розробники задокументували лише 14.4% усіх недоліків. з цієї кількості лише 25% були помилковими – іншими словами, проблеми, яких насправді не було, або «ігри в систему», як сказано у звіті.

Однак це не означає, що безпека програми настільки висока, наскільки могла б бути. Порівнюючи з топ-10 уразливостей OWASP – зламаний контроль доступу, неправильна конфігурація безпеки тощо – програми пройшли лише 30% часу під час першого сканування.

Це не особливо відрізняється від попереднього; протягом останніх п’яти звітів цей показник постійно був на рівні однієї третини або нижче. Помилки ін’єкції SQL з’явилися в 27,61 TP1T нещодавно відсканованих програм цього року, що менше, ніж раніше, але схоже на попередні п’ять звітів, усі між 29% та 32,2% відповідно. Проте, як зазначається у звіті, організації, у яких програми AppSec діяли щонайменше 10 років, працюють значно краще. У порівнянні з топ-10 рейтингу OWASP, цей показник становить 431 TP1T.

Отже, що можна зробити, щоб застосувати стратегію AppSec? Звіт пропонує кілька ідей. У звіті закликається думати як зловмисник після того, як виявилося, що деякі розробники «можливо відкидаються рекомендації щодо безпеки, засновані на деяких необґрунтованих припущеннях про те, як програми можуть бути потенційно атаковані».

«Одним із поширених факторів ризику, які ми виявили в коментарях щодо пом’якшення наслідків, було те, що деякі розробники все ще довіряють вводам користувачів до тривожної міри», – зазначається у звіті. «Хоча 99% легальних користувачів ніколи не введе нічого шкідливого в поле введення, ми все ще повинні турбуватися про ту невелику меншість зловмисників».

Інший спосіб покращення — перехід до середовища DevSecOps. Оскільки DevOps вимагає від організацій частіше тестувати та виконувати ітерації, DevSecOps вимагає, щоб вони також підвищили частоту сканування безпеки. З року в рік у звіті зазначено, що цифри повільно зростають. Більше третини (36,51 TP1T) організацій все ще тестують лише раз на рік, але це зменшилося з 38,51 TP1T організацій у 2016 році. Частка організацій, які тестують щомісяця, двічі на місяць і щотижня, зросла.

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

«Розробники, які розглядають експертів з безпеки як внутрішніх, так і зовнішніх, як ресурс, а не як супротивника, як правило, досягають великих успіхів у зменшенні ризиків у портфелях програм».

Посилання на джерело