Dispatch From the Other Side: From Scripts to Software

Source: Dev.to

Introduction

At the start of my career as a security engineer, I built an allow‑list management system for our web gateway within the security operations center (SOC). Beyond a simple script, it became a live system that a core security component relied on. A single mistake—blocking a /3 instead of a /32 IP range—broke access for a third of the internet for all 40,000 employees. That incident made it clear that the system I created had to prevent such catastrophic errors.

Regular discussions between the SOC analyst manager, my manager, and me highlighted the impact my code had on others’ work. It was the first time I felt responsible for software, not just automation.

Crossing Over: From Security to Platform Engineering

This series explores the lessons I learned as I moved from security engineering to platform engineering. I’ll share what I would tell my past self and how I now approach problem‑solving with a software‑and‑platform‑engineer’s perspective.

• For security practitioners: A glimpse of what lies on the other side.
• For developers working with security teams: Insight into why we think the way we do.

Managing Growing Vulnerabilities

While in the security organization, I noticed that the number of vulnerabilities grew faster than we could remediate them, even with frequent patching. As cloud platforms emerged, misconfiguration findings added to the load. To avoid repeating the same outcome, I changed my approach.

Preventative Platform Controls

Instead of creating more findings to track, I identified platform controls acceptable to all parties. Public S3 buckets were a common source of data leakage, so I implemented a preventative control that disallowed public buckets outright. This eliminated that class of issue for both development and vulnerability‑management teams.

Collaboration and Rollbacks

The security team does not own and operate every system in an enterprise, but working with a single platform or infrastructure team—rather than 50‑100—greatly reduces remediation time. Occasionally, we had to roll back a control because it negatively impacted a team’s ability to operate its systems.

• Lesson: Progressive rollouts are essential, a practice already common in software engineering.
• Policy‑as‑Code: Allows us to revert to an older policy version in minutes.

Transferable Skillsets

Many security skillsets proved more portable than expected:

• Security reviews prepared me for system design discussions and operational troubleshooting.
• Incident response experience—tracking an attacker’s footsteps—helped me debug live systems by stitching together timelines from logs and traces.

Building Effective Controls

The most effective controls I’ve built stem from understanding how development teams work and finding ways to remove risk without adding friction. While not everyone needs to become a software engineer, grasping core concepts and ways of working enables solutions that don’t slow teams down.

Next Topic

In the next post, we’ll explore CI/CD and how to balance effective controls, defaults, and exceptions.