Research / Advisories

Security advisories.

A security advisory is our public record of a vulnerability we found in someone else’s software, published after the vendor has had the chance to fix it. This page is where they will appear. There are none yet.

Published so far

Advisories 0

Nothing to show, and nothing hidden. We are a new firm, and an advisory needs a vendor who has been told, a fix or an agreed date, and a review. When the first one passes those steps it is listed here and counted in the reading room.

How we disclose

Find
In software we run ourselves: our own lab, open-source projects installed locally, products we are licensed to test. Findings from a client engagement belong to the client and never become advisories.
Confirm
We reproduce the issue, write down its preconditions and rate it with CVSS v4.0 before anyone outside hears of it.
Tell the vendor first
Privately, through the channel the vendor publishes: a security.txt contact, a security page or a bug bounty programme. Nothing is public at this point.
Agree a date
We work to the vendor’s fix, and agree when the advisory goes out. If a vendor does not respond, we try other channels before we consider publishing.
Publish
Once the fix ships or the agreed date passes, the advisory goes up here in the format below, with the vendor’s acknowledgment where they give one.

Reporting a vulnerability in this site or in our own tooling works the other way round, and our disclosure policy covers it, with the contact in security.txt.

What an advisory contains

Every advisory uses the same fields in the same order, so a reader, a scanner and a patch team can each find what they need. The sheet below is the format, not an advisory.

Format / Advisory v1

Id: SCOTOMA-YYYY-NNN, numbered per year in order of publication, for example SCOTOMA-2026-001.
Title: The weakness and the product, in one line, in plain words.
Affected: Product, component and the exact versions affected, and the first fixed version.
Severity: A CVSS v4.0 vector and score, with the reasoning behind each metric that is not obvious.
CVE: The CVE id once one is assigned, or a note that none was requested and why.
Summary: What is wrong and who is exposed, readable by someone who has never seen the code.
Impact: What an attacker could do, under which preconditions, described at the level of structure.
Fix: The version or the configuration change that closes it, and any interim workaround.
Timeline: Found, reported, acknowledged, fixed and published, each with an ISO date.
Vendor: The vendor’s acknowledgment, in their words where they agree to be quoted.
Credit: Who found it, and anyone who helped.

Fig. 1 / The advisory format. Fields only; no advisory has been published.

How to follow along

There is no feed and no mailing list yet, because there is nothing to send. The counter on this page and in the reading room is the record: when it reads 0, there is no advisory anywhere. A feed arrives with the first advisory, not before.

If you are a vendor and we have contacted you, the thread we opened is the place to reach us. If you think an advisory of ours is wrong, tell us through the same channel as a vulnerability report; corrections are published on the advisory itself, with the date.