01 Foundation
Security Architecture
Make product security assumptions explicit before teams add controls.
- Product security requirements
- Threat models engineers can use
Outcome
The product team knows what must remain secure.
Product Security Engineering for B2B software companies
Build Product Security that scales with the business
I help European and UK B2B software vendors make product security explicit and show that important controls still work.
Worked with engineering teams at
When security stops scaling
Early on, Product Security is often implicit. Senior engineers know the dangerous edges. The CTO reviews sensitive changes. Periodic testing keeps things moving.
That changes as B2B software companies move into larger or regulated customers.
Suddenly, customers want concrete answers about tenant isolation, authorisation, SSO, integrations, remediation, and security-critical behaviour. ISO 27001 and SOC 2 may already be in place. Annual pentests may be happening too, but they do not answer the underlying question:
Can you show that the security properties your customers depend on still hold as the product changes?
At that point, security is no longer a periodic activity. It is part of how the product scales.
The problem
Product Security connects security findings to the properties the product must preserve.
You may already have ISO 27001, pentest reports, scanners, security tickets, and strong findings from external assessors. That proves security work is happening. It does not prove the product is getting safer.
Many B2B software companies have a small AppSec function, or none at all. Findings arrive faster than engineering can triage and fix them well.
The real risk is not only an open vulnerability. It is the lack of a repeatable way to decide what matters and prove the fix worked.
- Findings pile up without clear ownership.
- Closed tickets do not prove risk is gone.
- Old vulnerability classes return.
- Security knowledge lives in people, not systems.
- Customer reviews ask for evidence the team struggles to produce.
- Security decisions are hard to defend.
Capabilities
Build the capability to ship safer product changes
Application Security, API security, Secure SDLC, remediation, and assurance sit underneath Product Security Engineering.
02 Delivery
Security Engineering
Turn security risks into engineering work that can be owned and shipped.
- Remediation workflow
- Controls in code and delivery
Outcome
Security work becomes actionable product work.
03 Assurance
Continuous Assurance
Check that important fixes still hold as the product changes.
- Fix verification
- Regression evidence
Outcome
The team can show that controls still work.
You may not need deeper work in every area. The assessment shows where intervention makes sense.
Outcomes
A cleaner pentest report is not the goal
Security properties are understood
Tenant isolation, authorisation, sensitive data flows, and other product requirements are clear enough to build against.
Findings become verified fixes
Findings are fixed according to the risk they represent.
Security can be evidenced
Important controls produce evidence that stands up to customer scrutiny.
"Søren quickly grasped the technical and business context of our project and added value from day one. His strong engineering background and structured thinking made collaboration seamless."
René Passmann
CEO, HAV Media
Assessment
Product Security Readiness Assessment
1 week · €2,000 fixed fee
We examine your current capability across Security Architecture, Security Engineering and Continuous Assurance.
No generic maturity score. No pentest report. No obligation to continue.
You leave with
- a map of how Product Security currently works;
- the three to five most important systemic gaps;
- a prioritised recommendation for what deserves investment;
- a proposed scope for deeper work, where intervention is justified.
If deeper work is warranted, I scope a fixed-price engagement in one or more of the three capability areas. If it is not, the assessment stands on its own.
Discuss an assessment
Søren Johanson
Product Security Engineer
I'm a software engineer specialising in Product and Application Security. I've worked on software supporting up to 50 million users and help teams make security practical inside engineering work.
Rather than producing another security report, I help engineering teams define what must remain secure and verify that important fixes hold.
Blog
Notes about Security
2026-09-02
AI, productivity and B2B SaaS
I'm deep into reading papers about AI, mostly with regard to secure code generation and trust in AI models. The landscape here is pretty thin though, with just a few papers...
Read more2026-09-01
AI still doesn't consider security proactively
AI has come a long way over the last few years, and I think by now everyone uses AI in one form or another to either help with the business (administrative tasks) or coding...
Read more2025-07-30
Your legacy API isn't the problem. Your documentation is.
For many mid-sized companies, an API exists somewhere in the system. It might have started years ago as an internal tool. Maybe it was built quickly to satisfy a one-off partner...
Read more