on request
Security research. What we can show, and what we cannot yet.
We find the leaks. Some of what we found we may show, some we may not, and some will follow when the fix is out.
What we do
We read the pipelines and automation of software projects the way an attacker does: the files that run when someone opens an issue or a pull request, and the credentials those runs can reach. When we find a hole we report it privately to the maintainers, and we tell you what we found if you ask us to look at yours.
The public example
A published GitHub security advisory with severity High: prompt injection in an issue automation workflow could expose workflow credentials. Our account is credited as the reporter. The severity is the one in the published advisory, set by the project, and it has no CVE. It opens without a login.
The whole record
From our own records: we filed 81 reports so far. The receiver confirmed 5, from two known technology companies and three open-source projects, one of them the advisory above. For 2 more the receiver acknowledged the report or fixed it without answering us. The rest were rejected, were duplicates of earlier reports, were withdrawn by us because our analysis was wrong, have had no answer, or are still waiting. The names stay private.
These are our own records. They are not an outside audit of us.
Sealed dossiers (planned)
Reports under embargo cannot be shown. We plan to put each one on a public list with its date and a fingerprint, without its content. When the fix is out we publish the dossier, and anyone can recompute the fingerprint and see that we had it on that date. It is the same idea as our Signal log. It is not live yet.
Where it stops
Not a penetration test of your production systems and not a certificate. You get a written report, privately, with the evidence we have for each finding and what is still open.