Software security research, and the tools we build for it.
Each lit dot is in line of sight from the ringed point: their two offsets share no factor but 1.
From (0, 0), of dots are in sight, a share of ; the limit is 6/π², about 0.608.
What we do
Vulnerability research
Finding bugs in software we don't own; disclosing them responsibly.
Supply chain
Provenance and CI hardening, shown on our own releases.
Tooling
Open-source security libraries, released when ready.
Tools
go-avscanv0.3.0
Asks the machine’s antivirus about a folder of files: Windows AMSI, a clamd daemon, or a command you name.
go get github.com/Totative/go-avscango-keyringv0.3.0
One credential store for a Go desktop app: the OS keyring, with a sealed-file fallback inside a Flatpak.
go get github.com/Totative/go-keyringgo-codepairv0.2.0
Pair two devices on a LAN with a short human-typed code and an authenticated key exchange.
go get github.com/Totative/go-codepair
What you can check
- Releases are built in CI and carry signed provenance and an SBOM. Verify any of them with
gh attestation verify <file> --owner Totative. - Every commit and tag is signed.
- Public repositories run CodeQL and publish an OpenSSF Scorecard.
- Vulnerability reports come in privately; advisories and CVEs go out through GitHub, with credit to the reporter.
For example, go-avscan v0.3.0:
gh release download v0.3.0 --repo Totative/go-avscan --pattern '*.tar.gz'
gh attestation verify go-avscan-v0.3.0.tar.gz --owner Totative
Each release carries three files: the source tarball (go-avscan-v0.3.0.tar.gz), its provenance bundle (go-avscan-v0.3.0.tar.gz.intoto.jsonl) and the SBOM (sbom.spdx.json).
Latest write-ups
Checking a Totative release
What we sign, what each release carries, how the pipeline that builds it is locked down, and the commands that check it without taking our word for it.
Report a vulnerability
Use Report a vulnerability on the repository’s Security tab, not a public issue. Scope and what we commit to are in the security policy.