Product security
Three different mechanisms doing three different jobs. Most programmes build one, call it all three, and wonder why engineering routes around them.
Every product security programme eventually writes a standard. It says buckets holding customer data must use encryption, logging, least privilege, and blocked public access. It is correct. It is twenty pages long. And it asks a developer with a sprint commitment to become a part-time security architect.
That is the problem in one sentence. We hand engineers a specification and ask them to produce an implementation, on their own time, under delivery pressure, with no reference build. Then we audit the result and act surprised by the variance.
But "paved road" has become a catch-all, and the sloppiness costs real programmes. Three distinct mechanisms are doing three distinct jobs, and each fails differently when it's missing.
A paved road is an offer. A guardrail is a boundary. Assurance is evidence. Programmes that conflate them end up mandating offers, apologising for boundaries, and collecting evidence by asking people to remember things.
The test of a paved road is not whether it's secure. It's whether it's faster than the alternative. A road that costs a team two extra days is a road nobody drives on, no matter how well built.
Security is no longer asking developers to interpret a control. It's asking them to import one.
| Problem | Paved road | What engineering gets |
|---|---|---|
| New application | Secure application template | Repo, CI/CD, logging, IAM and security defaults on day one |
| Cloud workload | Approved reference architecture | Terraform / CloudFormation modules, already reviewed |
| API | Secure API pattern | OAuth/OIDC, authorization, rate limiting, validation, logging |
| Authentication | Identity pattern | Approved IdP libraries instead of hand-rolled auth |
| Secrets | Secrets-management module | Vault or Secrets Manager integration, no plaintext path |
| Containers | Secure container baseline | Minimal image, non-root, scanning, signing |
| Dependencies | Approved dependency pipeline | SCA, automated updates, license checks |
| CI/CD | Secure pipeline template | SAST, SCA, secrets, IaC and container scans pre-wired |
| GenAI and RAG | Secure AI reference architecture | Model gateway, RAG isolation, IAM, guardrails, telemetry |
| Agents | Agent security pattern | Scoped identity, tool allowlist, sandboxing, approval boundaries |
| Release | Security evidence automation | Evidence generated from the pipeline, not questionnaires |
Some outcomes shouldn't depend on anyone remembering the paved road existed. A guardrail is not advice delivered in a stern tone — it's an automated denial, enforced by the platform, that fires whether or not a human was paying attention.
Never ship a guardrail without the corresponding road. Blocking public storage while offering no compliant bucket module means you've removed the only route a team knew and handed them nothing. That single mistake is how product security earns its reputation, and it is entirely avoidable by sequencing: road first, rail second.
This is the level almost everyone skips, and it decides whether the other two survive contact with a delivery deadline.
A product team may legitimately need something the road doesn't offer — a legacy protocol, an acquired codebase, a customer contract with its own requirements. The answer cannot be "no," and it must never be "yes, quietly." It has to be a path with a named owner and an end date.
Four properties make an escape hatch real rather than ceremonial:
If product security doesn't provide an efficient exception mechanism, developers will eventually build roads around product security. Exception turnaround time predicts programme health better than any coverage metric.
Coverage metrics — repos scanned, controls documented — measure activity, not adoption. Four numbers that actually indicate whether the road is real:
Paved roads are expensive, and the cost lands on product security's budget rather than engineering's. You are absorbing work that was previously distributed — invisibly, badly, and at someone else's expense — across every team in the company.
That's the trade, and it's also the argument for the headcount. It's a stronger argument than risk reduction, because it's measurable in delivery time rather than in incidents that didn't happen.
The alternative is the twenty-page standard. Cheaper to write, satisfies the auditor, and quietly transfers the entire implementation burden to the people with the least time and the least context to carry it.
Then we call the resulting variance a culture problem.