Listing Reviewer

What you’ll do

When the scanner flags a release, you read the finding, the declared scope and the code behind both, and decide: it ships, it ships with the scope corrected, or it does not ship. No release has been flagged yet, so the first one and the first security report would both be yours.

• Review flagged releases: the diff, the manifest and the gap between them.
• Read tool descriptions closely — text written for a model, occasionally against the buyer’s interest.
• Write verdicts that go to the publisher unedited: specific enough to act on, short enough to read.
• Handle urgent security reports with whoever is on the rota.

What we’re looking for

• You can read Python and TypeScript well enough to follow where an argument goes; you need not write either.
• You are careful at a real pace, without skimming.
• You write clearly under mild time pressure.
• You say “I am not sure” and escalate — another reviewer is there for that.
• Not required: a security background, a degree or odd hours — a rota covers urgent reports.

What success looks like

Signs the role is going well.

1. Reviewing on your own

   Your verdicts agree with another reviewer’s at or above the team average.

2. A scanner rule with your name on it

   You have written up a finding that keeps recurring, and it has become a scanner rule, so it stops reaching reviewers.

3. A category you own

   The reviewer everyone asks about database servers, or about anything that touches a credential.

Hiring process

Every conversation is scheduled inside your working hours.

1. 01

   Intro call

   With the publisher operations lead: how you read and when you escalate.

2. 02

   Review session

   Real cases; you write the verdicts a publisher would get. A paid session.

3. 03

   The team

   Reviewers from the team; expect them to disagree with a verdict on purpose.

4. 04

   Close

   Back with the lead: the offer, and your questions about the role.

Written feedback either way · a decision after the final conversation.