Product Security problems in startups are rarely caused by a complete absence of security. More often, security exists — but it grew organically, unevenly, and without a clear operating model.
Over time, I reviewed a sample of 15 anonymized Product Security engagements across startups, scale-ups, and growing software companies.
The environments were different. So were the architectures, cloud platforms, engineering maturity, and business constraints.
But the same patterns kept appearing.
This is not intended to be an industry benchmark. The sample is small, the percentages are rounded, and the observations are directional. What makes the data useful is not statistical significance — it is the recurrence of the same practical problems across different teams.
And many of those problems were much easier to fix than companies initially expected.
The Snapshot
Here are four quantitative signals that stood out across the engagements.
| Signal | Observation | What It Usually Meant |
|---|---|---|
| Baseline controls | ~40% | Missing, outdated, or incomplete foundational security controls |
| Configuration risk | 60+ artifacts | Defaults or security-relevant misconfigurations across infrastructure, CI/CD, cloud, Kubernetes, and services |
| Security cost perception | ~70% | Teams initially expected meaningful security to require enterprise-level spending |
| Automation & metrics | 80–85% | Limited aggregation, automation, ownership context, or useful security metrics |
The common problem was not a lack of effort.
It was a lack of structure, prioritization, ownership, and feedback loops.
1. About 40% Had Gaps in Foundational Controls
Roughly 6 out of 15 engagements showed missing, outdated, or poorly aligned baseline controls.
That did not necessarily mean there was “no security.” Often, controls already existed.
MFA was enabled — but not everywhere. Scanners were running — but coverage was incomplete. Vulnerability tickets existed — but ownership and closure criteria were unclear. Security decisions had been made years earlier — while the architecture had changed significantly since then.
This happens naturally in fast-moving companies. A startup adds repositories, cloud accounts, services, APIs, CI/CD pipelines, employees, contractors, and customer requirements much faster than its original security model evolves.
The result is security drift. The solution is usually not a massive transformation program.
It starts with understanding the critical products, assets, identities, delivery paths, sensitive data, and external exposure — and then fixing the controls that reduce the most meaningful product risk first.
Security does not have to start big. It has to start right.
2. We Found More Than 60 Security-Relevant Configuration Issues
Across the sample, 60+ configuration artifacts contained defaults or security-relevant misconfigurations.
These appeared across cloud infrastructure, Kubernetes, CI/CD, application services, access policies, and infrastructure-as-code. And this is one of the easiest security problems to understand. Developers and infrastructure engineers are primarily responsible for making systems work.
Security teams ask an additional question: How can this configuration be abused?
A perfectly functional configuration may still have overly broad permissions, unnecessary network exposure, debug behavior enabled in production, weak policy enforcement, unmanaged secrets, or default settings that no longer make sense for the environment.
Individually, many of these issues look small. Combined across identities, workloads, pipelines, and cloud services, they can create meaningful attack paths. The scalable answer is not manually fixing every configuration forever.
It is moving toward secure-by-default patterns: reusable templates, hardened baselines, configuration-as-code, automated checks, and policy enforcement where blocking is justified.
Working configuration is not the same as secure configuration.
3. Around 70% Initially Expected Security to Be Expensive
This was one of the most interesting patterns.
Around 70% of the teams initially perceived meaningful Product Security as something that would require major investment: expensive platforms, a dedicated department, multiple security engineers, or a large outsourcing engagement.
In many cases, that assumption was wrong. For a smaller product organization, a strong baseline can often be built using capabilities the company already has.
Cloud providers already include significant security functionality. Git hosting and CI/CD platforms provide native controls. Mature open-source projects can cover important parts of SAST, SCA, secrets detection, container scanning, IaC scanning, policy-as-code, and other workflows.
Commercial products absolutely have their place. But buying technology before understanding risk frequently creates tool overlap instead of security maturity.
A better sequence is:
Understand the product → identify meaningful risks → design the minimum useful control set → automate repeatable decisions → buy technology where it creates real leverage.
For a bounded product and cloud environment, even a two-engineer or fractional security model can often establish a meaningful operating baseline over roughly 90–100 days, depending on architecture, complexity, and implementation capacity.
Security becomes dramatically less expensive when architecture, scope, and priorities are clear.
4. 80–85% Were Missing Useful Automation or Metrics
This was the most common quantitative signal.
Approximately 12–13 of the 15 engagements had limited security automation, aggregation, or business-facing metrics.
Interestingly, this rarely meant that security data did not exist. There was often too much of it. Scanner findings. Cloud alerts. Tickets. Spreadsheets. CI/CD results. Vulnerability exports. Dependency data. Infrastructure findings. The problem was turning those disconnected outputs into decisions.
Without normalization and context, leadership sees vulnerability counts instead of risk. Engineering sees noise instead of priorities. Security teams spend time reconciling tools instead of reducing exposure.
A lightweight decision layer can change this significantly.
Useful metrics might include control coverage, risk debt, remediation velocity, exception health, release confidence, vulnerability aging, and ownership.
The goal is not to build another massive analytics platform. It is to answer simple questions:
Are we reducing important risk? Are controls actually working? Are critical issues closing faster? Where should the next dollar or engineering hour go?
Measure what changes a decision — not what is easiest to count.
Three More Patterns That Numbers Alone Do Not Show
Three qualitative patterns appeared repeatedly as well.
Security checks arrive too late. A penetration test before release or a scanner after the build may identify real problems, but often at the point where architecture is already fixed and remediation is expensive. The best security control is frequently the one placed immediately before the decision it is supposed to influence.
Ownership can be a bigger problem than tooling. A company can operate excellent scanners and still carry vulnerabilities indefinitely if nobody owns remediation, escalation, risk acceptance, exception expiration, or verification. A finding without an accountable owner is information — not risk reduction.
The product boundary is larger than the application boundary. Modern products cross applications, APIs, CI/CD systems, workload identities, IAM, secrets, cloud resources, Kubernetes, third-party services, and data stores. Reviewing every component independently can miss the path between them. Attackers do not respect organizational or architectural diagrams.
What Can a Lean Team Actually Do in 90 Days?
The encouraging part is that none of this automatically requires an enterprise-sized security organization.
A practical minimum viable Product Security program can be built incrementally.
During the first 30 days, understand the environment: critical products, repositories, identities, cloud accounts, sensitive data, delivery paths, obvious exposure, and the highest-value trust boundaries.
During days 31–60, integrate repeatable controls into normal engineering workflows: SAST, SCA, secrets detection, IaC and container checks where appropriate, secure configuration patterns, risk-based release gates, and clear vulnerability ownership.
During days 61–90, build the feedback loop: measure coverage and remediation, validate critical attack paths, review exceptions, create reusable evidence, and decide what the next 90 days should address based on real data.
The point is not to reach “perfect security” in three months. The point is to create a security system that can keep improving itself.
Product Security Is an Operating Model, Not a Toolchain
After looking across these engagements, my biggest takeaway is simple:
Most lean teams do not need more security everywhere. They need better security at the decisions that matter.
A sustainable Product Security program connects four things:
People — who owns the decision?
Process — how does the work move?
Controls — where is risk actually reduced?
Evidence — can we prove that the system is improving?
When those four pieces work together, security stops being a parallel organization that slows engineering down.
It becomes part of the way the company builds software. That is the model I believe works particularly well for startups and growing software companies:
Start narrow. Solve the real problem. Expand with evidence.
About the analysis
The observations in this article are based on a sample of 15 anonymized real-world Product Security engagements from my professional experience. The percentages are intentionally rounded and should be treated as directional observations rather than an industry-wide benchmark. No client identities or sensitive engagement data are included.
Ivan Piskunov
Bulwark Advisory — Product Security. Real-World Results.
Top comments (0)