The buy side of the build-vs-buy question comes with a quiet assumption. Once you've purchased the platform, the work is mostly done. You picked a market leader; they maintain the roadmap, and operations follow a user guide.
A recent webinar we ran together with Palo Alto Networks makes a more interesting and more accurate case: buying well is where the work starts. The session, presented by Paweł Imiełowski, DevOps engineer at CodiLime, and Migara Ekanayake, solutions architect at Palo Alto Networks, showed how to take a commercial next-generation firewall platform and wrap it in a configuration-as-code workflow, so that network security changes move at the speed application teams already expect. The platform is bought. The operating model around it is built. And the second part is what determines how much value the first part delivers.
The problem the purchase doesn't solve
Migara opened with a picture most organizations will recognize. Application teams have adopted DevOps end-to-end, writing, testing, deploying, and monitoring software multiple times a day. But an application doesn't go live on the strength of the application team alone. It needs the network operations team, the security operations team, and often a compliance sign-off.
That's where the workflow breaks down. A developer who needs a new server first has to work out whether they even need a ticket. The ticket goes to an infrastructure engineer, then flows to network operations and finally to SecOps for the firewall rules and to compliance for the policy check. End-to-end takes days.
Nobody in the chain is blocked because the security platform lacks capability. They're blocked because the process around it is ticket-driven and manual. Buying a more capable firewall doesn't fix a workflow problem. This matters for the build-vs-buy question because it locates precisely where the engineering effort belongs: not in the platform, but in how the platform is operated.
Treating security configuration as code
The answer the two presenters demonstrated is to manage firewall configuration the way developers manage software: as code, in a Git repository, with changes flowing through review and an automated pipeline.
Paweł walked through what the shift buys you, and it's worth separating the three benefits because they answer different pains. The first is code management: every configuration resource lives in one repository instead of being scattered across devices, ticketing systems, and someone's script folder. The second is auditability: every change is committed with an author, a description, and a reviewable diff, so the question "why is this rule even here?" has an answer in the Git history. The third is repeatability, and it's the one with the best business case. If an environment breaks and everything was configured manually or semi-manually, rebuilding it can take days or weeks, during which testing stops, and sometimes production too. If the configuration is code, you redeploy it.
The demo made this concrete with a deliberately everyday scenario: a newly deployed application that needs internet access opened through the firewall. The stack was a GitLab instance as the single source of truth and CI/CD engine, Terraform as the configuration tool, and on the Palo Alto Networks side, Panorama (the firewall management system) driving VM-Series next-generation firewalls in AWS.
Playing the developer, Paweł wrote the security policy as a few lines of readable code on a new branch, then opened a merge request explaining the change. Playing the network operator, Migara reviewed the diff. This is where the workflow earns its keep: the reviewer sees exactly what will change, line by line, and can comment on a specific line before anything touches a device. Approval merges the change into the main branch, the source of truth.
From there, the pipeline takes over: validation of the code itself, a Terraform plan showing precisely what will change in the environment, and then applying. The final stages use the platform's own safety mechanism. Changes land first in Panorama's candidate configuration, then get promoted to the running configuration through a commit. At that point, the platform validates the change against everything already running before pushing it to the right device. In the demo, once the change was approved, the pipeline had the application reachable within minutes. The presenters were candid that they were compressing the review step for time; in production, approval is a human gate that takes as long as your policy needs. What the workflow removes isn't the review, it's the opacity and the manual toil around it.
Where "customize" actually lives
Here's the part that should reassure anyone hearing "buy and customize" as a euphemism for an expensive integration project: almost nothing in the demo was exotic.
The pipeline was built from tools most organizations already run, such as a version control system, a CI system, and Terraform. Migara was explicit that Ansible or SaltStack work just as well: "if your team is more comfortable with Ansible, there's no reason to go find another tool to complicate things.
And the platform side meets the effort halfway. Palo Alto Networks publishes next-generation firewall modules on the Terraform registry, which the session pointed to as the kickstart for anyone wanting to try the workflow. This is the modern shape of a well-bought platform: it exposes its management plane as code and expects to be operated that way. The customization comes from assembling the workflow around it to fit how your organization ships software.
The demo also showed how far the tailoring can go. The Terraform syntax stayed close to the platform's own language, but the presenters noted you can abstract further by trimming the interface down until a developer supplies only the essential bits, with the pipeline generating the rest. How much you expose is a design decision, tuned to who is making the change.
The organizational shift underneath
The deeper change the workflow enables is about who does what. Migara framed it as shifting responsibility to where it belongs. Application developers know their application's connectivity requirements better than anyone, especially as architectures evolve from monoliths to microservices and connectivity grows more complex. So let them request the change, in a familiar language, from their own repository. Network and security engineers, instead of transcribing tickets, move into the roles the demo modeled: reviewers of proposed changes and publishers of the reusable modules that developers consume. Compliance stops being a meeting and becomes a pipeline stage. Business policy is codified as automated checks, so an overly broad rule is caught before it reaches a device.
None of this arrives by simply saying it, and the closing best practices were candid about the adoption path. Divide and conquer: start with the lowest-risk applications, where the blast radius is small and recovery is easy, rather than rolling out config as code across the entire estate. Match automation to your risk appetite: the demo ran fully automated, but a manual approval gate before apply is a legitimate design, and semi-automation is still a win. Protect the source of truth: once an aspect of configuration is automated, ClickOps on that aspect has to stop, or you end up with two states and no truth. And invest in training. For this to work, network and security engineers need to be genuinely comfortable with Git and the workflow.
What this says about the buy decision
Read as a build-vs-buy story, the webinar lands on a clean division of labor. The platform is the part you buy: the firewall capability, the management plane, the vendor's roadmap, the validation logic in that commit step. The operating model is the part you build: the repository structure, the pipeline stages, the review policy, the compliance checks, the level of abstraction offered to developers. That part is yours because it encodes decisions only your organization can make: your risk appetite, your team boundaries, your definition of a compliant change.
And it's the second part that converts the first into business value. The firewall was just as capable before the demo as after. What changed was the workflow around it and with it, how a security change moves: from an opaque ticket queue to a reviewable, testable, deterministic change that anyone can see the shape of before it ships.
Buying the platform answers the capability question. How you operate it is still an engineering decision, and, when done well, a surprisingly small one to start: a Git repository, a pipeline, one low-risk application, and the modules already published to get you moving.
