Application Security at Scale

Before a new app went live at one of PwC's largest clients, it came to us, and our job was to break in. On a good day that meant code running on their server, then admin rights, then the whole box.

The challenge

We were the last security step in a global consumer brand's software lifecycle, covering 500 to 600 web and mobile applications a year. Each one had to be tested before launch, on a schedule that product teams depended on.

The work arrived uneven. Most of it was static sites, a few hours each. The larger apps, about a third of the volume, took a day or two, and a mobile app took longer still, because we decompiled it first. And when I joined, the engagement ran on a scatter of disconnected spreadsheets, so nobody had one view of what was due, who was on it, or whether we'd meet the SLA.

What I built

For the product teams, an assessment was a promise: hand us the app, and on the agreed date you get a report that says what an attacker could do and how to fix it. A full assessment started black-box, from the outside like an attacker, and finished white-box, with access to more of the app. Automated tools mapped the app's footprint, fuzzed its inputs and scripted the obvious attacks. Then we went in by hand, looking for a foothold.

Around the testing I built the machinery that kept hundreds of assessments a year on time: one Google Sheets tracker with Apps Script automating the scheduling, time allocation, SLA tracking and budgets.

How it came together

I started on the project management side, so the tracker came first: replacing the scattered spreadsheets with one source of truth that scheduled itself. Within my first two months, the automation had taken over about $40,000 a year of manual work.

As I got more comfortable with web assessments, I turned to the testing itself. I standardized the scripts we used for automated scanning, and wrote templates for our top 100 findings that scripts could fill in, so a report started from the evidence instead of a blank page.

From there I moved into external penetration testing, mostly for industrial clients. It came easily, because the foothold that ends a web assessment is often how a penetration test begins. I also shaped the strategy for two threat and vulnerability management engagements in their early stages, before handing them on and joining PwC's Emerging Technology group.

What happened

We found something every day. Most often it was a violation of the client's security policies, and OWASP Top 10 vulnerabilities came up daily too. The findings I remember best were the chains: a remote code execution flaw that let us escalate privileges until we owned the box.

What I'd take forward

Most of what I build today rests on those years: reading an app or a network as an architecture, thinking through the ways in, weighing risk, and keeping identity tight. Above all, never trusting input. Agents read text written by strangers now, so when I design an agent system, I start from the same assumption I made at the start of every assessment: whatever comes in is hostile until proven otherwise.