В отличие от Рины и Иры, я решила не отвечать на все-все заданные вопросы, а выбрать из них самые интересные и ответить на них. Итак, тройка лидеров в моем хит-параде выглядит так:
1) Как расставить приоритеты при тестировании безопасности?
Говоря откровенно, я использую при тестировании безопасности те же методы приоритезации, что и при "обычном" тестировании. Время на тестирование традиционно ограничено, но мне повезло - если у меня есть что-то критичное, то я вполне могу попросить дополнительное время на его проведение. Поэтому во главу угла становятся риски.
Какие риски могут быть и из-за чего они возникают? Сначала определяем откуда придет баг. Традиционно выделяются три источника риска: сам продукт, собственно проект и наши любимые пользователи.
Какие могут быть риски в продукте? Всё как обычно: при реализации какой-то функциональности допустили ошибки. Не предусмотрели, что вот здесь логика должна быть такой, а не другой, и т.д.
Какие могут быть риски в проекте? Здесь тоже всё достаточно старо и знакомо: проект большой и сложный, а на него набрали студентов-практикантов или же опытных разработчиков, но не сталкивавшихся ни разу с подобными технологиями. Обычно неопытные товарищи допускают глупейшие и очевиднейшие (для опытных) ошибки. Или же у нас динамично развивающийся проект, а методологию мы под него подобрали такую, которая не позволяет успевать разработке за требованиями. Последствия всем известны: "костыли" в неожиданных местах, "забывания" про важные требования, отсутствие code review и пр.
Какие риски могут прийти от любимых пользователей? Самая первая и важная - они используют продукт "не так". Вечное "Пользователь никогда так не сделает!" перестаёт работать и пользователи делают-делают-делают.
Итак, определили основные источники риска. Посмотрели на свой проект. Ещё раз посмотрели. Какие из рисков для нас реальны? И дальше на основе этих реальных, конкретных рисков определяем какие методы тестирования безопасности нам пригодятся, к каким частям функционала их стоит применить и в каком объеме.
2) А к десктопным приложениям насколько применимо тестирование безопасности?
На все 100%! К слову, такая штука как Fuzzing обрела популярность именно после успешного применения на десктопных устройствах. И чаще всего фаззинг используется именно для тестирования безопасности десктопных приложений. При помощи него можно сделать такие замечательные штуки как: фаззинг файлов, фаззинг протоколов, драйверов, исходного кода и пр.
3) Насколько часто вообще требуется тестирование безопасности? Пытались работать с appscan - но как-то не заинтересовались.
Как и все виды тестирования, тестирование безопасности можно проводить постоянно, периодически и одноразово.
Одноразово - это похоже на то, что сделали вы. Один раз провели, посмотрели. Прослезились или нет :) Сделали выводы или нет :) Обычно, конечно, делаются выводы и в дальнейшем код пишется с учетом замечаний по безопасности.
Периодически - раз в какой-то промежуток времени. Например, раз в квартал, раз в год. Т.е. проверили один раз и дальше контролируем периодически: помогло или не помогло, стали писать лучше или не стали, стали обращать внимание или не стали.
Постоянно, конечно, самый оптимальный вариант, но не всегда доступный - проводить тестирование безопасности постоянно, вместе со всем остальным тестированием. Выкатили новый билд - проверяем в том числе и безопасность.
Если говорить о нашем текущем проекте, то сейчас мы делаем минимальное тестирование безопасности периодически. Наш проект не связан напрямую с финансами, не завязан на некую секретную информацию, нам достаточно периодически проверять серьезно, а постоянно - только мелочи, типа одинарной кавычки - всё ли у нас хорошо всё ещё.
Так и живём :)
Спасибо за вопросы и спасибо всем, кто был с нами :)
Удачи в нелегком тестерском труде!
Комментариев нет:
Отправить комментарий