Да, TDD - это инструмент / метод, который может помочь обеспечить безопасное кодирование.
Но, как и во всех вещах в этой отрасли: представьте, что это серебряная пуля, и вы выстрелите себе в ногу.
Неизвестные угрозы
Как вы указали в правке 2: «вы защищаетесь от 5 сценариев атаки, атакующий просто ищет и использует 6-ю атаку». TDD не собирается защитить вас от неизвестных угроз. По своей природе вы должны знать, что вы хотите проверить, чтобы написать тест в первую очередь.
Итак, предположим, что угроза номер 6 обнаружена (надеюсь, не из-за нарушения, а скорее из-за другого инструмента / техники, которая пытается найти потенциальные векторы атаки).
TDD поможет следующим образом:
- Могут быть написаны тесты для проверки угрозы.
- Может быть реализовано решение для блокирования угрозы и быстрого подтверждения его работоспособности.
- Что еще более важно, при условии, что все остальные тесты все еще проходят, вы можете быстро проверить, что:
- Все остальные меры безопасности по-прежнему работают правильно.
- Все остальные функции по-прежнему работают корректно.
- В основном TDD помогает быстро сократить время с момента обнаружения угрозы до того, как решение становится доступным.
- TDD также обеспечивает высокую степень уверенности в том, что новая версия ведет себя правильно.
Тестируемый код
Я читал, что TDD часто неверно истолковывают как методологию тестирования, хотя на самом деле это скорее методология проектирования. TDD улучшает дизайн вашего кода, делая его более тестируемым .
Специализированное тестирование
Важной особенностью тестовых случаев является их способность работать без побочных эффектов. Это означает, что вы можете запускать тесты в любом порядке, любое количество раз, и они никогда не должны давать сбой.
В результате ряд других аспектов системы становится проще тестировать исключительно в результате тестируемости. Например: производительность, использование памяти.
Это тестирование обычно выполняется путем запуска специальных проверок всего набора тестов - без непосредственного влияния на сам набор.
Подобный модуль тестирования безопасности может перекрывать набор тестов и искать известные проблемы безопасности, такие как защищенные данные, оставленные в памяти, переполнения буфера или любой новый вектор атаки, который становится известным. Такое наложение будет иметь определенную степень достоверности, поскольку оно было проверено для всех известных функций системы.
Улучшенный дизайн
Одним из ключевых улучшений конструкции, возникающих как побочный эффект TDD, является явная зависимость . Многие системы страдают от веса неявных или производных зависимостей. И это сделало бы тестирование практически невозможным. В результате конструкции TDD имеют тенденцию быть более модульными в нужных местах . С точки зрения безопасности это позволяет вам делать такие вещи, как:
- Тестирование компонентов, которые получают сетевые данные без фактической отправки их по сети.
- Можно легко смоделировать объекты, чтобы они вели себя неожиданным / «нереалистичным» образом, как это может происходить в сценариях атаки.
- Испытание компонентов в изоляции.
- Или с любым желаемым сочетанием производственных компонентов.
Модульное тестирование
Следует отметить, что TDD предпочитает сильно локализоваться (модульное тестирование). В результате вы можете легко проверить, что:
SecureZeroMemory() правильно удалит пароль из ОЗУ. - Или, что
GetSafeSQLParam() будет правильно защищать от внедрения SQL.
Однако становится все труднее проверить, что все разработчики использовали правильный метод в каждом месте, где это требуется.
Тест для проверки новой функции, связанной с SQL, подтвердил бы, что эта функция работает - она будет одинаково хорошо работать как с «безопасной», так и с «небезопасной» версиями GetSQLParam.
Именно по этой причине вам не следует пренебрегать другими инструментами / методами, которые можно использовать для «обеспечения безопасного кодирования».
- Стандарты кодирования
- Обзоры кодов
- Тестирование