І так, і не так. Security model, яка побудована на obscurity (якщо ніхто не знає нашого кода, то і не здогадається, де там дірка) в реалі як раз ламається набагато легше, бо як раз в таких системах і забувають поновити версії бібліотек тощо.

Для того, щоб отримати доступ до нашого системного коду нічого не треба ламати. Наприклад, Titus та Zuul лежать просто у вільному доступі. Заходь на гітхаб і качай.

Минулого року хакнули приватне репо майкрософту на гітахбі і що? а нічого. Ну знаєш ти, що є такий код і така дірка в ньому - і що далі? Доступа до environment'а в тебе нема, і не буде, бо критичні enviroments як раз і проєктуються з розрахунком на те, що в них будуть деплоїти неідеальний код.

А якщо в твоїй thread model є серйозні загрози, то (а) дірки в коді вони знайдуть навіть без доступа до сирців - просто по непрямим ознакам, (б) захист коду - це дуже вторинне. Бо якщо треба, то серйозні люди просто прийдуть в гості до твоїх SRE, завербують їх чи просто приставлять пістолет до голови (і тоді починати треба з фізичного захисту персоналу).



розділенням engineering і QA

Часто, до речі, це є анті-паттерном. Є ситуації де це має сенс, але в більшості випадків від цього більше шкоди, ніж користі.