Remote development teams rely on VPNs to access internal resources: source code repositories, build servers, artifact registries, and deployment infrastructure. But VPN security for development teams involves more than just encrypting traffic. The way the VPN is configured, how credentials are managed, and what happens on the developer's endpoint all affect the security of your software supply chain.
A compromised VPN connection gives attackers the same access as the developer. If that developer has access to the CI/CD pipeline, artifact repository, or deployment systems, the attacker does too. The 2020 compromise of several VPN appliances (Pulse Secure, Fortinet, Citrix ADC) demonstrated that VPN infrastructure itself is a high-value target.
Split Tunneling Risks
Split tunneling routes only corporate-destined traffic through the VPN, letting other traffic go directly to the internet. This improves performance and reduces VPN bandwidth usage. But for development teams, split tunneling creates specific risks.
DNS leaks. When a developer resolves a package registry hostname, the DNS query may go through the public resolver instead of the corporate resolver. An attacker performing DNS spoofing can redirect package downloads to malicious servers.
Mixed trust traffic. A developer might be downloading packages from a public registry (through the internet) and pushing builds to the internal CI/CD system (through the VPN) simultaneously. If the public internet connection is compromised, the attacker can see what packages are being downloaded and potentially inject malicious responses.
Endpoint exposure. Without full tunnel VPN, the developer's machine is directly exposed to the local network. In a coffee shop, hotel, or co-working space, this means potential exposure to network-based attacks.
For development teams with access to build infrastructure, full tunnel VPN is generally more appropriate than split tunneling. The performance cost is worth the security benefit.
VPN Credential Security
VPN credentials for development teams deserve extra attention because they protect access to supply chain infrastructure.
Certificate-based authentication. Use client certificates instead of username/password for VPN authentication. Certificates are harder to phish, cannot be reused across services, and can be tied to specific devices.
MFA enforcement. Require multi-factor authentication for all VPN connections. TOTP, hardware keys (YubiKey), or push-based MFA (Duo) add a layer of protection against credential theft.
Short-lived credentials. If possible, use VPN solutions that support short-lived certificates or tokens. A certificate that expires every 8 hours limits the window of exposure if the credential is compromised.
Per-device certificates. Issue unique certificates for each developer device. If a device is lost or compromised, revoke only that device's certificate without affecting other team members.
Endpoint Security Requirements
The VPN is only as secure as the endpoints connecting to it. For remote development teams, endpoint security requirements should be enforced before VPN access is granted.
Device compliance checks. Modern VPN solutions can verify device compliance before allowing connection. Check for OS updates, endpoint protection software, disk encryption, and firewall status.
Managed vs. personal devices. Ideally, development work happens on managed devices with organizational security controls. If personal devices are allowed, enforce minimum security requirements through device compliance checks.
Local development environment isolation. Developers running local containers, virtual machines, and development servers create additional attack surface. Ensure that local development environments do not expose services to the network that could be exploited by other devices on the same VPN.
VPN Architecture for Development
Hub-and-spoke vs. mesh. Traditional hub-and-spoke VPN routes all traffic through a central gateway. This creates a bottleneck and a single point of failure. Mesh VPN architectures (WireGuard-based solutions like Tailscale or Netmaker) allow direct peer-to-peer connections between authorized devices, reducing latency and eliminating the central bottleneck.
Per-application VPN. Instead of a full network VPN, consider per-application tunneling. Developers get VPN access only to specific applications (Git, CI/CD, artifact registry) rather than the entire network. This limits lateral movement if the developer's machine is compromised.
Always-on VPN. For teams with access to critical supply chain infrastructure, always-on VPN ensures that all traffic is protected regardless of the developer's location. This eliminates the risk of developers forgetting to connect before accessing sensitive resources.
Monitoring VPN Usage
VPN logs are a valuable source of security intelligence. Monitor for unusual connection patterns that might indicate compromise, such as connections from unexpected locations, simultaneous connections from the same credentials on different IP addresses, connections outside normal working hours, and unusually high bandwidth usage.
For supply chain security specifically, correlate VPN connection times with CI/CD activity. A build triggered from a VPN session that connected from an unusual location deserves investigation.
Moving Beyond VPN
VPNs are a transitional technology for many organizations. Zero Trust Network Access (ZTNA) solutions provide more granular access control, better user experience, and stronger security than traditional VPNs. Solutions like Zscaler Private Access, Cloudflare Access, and Tailscale provide application-level access without the complexity and overhead of traditional VPN infrastructure.
For development teams, the move from VPN to ZTNA means each application (Git, CI/CD, artifact registry) has its own access policy. Developers get access to exactly what they need, and nothing more.
How Safeguard.sh Helps
Safeguard.sh monitors your software supply chain regardless of how developers access your infrastructure. The platform integrates with your CI/CD pipeline and artifact repositories to detect unauthorized changes, compromised dependencies, and anomalous build patterns. Whether your team uses VPN, ZTNA, or direct cloud access, Safeguard.sh provides the supply chain visibility layer that network-level controls alone cannot offer.