Давно я уже не работаю программистом и вопросами как это делается сейчас "в промышленых" масштабах не интересуюсь, но, может, кому покажется полезной идея, изложенная здесь.
Все пограммные продукты, которые я когд-либо разрабатывал в конечном итоге были мною и спроектированы. Конечно, я тоже читал умные книжки о том, что надо сначала все спланировать, продумать алгоритм, нарисовать все схемки, предусмотреть все мелочи .... и только потом брать какую-нибудь SDEи кодировать. Но, я никогда не программировал с промышленных масштабах, в крупных командах, и в, конечном итоге, сам себе был и архитектор и реализатор. Думаю, что, тем не менее, я не в меньшинстве: всегда есть начальство, которое дает высокоуровневую задачу, реализацию которой от начала до конца следует продумать нам, подчиненным.
Из опыта (возможно плохого и неправильного с т.з. высокой науки планирования программных решений) могу сказать, что на момент начала кодирования далеко не все мелочи продуманы и даже некоторые запланированные фрагменты основного алгоритма по ходу реализации могут значительно изменяться. Причин таких изменений "по ходу реализации" может быть великое множество и я бы не хотел их тут подробно разбирать, может быть, когда-нибудь потом. Когда такие изменения некуда эскалировать, я сам и разработчик, и архитектор, и главный идейный генератор, я уже перехожу в разряд "творцов" и программирование для меня из механики (буквально перевод на язык программирования == переводчик) в что-то вроде, не побоюсь этого, творчества (== художник, писатель). Очевидно, что при тврочестве у меня уже нет возможности (да и я сам не рекомендовал бы распыляться!) мне уже некогда обращать внимание на правильность и точность механических действий (приведу не очень удачный пример: когда я увлеченно говорю на неродном для себя языке, я допускаю грамматические ошибки, поскольку я не могу в момент увлеченности жестко контролировать технику механики, собственно, речи: грамматику, произношение и т.п. Пример не очень удачен, ввиду того, что если я имею достаточно большую практику, я буду механически говорить правильно не напрягаясь. Но такая "привычка делать правильно" не может развиться при кодировании). Т.е. когда я творю, я, скорее всего, не думаю о безопасности моего кода, я концентрируюсь на функционале. Как следствие, я не проверяю входные параметры (поскольку такие проверки, при отсутствии стандартных функций сильно напрягают мозг), я не использую " безопасные" варианты функций и много чего еще не делаю, что надо бы, но не хочется отвлекаться, чтобы не потерять мысль.
Решением данной проблемы мне видится появление (а может уже где есть) специального класса "программистов-безопасников", которые потом будут вычитывать исходные коды за "творцами" и исправлять потенциально небезопасные реализации. Этот процесс, как мне кажется, можно достаточно хорошо поставить на поток, поскольку есть масса матерала о том, как надо писать на том или ином языке, и как не надо. Можно все эти "рекомендации" собрать, систематизировать и использовать. Можно даже что-то проверять, наверно, автоматизированными средствами, которые смогут выискивать потенциально небезопасные конструкции.
Из экономических соображений (еще один безопасник!), хочется программиста-безопасника интегрировать в обычного программиста, а всю творческую составляющую полность от него отнять. Мой (сразу скажу - небольшой) опыт показывает что полностью это сделать не получится. Обилие уязвимостей, связанных именно с программной реализацией: все виды переполнения буфера, всякие инъекции, всевозможные кросс-сайт штуки и т.п. показывает, что обзр исходников на безопасность если и производится, то крайне плохо.
Еще один возможный камень в огород моего предложения - не будет решена проблема архитектурных уязвимостей. Но, кто будет спорить с необходимостью привлечения безопасности на всех этапах SDLC!? Мой (на сей раз уже значительный) опыт участия в проектах в качестве того самого безопасника-эксперта показывает, что не только в разных проектах нужен безопасник разной специализации (думаю, это очевидно, не буду объяснять), но и на разных этапах нужен также профессионал в соответствующей области. А слово "профессионал" в моем, возможно, извращенном представлении, никак не ассоциируется с уточнением "широкого профиля" - нельзя быть профессионалом во всем.
Напомню, что здесь на ваш суд я обозначил потребность в программисте-безопаснике. Традиционно, любые мысли приветствуются.
Разработчик ПО - безопасник
Разработчик ПО - безопасник
