secnull
systems nominal feed · live 14:23 UTC
8
audits
0
open cve
the projectcharter
vstatic-export · last revised apr 22 · 08:14 utc
— the project · §00

We read the code so you don't have to trust it by accident.

secnull is a small collective of practitioners publishing plainspoken security reviews of the open-source software that decides who you are, what you can access, and whose servers your secrets touch. We write for the engineer on call at 2 a.m., not the procurement committee.


— charter · §01 to §05
ratified 2024 · revised quarterly
  1. §01

    We name names.

    A review without a verdict is a press release. If a library is not safe to use, we say which library and why. If a maintainer has gone quiet on a known issue, we say who and when. Receipts in hand, always.

  2. §02

    We publish method before verdict.

    Every audit ships with its test corpus, its scoring rubric, and its reproduction steps. You should be able to rerun our work. You should be able to disagree with it on technical grounds, not vibes.

  3. §03

    We do not take sponsorships on verdicts.

    Members fund the publication. Foundations fund the infrastructure. Nobody funds a grade. We publish our books on the first business day of every quarter.

  4. §04

    We revise when the code revises.

    Grades are not immortal. When a maintainer fixes a finding, we retest and re-grade — and we archive the prior verdict so the historical record stands.

  5. §05

    Every audit is cryptographically signed.

    Our server refuses to serve an article whose SHA-256 does not match the Ed25519 signature in our integrity manifest. Read the code or the receipts — either way, the trust stack is visible, not asserted.


— §06 · methodology

How a grade is made.

We score every audit against six axes. Each axis returns a letter grade. The final grade is the floor of the axes, with caps applied for severity — one high finding caps the total at C; two caps at D; a silent regression of a security behaviour is an automatic F on its axis.

01
Auth correctness
Does the flow implement the spec the way the spec was meant to be implemented? We measure against a 148-assertion compliance corpus.
02
Crypto correctness
Primitives, parameters, and the absence of bespoke schemes. When in doubt, we read the mailing-list archives.
03
Supply-chain hygiene
Signing, provenance, dependency sprawl, maintainer turnover. The soft targets are structural.
04
Documentation
What does the README tell a tired engineer to do? Does the example code embody the threat model, or contradict it?
05
Maintainer response
When we send findings, how fast do they reply — and with what? A thoughtful "no" is worth more than a fast patch.
06
Default-safe ergonomics
The most important axis. The defaults you ship are the threat model 95% of your users will ever meet.

— §07 · who

The people doing the reading.

Six staff reviewers with collective decades in identity, cryptography, and site reliability. A rotating bench of volunteer auditors. A single editor who has the final veto on verdicts she believes are unfair.

Security is not a product. It is a relationship between authors, maintainers, packagers, and the engineers who trust them by accident every morning.
— charter, §02 · the secnull collective, 2024
— §09 · contact

Findings & corrections

If you believe an audit is wrong, tell us. Send a minimal reproduction, a suggested revision, and your name.

corrections@secnull.com

Coordinated disclosure

If you're a maintainer and we've sent you a draft, reply to the thread. The 10-day window begins on your receipt, not our send. Urgent? Use the PGP key in security.txt.

disclose@secnull.com · pgp

Join the bench

We onboard two volunteer auditors per quarter. Bring a writing sample, a package you've read, and a scar.

bench@secnull.com