The tools that ship into customer environments — and the ones that ship to everyone.
Most of the tooling Yinkozi engineers build is customer-specific and stays inside the customer's environment. A subset graduates to open source, where it can serve the wider community without exposing engagement detail. This page is the categories of work — published artefacts are added as customer disclosure permits.
Five categories of internal tooling.
Built per engagement, kept by the customer, occasionally released. The internal toolchain stays internal — we are not in the business of competing with our customers' security tooling.
Custom static analyzers
Semgrep / CodeQL rule packs tuned to languages, frameworks, and idioms commercial scanners do not cover. Built per engagement; published when customer-cleared and useful upstream.
Fuzzing harnesses
Coverage-guided harnesses for proprietary parsers, custom protocols, and vendor-specific runtimes. Often the artefact a customer keeps after we leave.
Runtime instrumentation
Frida modules, Burp extensions, and EBPF probes for application behaviour observation. Deployed inside engagements where the off-the-shelf tooling does not have the right resolution.
Industrial-protocol parsers
Modbus, DNP3, IEC 61850, OPC UA dissectors and fuzzers for OT engagements where vendor-specific extensions break commercial parsers. Extensions developed alongside refinery and grid customers.
Cryptographic test vectors
Test vectors and reference implementations for protocols we have reviewed — particularly threshold-signature schemes, custom MPC protocols, and verifier-side cryptographic checks.
Most of the tooling stays with the customer.
Tooling we build for a tier-1 bank is tuned to that bank's languages, frameworks, deployment topology, and threat profile. Releasing it without abstraction work would either leak engagement detail or produce a tool that is useful to nobody else. Both are wrong.
What we release is the abstracted core — the rule pack without the customer's identifiers, the protocol parser without the proprietary extension, the fuzzing harness without the embedded credential set. That abstraction is engineering work. It happens when we have time and when the upstream community would benefit.
For specific tools or analyzers built during a published advisory or CVE, we will release them alongside the disclosure. For long-lived patterns we have built repeatedly, we will release them when the abstraction is correct.
We are not in a publishing race with other security firms. The tools that exist do real work for real customers. The publication is a side-effect.
Looking for a specific tool or contribution?
Email us with the project or CVE identifier and we will route to the originating engineer.
email