Share Source Code With New Developers: Secure Handover Playbook

Why Fora Soft wrote this playbook

In 20 years of shipping custom software for clients in video, e-learning, healthcare and security, the single question we get asked more than any other on week one is: “Do we really have to share our source code with you?” The short answer: yes, if you want sprint one to produce shippable code instead of archeology. The longer answer — what to sign, what access to grant, what to strip out first, and what to do if you genuinely cannot share — is this article.

We inherit codebases constantly. Some are legacy Rails apps with a decade of commits, some are half-finished React Native prototypes from a previous vendor, and some are production WebRTC stacks serving tens of thousands of concurrent users. The pattern that separates smooth handovers from painful ones is not the size of the code — it is whether the client gave us access early, with the right legal scaffolding and the right repo controls. When we have both, we ship the first meaningful PR in 5–10 business days. When we do not, that same work takes 4–8 weeks. Want a more detailed tour of how we take over code? Start with Fora Soft’s 20 years of software expertise or see our custom software development page.

The short answer: yes, share it — but engineer the handover

“Should I share source code with a new developer?” is usually not a question about trust — it is a question about risk. Legal risk (IP leakage, re-use against you). Security risk (leaked secrets, a compromised contractor laptop). Competitive risk (the vendor learns your algorithms). All three are real. All three have standard, repeatable countermeasures. None of them are reasons to keep a new team in the dark.

The blunt trade-off: a vendor without code access will cost you more, ship slower, and occasionally ship the wrong thing because they guessed at invariants they could not see. A vendor with code access under proper legal and technical controls ships faster, catches integration bugs earlier, and surfaces refactoring opportunities that reduce your long-term maintenance cost. The rest of this article is the practical recipe for getting the second outcome without the first one’s risk.

What a new team actually gains from your source code

A shareable repository is not a convenience — it is the spec. The code is the only artifact in your organization that is guaranteed to be up to date. Documentation lies. Jira tickets lie. The CTO’s mental model lies (gently). The code, by definition, does not. Four concrete wins flow from this:

1. Real integration tests, not simulated ones

If we are adding a feature — say, on-the-fly speech translation to an existing video-call stack — we need to boot the actual platform in a staging environment and run tests against it. Without source code we get a best-guess mock. Ship that against a real system and you discover the 3% of invariants we missed during the first demo to your users. That is expensive.

2. Compatibility audits that catch version drift

Older codebases pin to older versions of core libraries — React 17, Node 16, a specific Kurento build, a particular FFmpeg branch. A new module built against the latest versions will collide on day one. With the repo in hand we either match the pins or plan a controlled upgrade. Without it, we guess and you pay for a second integration pass.

3. Fast cross-team support when something breaks

Production incidents rarely respect team boundaries. When a 3am pager goes off, a team that knows both halves of the system fixes it in 40 minutes; a team that knows only its own module opens a ticket on your team and waits until 9am. Shared repo access is the difference between an uptime story and a change freeze.

4. Opportunistic refactoring

Long-running codebases accumulate dead code, dual implementations, and scaling bottlenecks. A second set of experienced eyes catches these in the first week. We see everything from a single-database bottleneck that could be fronted with Redis to an entire SDK dependency that could be replaced with 200 lines of custom WebRTC. For a deeper tour of why and when to do this, see our plain-words guide to code refactoring.

The legal layer: NDA, IP Assignment, DPA, escrow

An NDA by itself is a weak protection. It tells the vendor not to disclose your code — it does not transfer ownership of what they build on top of it, and it does not address what happens to the code if the vendor disappears. A modern handover agreement has four legal pieces, and most serious vendors will accept all four without negotiation:

Non-Disclosure Agreement (NDA)

The baseline. It defines confidential information (source code, architecture diagrams, customer lists, benchmarks), restricts use to “performance of the services only,” survives the contract by 3–5 years, and sets a specific liquidated-damages floor so the vendor cannot argue damages are speculative if they leak.

IP Assignment clause

Every line of code the vendor writes on your project is your IP on the moment of creation — not “on payment,” not “on final acceptance.” This matters in the edge case where a vendor tries to claim ownership of a shared module they wrote and re-used across clients. The clause should also include a waiver of moral rights where local law permits.

Data Processing Addendum (DPA)

Required under GDPR if any repository, log, or environment variable contains EU personal data. Specifies what the vendor can do with that data, how long they keep it, what happens on contract termination (deletion certification), and which sub-processors they use. If the vendor cannot sign a DPA, walk.

Source-code escrow (optional, recommended for mission-critical code)

A neutral third party (Escrow London, NCC Group, Iron Mountain) holds a copy of the current source. If the vendor goes bankrupt or breaches the contract, you get the code. Typical cost: $1,500–$4,000 per year for a single deposit with quarterly updates. Worth it for anything where vendor failure would halt your business.

The technical layer: least-privilege repo access

Legal protection is a deterrent. Technical controls are the wall. The goal is simple: give the new team exactly the access they need to do sprint 1, and nothing else. Five controls cover 95% of the risk:

1. A dedicated team or org role, not a personal fork

Create a GitHub / GitLab / Bitbucket team named for the vendor (vendor-forasoft). Invite individual developer accounts, not a shared email. When the engagement ends you revoke the team in one click and every access goes with it. Never let a contractor push to a personal fork — you lose audit trail.

2. Branch protection on main

Require 2 reviewer approvals (at least one from your team), passing CI, signed commits, and linear history. Disable force-pushes and direct commits to main. A vendor who objects to branch protection is showing you their workflow discipline — take it as data.

3. CODEOWNERS for sensitive paths

Put a .github/CODEOWNERS file that routes review on /infra/**, /security/**, /billing/**, and /.github/workflows/** to your team. The vendor can read those paths; they cannot merge changes without you.

4. Signed commits

Enforce git verify-commit on the server. Every commit carries a cryptographic signature tying it to a specific GPG / SSH key. If a contractor laptop is compromised, the attacker cannot forge commits from other developers.

5. Time-boxed access + audit log retention

Grant access for the contract term only. Review and re-attest every quarter. Keep the audit log (who cloned, who pushed, who merged) for 12–24 months on GitHub Enterprise / GitLab Premium. When a problem surfaces 9 months later, you want the trail.

Secrets hygiene: scrub the code before you share it

Industry reports consistently find that 30–45% of data breaches involve exposed credentials, and git history is one of the worst offenders because old commits often still contain the AWS key someone “removed” in the next commit. Before you open the repository to a new team, run a 30-minute pre-handover sweep:

# 1. Scan full git history for secrets
trufflehog git file://. --only-verified --json > secrets.json

# 2. Scan current tree for API keys, tokens, passwords
git-secrets --scan-history

# 3. Purge a known bad file from all history (use with care)
git filter-repo --path config/production.env --invert-paths

# 4. Rotate every key in the output BEFORE granting access
#    (AWS, Stripe, SendGrid, Firebase, Twilio, internal JWT signing keys)

# 5. Install pre-commit hook so the next leak is caught locally
pre-commit install

The non-obvious step is key rotation. Deleting a secret from HEAD does nothing — it is still in the commit history. Assume any credential that has ever been committed is already compromised and rotate it. Stripe, SendGrid, Firebase, and AWS all support same-day rotation; there is no reason to skip this step. For a deeper look at how Fora Soft bakes security into code handover, see shift-left security with AI code review.

Access patterns compared: which one fits your risk profile

Not every engagement needs full write access to the production repo. Five patterns cover the practical range, from paranoid-but-slow to fast-and-collaborative. The matrix below shows what each pattern buys you and what it costs.

Default to “Feature branch + PR.” Move to “Co-owned mainline” once you have seen three sprints of good work. Use black-box only when you genuinely cannot share the code — every week of delay it costs you has a price tag.

Compliance: GDPR, HIPAA, SOC 2, PCI DSS

If your code touches regulated data — EU user profiles, US health records, payment cards — code sharing is not just a contract; it is a compliance event. Four regimes cover most regulated software Fora Soft sees:

1. GDPR. If the repo, logs, or config reference any EU personal data (even as test fixtures), the vendor becomes a processor. You need a signed DPA, an accurate sub-processor list, and an “EU data stays in the EU” commitment if that is the position you publish. Maximum fine: EUR 20M or 4% of global turnover, whichever is higher.

2. HIPAA. If any code path touches US Protected Health Information, the vendor must sign a Business Associate Agreement (BAA) before they clone the repo. Audit logging, access review, and breach notification SLAs must be explicit. Per-record HIPAA violation fines run $100–$50,000 and class actions for PHI exposure regularly settle north of $1M.

3. SOC 2 Type II. For B2B SaaS clients, an annual SOC 2 report from the vendor is the single most useful document. It proves that the access controls, change management, and incident response described in the contract are actually in force.

4. PCI DSS. If the code ever sees cardholder data, the vendor environment must meet PCI Level 1 controls — segregated networks, no shared hosting, quarterly ASV scans. In practice the cleanest path is to keep the payment vendor (Stripe, Adyen, Checkout.com) handling cards end-to-end and scrub tokens from logs before handover.

Vendor due diligence: the red flags that mean “don’t share”

Most code-sharing disasters are not technical; they start because the client did not vet the vendor carefully enough. A 60-minute due diligence pass catches 90% of the bad ones. Watch for these signals before you grant repo access:

Refusal to sign IP Assignment. A vendor who wants to retain ownership of “reusable components” is telling you they plan to sell your work again. Walk.

Demand for admin / root access to infrastructure. They need write access to the feature branch, not to your AWS organization, not to your DNS, not to your Stripe account.

No documented security policy. Ask: “What is your laptop policy? How do engineers store source code locally? How do you revoke access when someone leaves?” If the answer is improvised, so is the protection.

No client references on similar work. Fora Soft regularly hands over named client references (with permission) on takeover projects. A vendor who says “we cannot share any references, privacy” is either very new or has nothing to show.

Shared development environments. “We all work on the same EC2 box” is a compliance failure on day one. Look for per-engineer environments with enforced disk encryption.

A decision framework — share or don’t share in five questions

Use these five questions as a go/no-go gate. If the answer to Q1–Q4 is yes and Q5 is “acceptable,” share the code. If any one of the first four is no, fix it before you share; if Q5 is “unacceptable,” explore the black-box alternative in the next section.

Q1. Has the vendor signed NDA + IP Assignment + DPA? All three, not just an NDA. An email thread is not a signature.

Q2. Is repo access time-boxed, team-scoped, and revocable in one click? Personal forks and shared emails fail this test.

Q3. Has the repository been scanned for secrets and every exposed credential rotated? If you share first and rotate later, the vendor will have the old keys on disk for months.

Q4. Is main protected with 2-reviewer approval and CODEOWNERS on sensitive paths? Without this, the vendor can merge a backdoor.

Q5. Is the vendor’s documented security posture (SOC 2, ISO 27001, or a direct audit) acceptable relative to your data classification? A B2B SaaS selling into regulated industries should expect SOC 2 Type II at minimum.

What a clean handover actually looks like — 10 business days

Good vendors get to shippable code in two working weeks. The typical path:

If week 2 ends without a merged feature PR, something is wrong — usually either an undersized vendor or a client side that did not rotate secrets and kept access blocked. Either way, diagnose fast.

Platform-specific controls: GitHub, GitLab, Bitbucket

The access controls above are platform-agnostic in concept, but each git host exposes them slightly differently. Use the quick-reference below to map the policy to the setting.

GitHub Enterprise

Create an organization-level team, assign the “Write” role only to specific repos. Enable “Require signed commits,” “Require linear history,” and “Require review from Code Owners” under branch protection on main. Retain the audit log for 6 months on the Cloud plan; Enterprise Cloud retains longer with export-to-SIEM. Use IP allow lists to restrict contractor traffic to known VPN ranges.

GitLab Premium / Ultimate

Use group-level permissions; assign “Reporter” for read + view pipelines and “Developer” for pushing to feature branches. Protected branches prevent direct pushes to main; merge-request approvals enforce the 2-reviewer rule. Premium includes a cross-project audit log under Security & Compliance.

Bitbucket Cloud / Data Center

Create a dedicated workspace for the vendor. Use branch permissions to allow writes only on feature/* and require Pull Request reviews for merges into main. Data Center supports IP allowlists and SAML SSO for contractor accounts.

Cost math: what a secure takeover really runs

Clients consistently over-estimate the cost of a secure handover and under-estimate the cost of skipping one. Here is the honest breakdown for a typical add-on engagement (one new feature, one senior engineer + one mid-level engineer on the vendor side, 8-week timeline):

Legal. NDA + IP Assignment + DPA package drafted once and reused: $800–$2,500 one-off with a tech-aware attorney. If you already have templates, closer to $0 on subsequent engagements.

Secrets scan + rotation. One engineer, 4–8 hours. Rotation is the bulk of the work if you have 20+ credentials in history.

Access controls. GitHub Enterprise / GitLab Premium tier, already in your budget. Configuring branch protection, CODEOWNERS, and IP allowlist: 2–4 hours, one-time.

Escrow. Optional. $1,500–$4,000 per year for quarterly deposits with a specialist (NCC Group, Escrow London, Iron Mountain).

Total one-time on the client side: typically under $5,000, plus 20–30 engineer-hours over two weeks. Compared to paying a vendor to rebuild two weeks’ worth of work they could have done directly in your repo, the break-even is immediate. Fora Soft also uses spec-driven agent engineering internally to compress the architecture-mapping phase, which keeps vendor ramp-up hours on our side low too.

Mini case: inheriting a 6-year-old video platform

A client came to us with a hybrid e-learning + video conferencing platform that had been built by three different teams over six years. The brief was simple on paper: add real-time translation of instructor speech across 12 languages. The complication: the original team had left, the codebase pinned an old Kurento build, and a previous vendor had partially migrated parts of the frontend to a different framework without finishing.

Week 1 was code-sharing logistics: NDA + IP Assignment signed on day one, repo invited on day two, trufflehog turned up 11 exposed credentials (three still active), all rotated within 24 hours. Week 2 we ran the architecture walkthrough and shipped two doc-only PRs to prove the workflow. Week 3 we opened the real feature PR for the translation module.

Before/after, 12 weeks in: median class latency dropped from 380ms to 210ms because the review of the existing code turned up a mis-tuned TURN server; the 11 stale credentials were gone; a no-longer-needed paid SDK dependency was replaced with 280 lines of custom code, saving $2,400/month in license fees. None of these wins would have been possible without full source access under proper controls. Want a similar assessment on your codebase? Book a 30-minute call. Or go deeper on method: read what to do with legacy code in your software project and a similar client story in AppyBee’s founder review.

When not to share — and what to do instead

A minority of engagements genuinely do not permit full code sharing. Three situations come up repeatedly:

The code belongs to a third party

You are building a component that plugs into a large partner’s system — perhaps a corporate client’s internal platform — and their license does not allow sharing the source. The answer is a detailed integration specification: API contracts, message schemas, authentication flow, rate limits, and error envelopes. Our analysts can produce this from a 2-hour discovery call with the partner team plus access to their API docs. With that in hand, we build against the contract and integrate later.

The original source code was lost

The previous vendor shut down or stopped responding and handed over only a running binary. In JavaScript / TypeScript stacks we can recover a usable amount of the source through source maps and careful reverse engineering for client-side code; for server-side code we diff deployed artifacts against the public dependency versions and extract what’s uniquely yours. It is slower than having the repo, but it is not a dead end.

Hardware-first or firmware-first projects

You have a device, but no production software yet. In this case there is nothing to share — the handover is a detailed hardware specification: SoC and OS, processing headroom, peripheral bus, power envelope, thermals, and a representative workload. That lets us scope firmware and application code accurately.

Five pitfalls we see on every third project

1. Sharing access before rotating secrets. The single most common mistake. The vendor has a clone on their laptop with your old production database credentials within 15 minutes. Rotate first.

2. Signing an NDA without IP Assignment. The NDA stops them from disclosing the code; it does not stop them from claiming ownership of a widget they build on top of it and re-selling the widget to your competitor.

3. Inviting personal accounts to a shared workspace. A contractor who uses a personal GitHub account survives their engagement with you. Force organization-level invites so revocation is one click, not a legal letter.

4. Skipping CODEOWNERS on infrastructure paths. The vendor gets full write access to /infra and /.github/workflows, quietly merges a deployment change, and ships to production by accident. CODEOWNERS blocks this cleanly.

5. Treating the engagement as one-way. Good vendors will also share their own libraries, tests, and Docker setups back to you — preferably inside your repo. If the work never flows back, you are building dependence on an outside team.

KPIs that tell you the handover is healthy

Quality KPIs. PR review turnaround under 24 hours (vendor to you or vice versa); fewer than 2 reverts per 100 merges after week 3; static-analysis pass rate above 95% on the vendor’s PRs.

Business KPIs. First shipped feature by end of week 2; sprint velocity within 20% of your internal team’s by week 6; production incidents attributable to vendor code below 1 per month by month 3.

Reliability KPIs. Zero re-introduced secrets (monthly scan); zero unauthorized branch pushes (quarterly audit-log review); 100% of vendor accounts covered by 2FA and included in the quarterly access re-attestation.

FAQ

What to Read Next

Ready to hand over code to a team that knows what to do with it?

Sharing source code with a new development team is not a risk to avoid — it is a risk to manage. The right legal documents (NDA + IP Assignment + DPA, plus escrow if the stakes are high), the right access pattern (feature-branch + CODEOWNERS + branch protection), and a 30-minute secrets sweep before you open the repo collapse most of the downside. What you gain is a team that can ship real work in two weeks instead of two months.

If you are weighing a handover right now, run the 5-question decision framework first, fix any “no” answers, and then bring a vendor in under proper controls. If that vendor is Fora Soft, you already know our standards — and if it is not, the same playbook applies. Either way, do not let the fear of sharing source code cost you three months of shipping velocity.