Как обезопасить сайт от фрилансеров?

Question

[Ренат]

Периодически сайт ходит по-рукам фрилансеров и возникло сомнение о "чистоте" их помыслов.
Как не нахватать шеллов и прочих "черных ходов", которые обычно никак не сканируются антивирусами?
Стейджинг и контроль версий не очень подходят т.к. область работ почти по всему ядру CMS и модулей + новые увесистые наработки. По разным местам можно натыкать референсов и потом пробираться.
Как снижают подобные риски (если такое вообще решаемо с разумными трудозатратами)?

Comments

[Пашенька]

Выход один: стать фрилансером.

[Dima Polos]

Постоянного найдите одного, почему постоянно другие делают работу, что со всеми остальными не так?

[Константин Нагибович]

Dima Polos, может с заказчиком что-то не так?

[Сергей П]

Константин Нагибович, такое частенько бывает, что весь мир как мухи ополчится на одного человека и так и норовит в него личинку отложить. А человек-то хороший, свежий... Но по-разному бывает.

[Дмитрий]

Стейджинг и контроль версий не очень подходят т.к. область работ почти по всему ядру CMS и модулей + новые увесистые наработки

это значит, что вы неправильно пользуетесь стейджингом и контролем версий

правильный подход:
у фрилансера нет прямого доступа к проде и стейджу, есть только выдаваемые на время работ права мерджить в ветку для стейджа и делать пул риквест к ветке для проды
мердж в ветку для стейджа должен автоматом выкатывать код на стейджинг
перед мерджем в ветку проды - обязательный ревью кода

[ProjectSoft]

Но по-разному бывает

Сергей Паньков, не бывает.
Расскажу, как бывает.
Вы даёте задачу, её выполняют, но у вас ВДРУГ появляются куча хотелок, которые, как бы, относятся к задаче по вашему мнению и удерживаете оплату по основной задаче.
Заплатите за выполненную задачу, а потом поставьте на выполнение уже ваши хотелки за определённую сумму. И НИКАКИХ проблем у вас никогда не будет. Нужно играть честно.

[Сергей П]

ProjectSoft, для этого нужно не лениться, а писать себе ТЗ и подписывать её у заказчика. А ещё типовой договор с пунктами, жестко регламентирующими объёмы возможных "хотелок, доделок и перделок".
Да, это нормально, что ТЗ разработчик пишет себе сам. Заказчик может не быть специалистом в описании работы. Был бы спецом - сам бы всё сделал. А это именно что техническое задание.

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

[Ярослав Александров]

Выбрать опытного фрилансера профессионала и работать только с ним одним на постоянной основе. У таких людей не принято делать пакости заказчику и нет черных помыслов. Но если вы экономите, то и получаете на сайте проходной двор и толпы неблагонадёжных фрилансеров

[ProjectSoft]

Сергей Паньков,

Заказчик может не быть специалистом в описании работы. Был бы спецом - сам бы всё сделал. А это именно что техническое задание.

И это никак не снимает ответственность заплатить за проделанную работу по ТЗ даже если оно устное. Да и навряд ли оно устное, ибо писалось в мессенджер или другие виды удалённой связи.
Если новичок - это не значит лох.
И как говорил Иисус

Итак во всем, как хотите, чтобы с вами поступали люди, так поступайте и вы с ними, ибо в этом закон и пророки

Поэтому вопрос Константин Нагибович даже очень в точку.

Answer 1

[Сергей П]

Стейджинг и контроль версий не очень подходят т.к. область работ почти по всему ядру CMS и модулей + новые увесистые наработки.

1. Подходят / не подходят, а если у вас всё это делается без стейджинга и контроля версий, я вам советую продать сайт пока возможность есть со всеми потрохами и поискать себя в другой области. Система контроля версий - это единственное, что потом позволит вам хотя бы задним числом понять кто не чист на руку и отомстить плохими отзывами в профиле.
   
2. Не ищите дешевых фрилансеров без репутации и профиля, которым имело бы смысл дорожить.
   
3. Держите репозиторий в гитхабе и старайтесь, чтобы разработчик от своего основного эккаунта кодил. Акк должен быть с активностью, историей, иначе что это за разработчик такой? Вообще верно в той поговорке сказано: "не гонялся бы ты, поп, за дешевизной".
   
4. Дешевых нонейм-фрилансеров без истории опасно пускать в ядро. Отдавайте их код на ревью ребятам посерьёзнее, с репутацией. Ревью тоже работа, но обойдётся дешевле, чем закодить все эти фичи. За то опытный человек своим глазом глянет. С него потом и спросить можно как это он проглядел вредоносный коммит.
   
5. Выносите всё что можно в опенсорс, но контрибьютьте корневой проект сами или через проверенных людей. Тут вам и бесплатные руки (если фичи полезные), илишние глаза для проверки на вшивость.
   
6. Не хватает денег на крутых серьёзных разрабов с репутацией, делегируйте им хотя бы составление детального ТЗ и, как я выше уже написал, ревью.
   
7. Помните, что порой лучшее - враг хорошего. Умейте выстраивать MVP. По Паретто 80% прибыли вам принесёт 20% фич. Сделайте их хорошо, а остальное, может быть, отпадёт за ненадобностью по факту.
   
8. Как говорится "вам пора, и вам пора, с вентиляторным заводом заключать договора". Правильно коллега подметил в соседнем ответе. Вы ж не подпольную крипто-биржу, наверно, там кодите. Можно договора заключать с разрабами в белую. Лишний повод ему не гадить засветив реквизиты и подписавшись.
   

Comments

[Dima Polos]

Подписываюсь под каждым словом!

Answer 2

[Владимир Коротенко]

Ренат будьте вежливыми, перед тем как сказать досчитайте до 42.
Не кидайте в сугубо криминальном понятии кидка. Все проблемы разрешайте переговорами.
Фрилансерам в общем то до вас без разницы, вы заказчик и оплачиваете банкет, навредить вам и себя подставить так себе развлечение. Ну висит у меня куча паролей. Что мне дропать базу? Я лучше возьму с вас по второму кругу когда вам студенты наворотят, тем более буду знать что там у вас твориться.

У меня есть долгоиграющий проект, завершали мы его раза 4, работало над ним примерно 17 команд. Мы уже друг друга знаем поименно.

Answer 3

[Sanes]

Сами делайте. Вместо фрилансеров.

Answer 4

[Амир Давлатов]

Выхода только два. Либо делать все самому, либо найти одного человека который все будет делать сам

Answer 5

[iBird Rose]

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

Comments

[Сергей П]

О, а можно я ваш ответ себе доп-пунктом добавлю? Забыл упомянуть. Это ж не мамкин блокчейн-проект какой-нибудь, тут и можно и договор и NDA заключать. Лишняя соломка всёж-таки.

[iBird Rose]

Сергей Паньков, конечно

Answer 6

[Пума Тайланд]

Судя по описанию идеально подходит стейджинг и контроль версий в Гите
Это прямо что процентное попадание в гит он специально для этого и был сделан

Answer 7

[xmoonlight]

Давать кодировать отдельными блоками и ограничивать валидацию только нужным Вам перечнем функций.
PS: Инфы много: если интересно - могу статью черкануть в своём блоге.