Development environments sit in an awkward spot in most network architectures. They need access to source code repositories, package registries, build systems, and testing infrastructure. Developers need internet access for documentation, package downloads, and collaboration tools. This combination of broad access requirements and internet connectivity makes development networks a prime target for attackers.
When a developer's machine is compromised, the attacker inherits that machine's network access. Without proper segmentation, this can mean access to build servers, artifact repositories, secrets management systems, and sometimes even production environments. The SolarWinds attack demonstrated this pattern at scale: the build environment was the attack vector that led to production compromise.
Why Development Networks Are Different
Production environments have decades of security best practices: firewalls, IDS/IPS, WAFs, load balancers with security features, and strict access controls. Development environments, by contrast, are often treated as internal trusted zones with minimal controls.
This disparity exists for understandable reasons. Developers need flexibility. They install tools, run local servers, test configurations, and troubleshoot issues that require broad access. Security controls that slow down development face resistance. But the compromise between developer productivity and network security does not have to be all-or-nothing.
Segmentation Architecture
A properly segmented development network divides infrastructure into zones with controlled communication between them.
Developer workstations. Individual developer machines should be on their own network segment with controlled egress. Outbound access should be limited to approved destinations: source code repositories, package registries (through a proxy), collaboration tools, and documentation sites.
Build and CI/CD systems. Build servers, CI/CD runners, and related infrastructure should be on a separate segment with no direct access from developer workstations. Developers interact with CI/CD through APIs and web interfaces, not direct network connections.
Artifact storage. Package repositories, container registries, and artifact stores should be on their own segment. Build systems can publish to artifact storage, and deployment systems can read from it, but developer workstations should only have read access through authenticated APIs.
Secrets management. Vault, AWS Secrets Manager, or similar systems should be on an isolated segment accessible only by authorized services. Developer workstations should never have direct access to secrets management infrastructure.
Testing environments. Staging, QA, and testing environments should be segmented from both development and production. Test environments often contain production-like data and configurations, making them attractive targets.
Implementing Segmentation
VLANs and subnets. The most basic segmentation uses VLANs and IP subnets. Each zone gets its own VLAN with firewall rules controlling inter-VLAN traffic. This works for on-premises infrastructure but requires physical or virtual network infrastructure.
Micro-segmentation. Software-defined networking tools (VMware NSX, Cisco ACI, Illumio) can implement granular segmentation without VLAN changes. Micro-segmentation applies policies at the workload level, controlling which processes can communicate with which endpoints.
Cloud-native segmentation. In cloud environments, use VPCs (AWS), VNets (Azure), or VPC networks (GCP) to isolate development infrastructure. Security groups and network ACLs provide firewall-equivalent controls. Private endpoints keep traffic within the cloud provider's network.
Container network policies. For Kubernetes-based development infrastructure, network policies control pod-to-pod communication. Calico, Cilium, and other CNI plugins enforce these policies at the container level.
Common Mistakes
Flat networks with security groups. Security groups alone are not segmentation. If all resources are on the same network and rely on security groups for isolation, a single misconfigured rule can expose everything.
VPN as a segment. A VPN provides encrypted transport, not segmentation. If all VPN users land on the same network segment, the VPN provides no isolation between users.
Allowing SSH everywhere. SSH access from developer workstations to build servers, artifact repositories, and other infrastructure is a common backdoor around segmentation. Use bastion hosts or zero-trust access tools instead.
Shared credentials across segments. If the same credentials work in the development segment and the production segment, segmentation provides limited protection. An attacker with stolen credentials can move between segments regardless of network controls.
Forgetting DNS. DNS traffic is often allowed through all firewalls. Attackers use DNS tunneling to exfiltrate data and maintain command-and-control channels. Monitor and control DNS traffic at segment boundaries.
Monitoring Segmented Networks
Segmentation creates natural monitoring points. Every connection that crosses a segment boundary passes through a controlled choke point where it can be logged, inspected, and blocked if suspicious.
Key monitoring focuses include unexpected cross-segment connections (a developer workstation connecting directly to a production database), high-volume data transfers between segments, new protocols or ports appearing in cross-segment traffic, and authentication failures at segment boundaries.
Balancing Security and Productivity
The key to successful segmentation is making the secure path the easy path. If developers have to bypass segmentation controls to do their jobs, they will -- and they will find creative ways to do it.
Provide self-service access to approved resources. Use SSO and MFA for cross-segment access rather than manual firewall rule requests. Automate common workflows so developers do not need direct access to infrastructure they currently SSH into.
How Safeguard.sh Helps
Safeguard.sh provides visibility into your software supply chain across network segments. The platform monitors build outputs, dependency changes, and artifact integrity regardless of where in your network the build occurs. By integrating with your CI/CD pipeline rather than requiring network-level access, Safeguard.sh adds supply chain security monitoring without complicating your segmentation architecture.