Binary Analysis, Fuzzing & SBOM Assurance

What ships is a binary, not a repository. We analyse the artefact you actually deliver: reverse engineering, coverage-guided fuzzing, binary-recovered SBOM and VEX, and provenance a downstream verifier can check.

Duration

6–12 weeks

Team

2 named + RE lead

From

€58,000

Crash triage

48h median

How it runs

Artefact intake — firmware images, drivers, mobile SDKs or appliances; unpacking, architecture identification, secure-boot chain map.

Reverse engineering — Ghidra / IDA with in-house lifters; annotated attack-surface map of parsers, IPC, debug interfaces and trust boundaries.

Fuzzing — AFL++ / LibAFL harnesses, syzkaller for kernel components, firmware rehosting; crash triage to root cause, CWE and exploitability.

Assurance — SPDX 3.0 / CycloneDX 1.6 SBOM reconciled against the binary, VEX statements, SLSA L3 provenance and Sigstore attestation.

What you get

Attack-surface map of the shipped binary, not the source tree
Fuzzing harness corpus and crash register with root-cause triage
SBOM (SPDX 3.0 / CycloneDX 1.6) reconciled against what is actually linked
VEX statements for CRA and EO 14028 delivery obligations
Reproducible-build and provenance policy with verifier instructions

Methodology

SPDX 3.0 · CycloneDX 1.6
SLSA v1.0 · in-toto · Sigstore
EU Cyber Resilience Act
NIST SSDF (SP 800-218)

Typical scope

Firmware, kernel drivers, TEE / secure-element code, embedded and WASM runtimes, mobile SDKs, closed-source appliances, OSS dependency trees.

Not included

Source-code review as a substitute for binary analysis. Exploit development beyond proof of exploitability. Ongoing SBOM monitoring (available as a managed service).

Each is a separate engagement — they need separate authorisation.

A time-boxed assessment establishes what was found within the agreed scope and window. It does not certify the absence of vulnerabilities, and we will never say that it does.

securepeak.com

engagements@securepeak.com