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