Безпека – це складна сфера, що включає все, від розробки та конфігурації до розгортання та обслуговування. У цих випадках є впевнені дві речі. По-перше, обізнаність є ключовою. По-друге, якщо не працювати з безпекою на всіх етапах, ви потрапите в гірше становище!
Ось 5 порад, які допоможуть вам підвищити рівень обізнаності щодо безпеки під час розробки проекту Agile. Пам’ятайте: безпека – це не проблема когось іншого – це ваша проблема і проблема вашої команди!
1 призначити чемпіона з безпеки
Почніть із призначення когось Чемпіоном безпеки вашої команди. Ця особа не повинна бути експертом з питань безпеки (але якщо є очевидна потреба, відправте її на навчання).
Чемпіон з безпеки несе відповідальність за те, щоб за потреби піднімали питання, що стосуються безпеки. Ніхто не очікує, що ця людина матиме всі відповіді. Натомість чемпіон з безпеки повинен нагадати команді про необхідність розглянути питання безпеки, коли це необхідно.
Це гарна ідея передати цю роль навколо. Для кожного спринту робіть когось іншого Чемпіоном безпеки. Це допоможе поширити обізнаність та знання.
2 виконайте перевірки безпеки
Важливо розуміти та відстежувати зміни у продукті, які можуть вплинути на безпеку. Тому рекомендується регулярно проводити перевірку безпеки під час проекту.
Позначте кожну доставлену історію користувача, яка може вплинути на безпеку. Потім перегляньте ті позначені історії, які були передані після попередньої перевірки – або під час огляду спринту, або під час планування спринту. Якщо команда визначить необхідні зміни в безпеці, створіть нові історії користувачів і додайте їх до відставання продукту.
Щоб визначити зміни, які можуть вплинути на безпеку, команда може задати кілька простих запитань для кожної переданої історії користувача:
“Ми змінили щось, що може вплинути на безпеку?”
Це стосується функцій або компонентів, які зазнали змін, наприклад зміна сторонньої бібліотеки або зміна процесу реєстрації.
“Ми ввели щось, що може вплинути на безпеку?”
Це стосується додаткових функцій, напр. нещодавно введена функція для завантаження зображень.
Додаючи регулярні перевірки безпеки до Визначення Готово, це не буде забуто. Тоді це буде потрібно, перш ніж будь-яку роботу можна буде вважати завершеною.
3 аналіз безпеки історій користувачів
У проекті, який відповідає за безпеку, буде проведено аналіз безпеки перед початком проекту. Це дасть команді безцінну інформацію про загальні вимоги до безпеки. Однак навіть якщо цей аналіз дає базову лінію, вимоги до безпеки повинні адаптуватися разом із розробленим продуктом.
Розглядаючи будь-яку історію користувача для включення в спринт, команда також повинна враховувати наслідки для безпеки. Це можна зробити за допомогою моделі для аналізу безпеки. Чим менш досвідчена команда, тим простішою повинна бути ця модель. Запитання про те, як хтось може скомпрометувати функцію або конфіденційні дані, може бути достатньо. Якщо ваша команда призначила Чемпіона з безпеки, керівництво цією роботою несе відповідальність цієї особи.
4 ведіть каталог історій безпеки
Хорошим способом підвищення обізнаності та якості в проекті є наявність каталогу раніше написаних історій, орієнтованих на безпеку. Ці історії можуть базуватися на списках загальних вразливих місць і можуть бути використані повторно для інших проектів.
Якщо ці магазини містять детальну інформацію про вразливість, що впровадити та як перевірити, це допоможе недосвідченій команді отримати більше обізнаності та знань. Коли команда проводить аналіз безпеки історії користувача, цей каталог може допомогти зрозуміти, на що звертати увагу та як боротися з уразливістю.
Ось приклад історії, орієнтованої на безпеку: “Як розробник я хочу забезпечити обмеження конфіденційних даних, щоб доступ до них мали лише уповноважені актори”.
5 відстежуйте свій борг за безпеку
Традиційно програмні проекти говорять про технічний борг, тобто про майбутні витрати поточного технічного рішення. Відповідно, борг під заставу може бути визначений як сума всіх незавершених завдань або питань, пов’язаних із безпекою. Важливо розуміти, що цей борг може складатися як з відомих, так і з невідомих питань.
Оновлений перелік боргу за безпеку товару дозволить усвідомлювати всім учасникам проекту потенційні вразливі місця та ризики. Це спільні зусилля під керівництвом Чемпіона з безпеки та Власника продукту.
Власник продукту володіє боргом під заставу і повинен вирішити, як з ним боротися, які ризики слід контролювати і які слід приймати. Перед будь-яким випуском у виробництво Власник продукту повинен прийняти поточний борг під заставу; якщо його не можна прийняти, тоді товар не можна випустити.
Вводячи безпеку в проект Agile, почніть з відстеження боргу за безпеку. Потім призначте Чемпіона з безпеки та додайте решту, як вважаєте за потрібне. Ваша команда почне будувати власність та відповідальність за безпеку продукту. Це призведе до підвищення якості та поставить усіх у кращу та безпечнішу позицію.
Ніклас К’єллін працює експертом з питань безпеки у Softhouse Consulting у Швеції. Перейдіть за посиланням для іншої статті про те, „Безпека потрібна на кожному кроці проекту Agile” (шведська).
Спочатку ця публікація була опублікована за адресою https://www.linkedin.com/pulse/top-5-advice-include-security-any-agile-software-project-kjellin/.
Niclas Kjellin люб’язно дозволив нам перекласти і опублікувати цю статтю.
Temy.co - Software Development Partner 