Безопасность = качество? Часть 1

До сих пор в массах бытует мнение что часто безопасность есть нечто отделимое от всего остального, что необязательно закладывать безопасность продукта в его архитектуру и на любом этапе разработки, если вдруг потребуется (часто надеяться что не потребуется), можно к ней вернуться и включить в состав.

Но реальность полна разочарований и большинство натурных "экспериментов" доказало что если не вспоминать про безопасность с самого начала, "включаясь" на последних этапах разработки спешно и обморочно внедряя хоть бы какую верификацию, то рано или поздно технический долг выстрелит по продукту, приведя к потерям. И хорошо если это будут только финансовые потери, не зря говорят что ТБ пишется кровью. Часто пренебрежение конструктивной/функциональной/информационной безопасностью ведёт, в том числе к увечьям и смертям. Чтобы зафиксировать в своей голове к чему может привести игнорирование безопасной разработки, есть некоторые концепции. Например, концепция "1:10:100".

В чем она заключается? Она говорит нам про то, что чем позднее мы включаем в процесс разработки верификацию, тем дороже нам обойдётся устранение проблем. В оригинальной формулировке конечно же подразумеваются доллары, мы же патриотично раскидаем пример на рублях. Если мы заметим дефект на уровне архитектурного проектирования - его устранение потребует от нас затрат на один рубль, если дефект будет обнаружен на этапе верификации, то он нам "встанет" в 10 рублей, если же мы верификацию отдадим на откуп потребителю, то уже 100 рублей придется отдать за устранение проблем.
Наш совет простой - найдите ошибку до того, как она станет проблемой.

#ДайджестРБПО