サーバーコードとクライアントコードを持つリポジトリは別々にすべきですか？
フロントエンドSPAとREST APIバックエンドでWebサイトを実行するプロジェクトがあります。
現在、コードは/ clientおよび/ serverフォルダーに分割されており、独立して実行されます。ただし、それらは現在同じリポジトリにあります。
クライアント側のコードでのみ機能する請負業者を雇った場合、これを2つのリポジトリに分割し、フロントエンドの請負業者にクライアント側のコードのみを提供することには、セキュリティ上の利点がありますか？
開発者は引き続き、ローカルの開発環境を、サーバーをクラウドで実行している開発環境に接続できます。
私の主な懸念は、バックエンドコードが信頼できない開発者によってハッカーに売られ、コードを調べてセキュリティホールが発見される可能性があることです。
はい、これらは通常分割する必要があります。
これらは一緒に1つのソリューションを形成する可能性がありますが、コード自体は論理的に分離されています。そのため、1つのリポジトリにアクセスできるユーザーは、必ずしも他のリポジトリにアクセスする必要はありません。
リスクは何ですか？
脆弱性をハッカーに売り込むことは可能ですが、それらのハッカーはコードで同じ脆弱性を見つけることもできます。はるかに大きなリスクは、コード自体を競合他社に販売するか、それを使用して競合製品を構築することです。
私はあなたが請負業者がそれをしていると非難していません-彼らはまさしく正直な仕事をしている正直な人々であるかもしれません-請負業者がまさにそれをしているという報告があります。彼らはあなたの製品の分析に時間を費やし、スタッフからの質問に答えてもらって、1年後に競合製品が出てきました。彼らがコードを盗んだことを証明することはできませんでしたが、偶然であるにはあまりに多くの偶然です。
コードを分割する方法は？
使用しているバージョン管理システムに応じて、これは簡単な場合とそうでない場合があります。たとえば、Gitを使用する場合、リポジトリを複製してそれぞれの半分を削除するだけでは簡単ではありません。 Gitはすべての古いファイルを履歴に保持するため、「クライアントのみ」のリポジトリのローカルコピーにアクセスできる請負業者は、分割の時点まで悪意のあるサーバーデータを参照できます（悪意があるので十分かもしれません）。 。新しい「クライアントのみ」のリポジトリをチェックアウトする新しい請負業者は、引き続きサーバーデータにアクセスできます。
「最も簡単な」方法は、古いリポジトリを完全に消去し、それぞれのコミット履歴で2つのリポジトリを再構築することです。リポジトリのサイズにもよりますが、これには1時間から10年の作業が必要です。
自動化ツールが利用できる場合もあれば、そのための独自のスクリプトを作成できる場合もあります。私はこのような状況に陥ったことがなかったので、実際に体験したことはありません。
もちろん、これでも請負業者に古いコードのローカルコピーを残すことになりますが、このコードが最終的に自分のマシンで使用された場合、このコードはすでに侵害されていると見なす必要があります。しかし、少なくともそれは将来の請負業者がそれにアクセスすることを妨げるでしょう。