сходу прям моют бабки. ну молодцы чего уж)

Мало кто умеет думать про безопасность и строить безопасные финансовые решения.
В лучшем случае число людей, могущих украсть деньги сводится до трех-пяти (а не для любого разработчика)

Не, это не про отмыв, это обычно про казино и букмекеров и это уже уголовщина )

А где можно посмотреть/почитать как правильно или как уж точно не стоит делать?

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

Сейчас это или через крипту или через очень рисковые банки. Рисковые банки массово прикрывают за такое (отзывают лицензии).

Хм, думаю, что нигде (

Понял. Только личный опыт к сожалению

Спасибо

Ну, иногда можно читать доклады про OpsSec, читать OWASPовские рекомендации и т.п.
Но в среднем нужно думать самому или искать нормального безопасника (не бумажного, а по делу)

Я тоже знаю эти вещи со стороны разработки, а там дофига вещей именно у СБшников.

Спасибо

@dphil привет
по Design Review хотел спросить. ты вначале говоришь, что по факту код ревью - это способ решить проблему доверия к разработчику. но как начать доверять и верить, что разработчик будет пилить код в соответствии с дизайн ревью? Особенно, если разработчик новый (может и опытный, в команде недавно). чайка ревью не может оказаться слишком запоздалой реакцией?

Онбординг - это отдельный процесс, конечно, а я про процессы разработки пишу

Пока разработчику нельзя доверять в таких вещах - он или еще джун (процесс обучения) или не включен в команду (процесс онбординга)

ага, согласен. но тут я больше не про онбординг, а про введение процесса дизайн ревью
по факту я (или лид) ведь еще не знаю, как каждый из сотрудников будет код пилить - по дизайну своему или нет. вот как начать доверять тут. ведь если бы я доверял полностью, то у нас бы и пир ревью не было )
тут посоветоваться хотел - логичнее на этапе введения иметь 2 ревью (дизайн и код) или скорее вариант с некой частой на первых этапах ретроспективой?

вот, кстати, ты упомянул доклад там про введение процессов, может быть есть ссылка близко? может быть там уже и ответы все есть )

Да, вначале можно сочетать и дизайн и кодревью, без проблем

и соответственно выглядит логичным на этапе адаптации тоже оставлять 2 ревью?

Да, конечно. Потом потихоньку уменьшая ответственность при code review