Philippines staffing research · Published: October 2, 2026

What repository access should an outsourced developer receive?

A least-privilege model that separates source contribution, automation, merge rights, and production authority.

Repository access is not a binary choice between trust and no trust. It is a set of capabilities: seeing code, creating branches, opening pull requests, running automation, reading issues, managing settings, approving changes, merging protected branches, accessing secrets, and triggering releases. A company hiring a Philippines-based programmer should assign only what the first work lane requires, then expand from observed need. The question is not “Can this person have GitHub?” It is “Which named actions must this role perform, on which repositories and environments, with which review and recovery controls?”

This study uses threat-and-task mapping. Define expected work and assets, map every task to platform permissions, test normal delivery and prohibited boundaries with a disposable account, and record owner-only actions. GitHub and NIST establish platform behavior and security principles. The recommended matrix is an inference for outsourced delivery, not a universal model. No client access logs were used and no incident reduction is asserted. Sources were checked October 2, 2026.

Inventory before inviting. List repositories, forks, packages, Actions, environments, issue trackers, wikis, code owners, branch rules, deploy keys, installed apps, and external CI. Classify them by the assigned work. A shared monorepo may expose customer code or infrastructure unrelated to the task, making read access broader than it appears. If a task can be isolated safely, prefer a scoped repository or sanitized fixture. Never copy secrets or customer data into a new repository merely to simplify administration.

Use a named individual identity, supported multi-factor authentication, and no shared credentials or tokens passed through chat. Organization membership and outside-collaborator models create different visibility; choose deliberately and document removal ownership. Verify invitations through an approved channel. A profile name is not proof. Record account, repository, role, start date, approver, business reason, and review date in an access register without storing authentication material.

Routine feature work often needs read access plus a branch or fork and pull-request creation. Protect production branches from direct writes, require review for material changes, and keep rule administration with a company owner. The programmer may read CI results without editing secrets or bypassing checks. Test the exact identity: clone, create a work branch, open a draft, receive review, and attempt one explicitly prohibited action. Documentation screenshots are weaker than a boundary test because inherited team membership changes effective access.

Automation creates another authority plane. A pull request can cause workflows to read tokens, publish packages, comment externally, or deploy previews. Inspect triggers, fork behavior, environment approvals, and whether untrusted code reaches secrets. Write access may permit workflow edits, so human approval or restricted environments remain important. Masking log values does not make arbitrary code safe. Use low-risk preview credentials, synthetic data, and owner-approved production environments.

Separate review from merge and release. An outsourced senior developer may provide valuable approval while the company requires a staff owner for protected branches. Allowing merge need not imply deployment. Write the split in branch rules, code owners, and runbooks. Emergency bypass should be attributable, time-bounded, and reviewed. If the platform cannot express the desired separation, add an external approval or narrow the work lane rather than rely on an unwritten promise.

Issue access can leak as much as source. Tickets may contain customer details, vulnerability reports, pricing, credentials pasted by mistake, or plans outside the role. Scope boards and chat channels along the same task boundaries. Provide a private vulnerability route. A programmer discovering a secret in history should escalate without copying it elsewhere. Rotation and cleanup remain company incident decisions, while the developer can identify affected revisions and remove active references.

Review access after the first pull request, any lane expansion, and at a fixed recertification interval. Compare permission with recent work instead of merely asking whether it is still needed. Give stale memberships, dormant tokens, unused deploy keys, and automation ownership explicit dispositions. Removal is not a judgment about the programmer; it is normal when a task no longer requires a capability.

Offboarding begins before the final day. Identify company-owned branches, open reviews, packages, documentation, outstanding credentials, and scheduled automation. Transfer ownership, then remove repository, issue, chat, VPN, cloud, and vault access through authoritative systems. Revoke tokens even if expected to expire. Test that the identity no longer reaches resources and that builds do not depend on a personal fork or user-owned secret.

The access matrix distinguishes fact, analysis, and uncertainty. A platform role and denied-action test are facts. Sufficiency is analysis against the task map. Unknown installed apps, inherited policy, self-hosted runners, undiscovered secrets, and untested external systems are uncertainty. Record exceptions with owner and expiry. “Least privilege” alone is not evidence; exact allowed and denied actions are.

Limitations include changing platform models and integrations that extend authority beyond the user interface. A test repository may not reproduce enterprise policy or production runners. Small teams may require one person to merge, but that is an explicit risk choice with review and rollback. GitHub describes roles, branches, and Actions security; NIST describes account management. Neither knows the company's architecture or contract. Qualified owners must address regulated data.

Approve access only when a work lane maps to exact repositories, capabilities, automation exposure, owner-only actions, and removal timing. Return requests for admin “just in case.” A Philippines-based developer can own branches, pull requests, tests, and documentation while a company owner retains secrets, rules, protected-branch exceptions, production environments, and commercial decisions. Location or employment model never substitutes for sound identity engineering.

A concrete access worksheet should contain one row per action rather than one row per job title. “Read application source,” “create a branch,” “trigger an unprivileged preview,” “view a failed test log,” “approve a dependency update,” “merge main,” and “approve production” are separate actions with separate evidence. For each row, name the repository or environment, granting mechanism, approver, test, review date, and revocation event. Then inspect privilege escalation paths: team maintainers who can add members, workflow editors who can print tokens, package maintainers who can replace a dependency, and cloud identities assumed from CI. This catches authority hidden behind a modest repository label.

Use time-bounded elevation for the unusual task. If a developer must inspect a protected setting or recover a release, open a ticket describing the reason, grant the smallest temporary capability, observe the action through platform logs, and remove it at the promised time. Do not leave elevated access in place because another incident might occur. For unavailable staff, use company-controlled break-glass identities with post-use review, never the departed contributor's session. The access register should also distinguish user credentials from machine credentials: rotating one person's token does not retire a deploy key, GitHub App installation, runner registration token, or cloud federation rule. A final reviewer should reconcile the platform's effective membership and integration list against the register. That comparison, plus an actual denied-action test, supports a bounded conclusion that the intended lane works without unnecessary production authority.

Forks and local clones need an explicit data lifecycle. Decide whether private repository forking is allowed, where company code may be stored, whether full history is necessary, and how local copies are removed when the lane ends. Device controls should be proportional to the sensitivity of the source and agreed before access is issued. If the programmer uses a supplier-managed device, the company still needs a verifiable offboarding path rather than an unsupported promise that files were deleted. Avoid demanding invasive personal-device inspection; instead supply an approved managed workspace when stronger controls are required. Review package publishing separately from source contribution because a maintainer token can affect downstream users even without main-branch access. Require protected release workflows, provenance where supported, and an owner approval for public packages. Finally, rehearse a lost-device or compromised-token scenario: revoke the named credential, inspect platform audit events, rotate any exposed machine secret, and confirm normal contribution continues through a new approved identity. This demonstrates recoverability without granting a permanent administrative role.