The flaws nobody has published yet.
Original research into the software and hardware you depend on: the bugs no scanner will ever flag, found by people who know where to look. Faster now that the models do the reading. Still a person’s call.
The models read. The researcher decides.
AI has changed the pace of this work. A model reads a codebase, a firmware image or a protocol specification in minutes, triages crash dumps, drafts harnesses and proposes where to look.
What it does not do is decide what matters, chain three unremarkable weaknesses into one path that works, judge whether a finding is real in your deployment, or write the exploit that proves it.
Our researchers use the models for the reading and keep the judgement. You see which was which.
- Reads the codebase, the firmware, the spec
- Triages the crash dumps
- Drafts the harnesses
- Proposes where to look
- Decides what matters
- Chains three weaknesses into one path
- Judges whether it is real in your deployment
- Writes the exploit that proves it
The software and hardware you depend on.
Third-party software
The products your business depends on and nobody else has looked at.
Your own products, before release
What the Cyber Resilience Act now expects of a manufacturer.
Firmware and embedded devices
The code on the board, and the ways in the datasheet never mentions.
Protocols and file formats
The parsers and handshakes everything else trusts.
Mainframes and the systems scanners do not understand
If it computes, it is in scope.
Shipping a product into the EU? What the Cyber Resilience Act asks of a manufacturer →
Scoped from the question. Run as a sprint.
- 01
Scoped from the question: what would hurt most if it broke.
- 02
A time-boxed research sprint, sized to the question.
- 03
A check-in each week, with what the models surfaced and what the researcher made of it.
- 04
Coordinated disclosure handled with you when the flaw is in someone else’s product.
One senior researcher carries the question from the scoping call through to the debrief, and reads the models’ output with the same scepticism as a crash dump.
A rootkit, under their rootkit.
A security-product vendor asked us to break their own product. To see how it really worked, we wrote a rootkit that ran underneath the product’s own rootkit-like behavior. Those findings hardened it.
That rootkit became a capability of its own. On a later engagement, a locked-down secure zone with every control live, we used it to get beneath the controls, then went after everything else.
Findings with the proof attached.
The findings, with proof-of-concept exploits
Reproducible, so your own engineers can see it work.
Severity judged in your deployment
Not by CVSS. By what it would let an attacker do to you.
The fix or mitigation, tested
We confirm it closes the path, not only the symptom.
Disclosure handled
With the vendor, on a timeline you agree.
A debrief with the researchers who did the work
The people who found it, in the room, answering the hard questions.
What every engagement includes.
Not a tier you pay extra for. Every client gets it.
Help beyond the scope
A problem outside what you hired us for? If we can help, we will.
Seniors on call
Reach the people who did the work, any time, for as long as you need them.
From found to fixed
Fix guidance from the people who found it, and a free re-test within 90 days of the engagement to confirm it held.
What our seniors learn here is encoded into Incenter: every engagement makes the engine smarter.