01
Security Architecture
Start with the assumptions that would hurt most if they were wrong.
- Tenant isolation and authorisation requirements
- Trust boundaries engineers can use
Outcome
Engineers know what the product must preserve.
Product Security is what must stay true as the product changes
Application Security finds vulnerabilities. Product Security starts with the things your customers cannot afford to get wrong, then helps the team check them after the next release.
Start with what the product must protect
Product Security begins with the properties a product has to preserve for its customers: tenant isolation, authorisation, sensitive data handling, identity boundaries, safe integrations, and the ability to answer a customer’s questions with evidence.
It is a way for an engineering organisation to decide what cannot break and check that decision as the product evolves. It may use tools and one-off tests, but neither is enough on its own.
The useful measure is not how many findings were closed. It is whether the team can answer two questions without guessing: what does this product have to preserve, and does it still?
It is different from Application Security
Application Security and Product Security work together. Application Security asks whether something is vulnerable. Product Security asks whether the properties the product promises are still true. A team selling to larger customers usually needs both, but often has only the first.
| Application Security | Product Security | |
|---|---|---|
| Primary question | Is this release vulnerable? | Do the important parts of the product still behave securely? |
| Typical work | Scans, pentests, triage, findings | Requirements, threat models, fixes, verification |
| Output | A list of issues to fix | A way to catch the same issues when they return |
| Time horizon | A point in time: a release or an audit | A check that follows the product through releases |
| Typical owner | A security team or external assessor | Engineering, with security setting the bar |
| Failure mode | Findings pile up and fixes are not verified | Nobody can show which properties the product must preserve |
For a deeper comparison, see Product Security vs Application Security.
When the old arrangement no longer covers the questions
It often starts with a customer you did not have before: a mid-market or enterprise buyer with a security review of its own. They like the product. Then the questionnaire arrives, and your answers start to influence whether the deal closes.
By then the company often looks ready. There is an Enterprise plan, SSO and audit logs are on the feature list, and a Security page gives procurement something to read. The product is multi-tenant, with APIs and integrations that other companies now depend on.
There may not be a Product Security function yet. Strong engineers are covering security around their normal work, and an annual pentest keeps the lights on. That was enough while the customers were smaller. The questions are harder now, and the answers take more than a report.
The problem shows up when a customer asks whether one tenant can reach another tenant’s data, or whether authorisation is enforced on every important path, and nobody has a current answer. Product Security then has to become part of how the product is built, rather than a periodic chore.
Three kinds of work that need to connect
The work usually falls into three areas. A team may be strong in one and still have a gap in the others. Customer questions tend to expose that gap quickly.
02
Security Engineering
Turn a finding into work someone can own, ship, and revisit.
- A remediation workflow with clear ownership
- Controls in code and delivery
Outcome
Security work has a place in the product backlog.
03
Continuous Assurance
After a fix ships, check that it survived the next change.
- Verification for important fixes
- Evidence of regressions being caught
Outcome
Customer answers are backed by current evidence.
Product Security resources
Product Security vs Application Security
Application Security finds and fixes bugs. Product Security keeps the security properties of your product true over time. Here is the practical difference.
Read moreWhat is Product Security Engineering?
Product Security Engineering turns security requirements and threat models into engineering work that ships and stays fixed.
Read moreProduct Security Assessment
A one-week Product Security Assessment that shows where your security effort is fragmented and what deserves investment next.
Read moreSecurity Remediation and Vulnerability Retesting
Why findings pile up and how to verify a fix really removed the risk instead of marking it resolved.
Read moreContinuous Product Security Assurance
How to prove the controls your customers depend on still work as the product and the team change between audits.
Read moreProduct Security for B2B SaaS
What B2B SaaS vendors moving upmarket need in place before enterprise buyers and security reviews raise the bar.
Read moreStart with the Product Security Assessment
One week at a fixed fee, and a clear picture of where your Product Security effort is fragmented and what deserves investment next.