Skip to content
NamadaSecurity operations

Where we work

The programmes our clients already run on, what we actually do on each one, and how platform reputation really works. No ranks, no tiers, no borrowed logos — the relationship and the work, described plainly.

Bring us a programme

The programmes your reports already flow through

These are the programmes most of our clients are already running on, which means we have read the reports their triage queue is drowning in — and written a few of them.

  • HackerOneWeb, API and mobile programmesReport triage, duplicate adjudication, and programme design for teams standing up a VDP.
  • HackenProofWeb3 VDPs and audit contestsContest review and post-contest remediation verification for EVM protocol launches.
  • ImmunefiSmart contract bounties, EVM and SVMSeverity adjudication against the Immunefi classification, and impact-statement review.
  • BugcrowdCloud and enterprise estatesTriage automation for programmes carrying a large backlog of low-signal submissions.
  • IntigritiEuropean VDP and pentest programmesScope definition and rules-of-engagement drafting under GDPR-bound disclosure terms.
  • Code4renaCompetitive Solidity reviewFindings calibration — converting contest-style submissions into sponsor-ready reports.

We have not reproduced any platform’s logo here — a borrowed trademark on a marketing page is a claim we have no right to make. Report history, payout records and reviewer feedback are available on request before you sign anything, including the ones closed as duplicates, which is the number most auditors will not show you.

What a platform relationship is, and is not

An account is not a credential, and a logo strip is not a partnership. This is the honest version of where we sit.

An account on a bounty platform is not a credential, and a logo strip is not a partnership. We work on the programmes our clients are already running, and the useful part is not the account — it is that we have read the reports those programmes generate, in volume, from both directions.

A triage queue is where evidence waits. The same class of finding arrives six times under six different titles, a valid report sits behind forty low-signal ones, and the engineer who could fix it is reading duplicates instead. That is the queue we know, because we have submitted into it and triaged what comes out of it.

So the relationship is a working one. We do not display a platform logo, we do not describe a partnership nobody signed, and we do not restate a rank from memory onto a marketing page.

In practice

  • If you already run a programme, we work inside it under your rules and your severity definitions.
  • If you have not stood one up, we draft the scope, the severity taxonomy and the response targets before it goes public.
  • If your queue is the problem, triage is the engagement — the platforms are only where the reports arrive.

How platform reputation actually works

A reputation total is a record of accepted reports. It is worth understanding what it does and does not tell you before you weigh one in a buying decision.

It counts accepted work, not skill

Platforms publish a reputation or points total derived from reports a programme has accepted as valid and unique, weighted by severity. The formula is public on each platform and differs between them. It is a running count of accepted work — not a measure of how hard any single finding was.

Severity is negotiated, not declared

A researcher can report a finding as critical; the programme triages it, and the record shows the severity the programme accepted. Disagreement is a normal part of the process, and how the argument is made — with the reproduction, not with the headline — is a better signal than the total.

It is per-platform and does not transfer

A standing built on one platform says nothing about standing on another, and nothing about a specific engagement. The work is judged by the finding in front of you, not by a number earned somewhere else.

A rank is not evidence

We do not put a rank, a tier or a badge on this page. Where a platform publishes a public profile, we will link it so you can read the actual record instead of a number we copied here. The number is the platform’s; the work is what you can check.

What we do with a report after it is accepted

Acceptance is the start of the work, not the end of it. Four stages run between a triaged report and a closed finding.

  1. Reproduction

    An accepted report is reproduced against a running target before anyone acts on it. Reproduction is what separates a finding from a plausible description, and it is what makes the remediation testable afterwards.

  2. Severity negotiation

    We derive the CVSS v3.1 vector from the mechanism rather than the headline, and argue the impact with the triage team using the reproduction as the evidence. Severities move in both directions, and we record the final one along with the reasoning.

  3. Disclosure timing

    We hold to the programme embargo, coordinate the fix window, and publish only after the fix is live. Where the reporter and the fixing team are different parties, disclosure waits on the fix, not on the calendar.

  4. Retest

    After the fix ships, the exact path that was reported is retested. The report closes against a running target, and the check that failed before the fix stays as a regression gate so the class cannot return quietly.

Tell us which programmes you run

If your triage queue is the bottleneck, that is the engagement. We will map it against what you already have before proposing anything.

Talk to securitySee the services