About SIRENBOW

What we do

Our work runs on two tracks.

Published research. Vulnerability analysis and incident post-mortems written for defenders — how the flaw worked, how the attack ran, and what would have caught it. Every piece ships with the primary sources: contract addresses, transaction hashes, code references, so a reader can reproduce the analysis instead of taking our word for it.

Applied security work. Security review and hardening of production systems: authorization models (row-level security, database role privileges), authentication flows, content security policy and security headers, rate limiting and abuse controls, secret handling, and pre-launch review.

How we write

Every factual claim in our research carries one of three labels, and we hold that line even when it makes a story less dramatic:

• [verified] — we checked it ourselves against a primary source, and the appendix tells you how to check it too.
• [reported] — it comes from public reporting we did not independently confirm.
• [inferred] — it is our reading of the code or the evidence, not established fact.

Inference does not get promoted to fact because it reads better. When we are unsure, the text says so.

Scope and authorization

We test systems we own and operate, and systems we build and operate for clients under contract. We do not test third-party systems without written authorization. Research into public incidents is conducted against public data — on-chain records, published disclosures, and source code that is already open.

Disclosure

If you have found a security issue in something we run, or you want to reach us about a coordinated disclosure, write to security@sirenbow.com. Machine-readable contact details are at /.well-known/security.txt.

We read every report and we will tell you plainly whether we consider it valid, and why.