This article expands on a topic originally discussed on devops.com. The concepts described reflect general industry thinking on integrating network security into CI/CD pipelines.
The Problem: Network Security Is the Last Manual Bottleneck
Modern DevOps practices have automated nearly every step of the software delivery lifecycle. Virtualization, public and private cloud platforms, and software-defined networking (SDN) mean that spinning up servers, provisioning storage, or launching entire environments can take minutes or even seconds. CI/CD pipelines handle builds, tests, and deployments with no human intervention.
Yet one step has stubbornly resisted automation: changing network connectivity and firewall rules. When a new application or service needs a firewall rule opened or a network flow provisioned, developers typically must stop, open a manual change request, wait for approval from a network security team, and then wait again for implementation. This single step can turn a sub-hour deployment into a multi-day process.
The Application Development–Security Disconnect
The friction is not just procedural—it is also a knowledge gap. Change request forms typically ask developers to specify firewall names, network zones, subnets, and IP addresses. Application developers often do not have this information and should not need it: their job is to describe what the application needs to communicate with, not to understand the underlying network topology.
Conversely, the network security team reviewing the request rarely has full context about why the application needs a particular connection, what business process it supports, or what the impact of a delay or denial will be. The result is back-and-forth communication that makes the process slow, error-prone, and frustrating for both sides.
The core challenge is balancing two legitimate needs:
- Developer agility: changes should flow through the pipeline automatically, without waiting on manual approvals for routine, low-risk connectivity.
- Security governance: not every connectivity change is routine or low-risk, and a fast pipeline that skips security checks simply moves the risk rather than eliminating it.
The Solution: Connectivity as Code
Connectivity as code is a methodology that brings network connectivity provisioning into the CI/CD pipeline as a first-class, automated step. Instead of opening a manual change request, developers declare their application’s connectivity requirements in a machine-readable file that lives alongside the application code in version control. The pipeline then handles connectivity provisioning, validation, and compliance checking automatically—just like it handles unit tests or infrastructure provisioning.
The key architectural idea is an abstraction layer that translates between the developer’s logical view of the application and the network security team’s physical view of the infrastructure. Developers work in terms of application components and logical flows; the abstraction layer maps those to the actual firewalls, zones, IP ranges, and security policies that the network team manages.
How Connectivity as Code Works in Practice
Step 1: Declare Connectivity Requirements
The developer creates a connectivity requirements file—a simple, human-readable, machine-parseable text file (YAML and JSON are common choices, though the methodology is format-agnostic) that lists all the logical flows the application needs. Each flow entry typically includes:
- Source: the component or service initiating the connection (e.g.,
app-server,frontend) - Destination: the component or service accepting the connection (e.g.,
database,payment-api) - Service/port: the protocol and port required (e.g.,
tcp/5432,https) - Environment: which deployment environment the flow applies to (development, staging, production)
Critically, the developer does not need to know IP addresses, subnet ranges, firewall names, or whether a firewall even exists between the two components. That translation is handled downstream by the automation tooling.
# Example connectivity requirements file (illustrative YAML)
flows:
- name: app-to-database
source: app-server
destination: postgres-db
service: tcp/5432
environments: [staging, production]
- name: app-to-payment-gateway
source: app-server
destination: payment-api
service: https
environments: [production]Code language: PHP (php)Step 2: The Connectivity Phase in the Pipeline
Once the requirements file exists, a dedicated connectivity phase is inserted into the CI/CD pipeline—typically between infrastructure provisioning and application deployment. This phase is handled by a Network Security Policy Management (NSPM) solution that reads the connectivity requirements file and takes one of three actions:
- No change required: If connectivity requirements have not changed since the last run, the NSPM solution verifies that all required flows are currently active and reachable. It returns a pass/fail signal to the pipeline, giving developers confidence that connectivity-related failures will not occur in production.
- Compliant new flow required: If a new or modified flow is needed and it complies with the organization’s pre-approved security policy, industry regulations, and security best practices, the NSPM solution automatically designs and pushes the required firewall rule changes to the relevant network devices—without any manual intervention.
- Non-compliant change required: If a requested flow does not comply with policy, the change is automatically escalated for human approval. Once approved, it is implemented automatically. The developer does not need to open a separate out-of-band change request.
Step 3: Ongoing Lifecycle Management
Because the connectivity requirements file lives in source control alongside the application code, it evolves with the application. When a new version of the application introduces new dependencies or removes old ones, the developer updates the file, and the connectivity phase on the next pipeline run handles provisioning and de-provisioning automatically. This means the connectivity state of the application is always documented, current, and reproducible—a significant improvement over firewall rules that accumulate over years with no clear ownership.
Benefits of Connectivity as Code
Faster, More Predictable Delivery
By automating the connectivity provisioning step, organizations remove one of the most common causes of deployment delay. Routine, policy-compliant connectivity changes no longer require waiting on a separate team. The pipeline moves forward automatically, and developers get clear, immediate feedback if a connectivity issue is anticipated before it reaches production.
Continuous Compliance and Auditability
Every connectivity change made through the pipeline is automatically checked against security policy and industry regulations before implementation. All changes are logged with full context—which application triggered the change, which pipeline run, which version of the connectivity requirements file. This creates a complete, timestamped audit trail that satisfies compliance requirements without any additional documentation effort from either the development or security team.
Business Continuity During Infrastructure Changes
Because connectivity requirements are explicitly documented and version-controlled, they can be used to restore or verify application connectivity after network architecture changes, cloud migrations, or server replacements. Instead of relying on institutional knowledge about which firewall rules support which applications, operations teams can re-run the connectivity phase against the current requirements file to ensure the application’s connectivity is intact.
Reduced Friction Between Development and Security
Perhaps most importantly, connectivity as code shifts the relationship between developers and network security teams. Developers no longer need to understand network topology to get their applications deployed, and security teams no longer receive context-free change requests that require back-and-forth clarification. The abstraction layer handles translation automatically, and the NSPM solution enforces policy consistently—giving security teams confidence that the pipeline is not bypassing their controls.
Where Connectivity as Code Fits in the Pipeline
A typical pipeline integration looks like this:
- Code commit triggers the pipeline.
- Build and unit test phase runs as normal.
- Infrastructure provisioning (Terraform, Ansible, CloudFormation, etc.) creates or updates compute and storage resources.
- Connectivity phase reads the connectivity requirements file, validates or provisions network flows, and returns pass/fail to the pipeline.
- Application deployment proceeds only if the connectivity phase passes.
- Integration and smoke tests validate end-to-end behavior, including connectivity.
This positioning ensures that connectivity is always validated before the application is deployed, eliminating the class of production failures caused by missing or misconfigured firewall rules.
Conclusion
Connectivity as code applies the same principles that have made infrastructure as code successful—declarative definitions, version control, automation, and auditability—to the domain of network security policy. By treating connectivity requirements as code rather than as manual change requests, organizations can eliminate one of the last significant manual bottlenecks in the CI/CD pipeline without weakening security controls or compliance posture.
The result is a genuine win for both sides of a historically tense relationship: development teams get the speed and autonomy they need, and security teams get consistent policy enforcement, full auditability, and confidence that risk checks are built into the delivery process rather than bypassed by it.