Application security · Bergen, Norway
I help engineering teams design secure APIs, manage software-supply-chain risk, implement practical DevSecOps controls, and build secure cloud applications using Rust, Python, React and Azure.
Where I work
I start with the assets, people and trust boundaries that matter. The useful output is not a perfect diagram; it is a short list of risks and decisions the team can act on.
STRIDE · attack paths · trust boundaries · security ADRs
Signing in and being allowed to perform an action are different problems. I design both, including tenant and resource-level checks that are easy to miss in APIs.
OAuth 2.0 · OIDC · Microsoft Entra ID · APIM · Zero Trust
I prefer a few clear requirements in a story and pipeline over a large policy nobody reads. OWASP ASVS gives those requirements a testable foundation.
OWASP ASVS · abuse cases · acceptance criteria · security gates
An SBOM is only useful when a finding can be connected to a deployed service, an owner and a decision. That connection is where I put most of the effort.
CycloneDX · Dependency-Track · provenance · CI/CD hardening
I pay particular attention to authorization, data access, file handling, error paths and the assumptions hidden between frontend and backend code.
Rust · Python/FastAPI · React/Next.js · PostgreSQL · MS SQL
My focus is the path an identity, request or secret takes through the system: who can reach it, what they can do and what evidence remains afterwards.
Azure · Key Vault · WAF · private endpoints · security telemetry
Coding agents make it cheaper to create code and easier to create risk at scale. I work on practical boundaries for tool access, data, review and auditability.
least privilege · tool isolation · audit trails · review policy
Verification
I use the OWASP Application Security Verification Standard to turn broad security goals into requirements a team can test. Some controls belong in CI; others need architecture review, code review or a deliberately awkward abuse test.
The OWASP Top 10 is useful for explaining common risks. ASVS is what I reach for when a team needs acceptance criteria and evidence that a control actually works.
Working method
Start with the system, its sensitive assets and the ways it could realistically fail or be abused.
Choose proportionate controls and write down ownership, trade-offs and the reasons behind them.
Combine ASVS requirements, automated checks and focused human testing. No single tool is enough.
Use findings and incidents to improve the shared patterns, not only the application where they appeared.
A practical perspective
My background spans hands-on software development, technical leadership and academic research. I am most useful when a security question crosses those boundaries: an Entra design that also has to work in an API, a dependency policy developers can live with, or an architecture decision that needs evidence rather than reassurance.
Have a difficult security decision?