For product teams before a launch
Find the security gaps before your customers do
An application security review before launch looks at how your application and its data could be attacked: a threat model, a review of sign-in, access control, data handling and dependencies, and a fix list in priority order. We then work through the most serious fixes with your team.
01 How we work
How a review runs
-
A threat model first
We map the application's data, users, entry points and trust boundaries with your team, then rank the threats by what they would cost you if they happened.
-
Code and configuration, not only scans
Automated scanning finds known issues. We also read the sign-in, authorization and data-handling code paths, where logic flaws hide from scanners.
-
Fixes, not only findings
Each finding comes with a severity, the evidence and a concrete fix. We can make the fixes with your engineers and retest each one.
-
Your engineers in the room
Your developers join the threat model and the fixes, so they learn where the risks sit and can keep new code clear of them after the review.
What we'll tell you
A review lowers risk; it cannot prove there is none. We will not call an application secure, and your answers to a customer's questionnaire stay yours.
Review questions
Pick the questions a customer's security team will ask
Tick the questions you expect in the questionnaire. Each one shows the evidence a security reviewer looks for, and what we would build or change first.
Review questionnaire Tick the questions you expect
What to prepare
Tick a question to see the evidence a reviewer expects and what to build or change first.
-
Start here
How do users sign in, and how are sessions protected?
- Evidence
- A description of the sign-in flow, the multifactor options, session lifetime, and how tokens are stored and revoked.
- First
- Move sign-in to a proven identity provider or library, add multifactor for admins and shorten session lifetimes.
-
Start here
Can one customer ever see another customer's data?
- Evidence
- The tenant isolation design, and tests that try to read across tenants through the API and the user interface.
- First
- Enforce the tenant check in one shared layer for every query, then add automated cross-tenant tests to the build.
-
Start here
How is sensitive data protected at rest and in transit?
- Evidence
- A data inventory with classifications, the encryption in place, how keys are managed and who can reach each data store.
- First
- Classify the data first, encrypt sensitive fields, move secrets out of the code and narrow who can query production.
-
Start here
How do you find and fix vulnerable dependencies?
- Evidence
- Dependency scanning in the build pipeline, a record of findings and the policy for how fast each severity is fixed.
- First
- Add dependency and secret scanning to every build, and agree a fix policy by severity with a named owner.
-
Start here
Has the application been tested against common attacks?
- Evidence
- Results of a review covering injection, broken access control and other common web risks, with retests of the fixes.
- First
- Fix the highest-severity findings first, add a regression test for each one and retest it once fixed.
-
Start here
What do you log, and how would you detect an incident?
- Evidence
- A list of the security events that are logged, where the logs go, who reviews them and the response plan.
- First
- Log sign-ins, permission changes and data exports to one place, and write a short incident runbook the team can follow.
How it starts
-
Agree the scope
We agree which application, environments and data are in scope, the launch date, and the questionnaire or standard you are working toward.
-
Model the threats
A working session maps data flows, entry points and trust boundaries, and ranks the threats worth testing.
-
Review and test
We review the code, configuration and dependencies, and test the highest-ranked threats in a non-production environment.
-
Fix and retest
You get findings in priority order, each with a fix. We make or support the fixes, most serious first, and retest each one.
The usual engagement model: Fixed-scope implementation
Ready to talk it through?
Start a conversation02 A typical situation
What this usually looks like
A SaaS team might come to us shortly before signing its first large customer, holding a security questionnaire full of questions nobody on the team has answered before.
We would model the threats in the first days, review sign-in, tenant isolation and data handling, and fix the serious findings with the team. They would answer the questionnaire themselves, with evidence behind each answer.
03 Questions
Questions people ask
Not quite. A penetration test probes a running system from the outside. A review also reads the design and the code, so it finds logic flaws a test can miss. Many teams need both, and we will say which comes first.
Where your customers ask for them, the fixes and evidence can be aligned with SOC 2 control criteria or ISO/IEC 27001. An audit is a separate step that ends in an auditor's opinion.
This review covers the application and its data. If the questions are about cloud accounts, networks or infrastructure as code, we will say so early, because that is a separate piece of work.
No. We review the code and test in a staging or test environment that mirrors production. Any production access would follow your approval process and be logged.
04 Start
Bring the questionnaire you are worried about
Book a call with an engineer. We will look at your launch date and the questions you face, and suggest what to review first.
What happens next
- You pick a time, or send us a message.
- A person at Nexstella reads what you shared before we talk.
- You leave with a clear next step, even when that step is to wait.
Or write to [email protected]. Send a brief instead
Meet
Booking as .
Loading the calendar. If it does not appear, it opens on Cal.com too: open it in a new tab
Send us two or three times that suit you. A person replies within one business day. The invite goes to the address above.
Prefer that we send you times?
What happens next
- You pick a time, or send us a message.
- A person at Nexstella reads what you shared before we talk.
- You leave with a clear next step, even when that step is to wait.
Contact
Send us a message
Pick the topic that fits and tell us what you are working on. A person replies within one business day.
Want the full picture? Read Data governance, cybersecurity and responsible AI.
Also written for you: Responsible AI governance , Architecture review .
Last updated