Skip to content
Edictum Labs, home
Discipline 01

Vulnerability
research

Sustained, curiosity-driven investigation into how software and systems actually break — from kernel memory handling to the boundaries that are supposed to keep workloads apart.

Discuss a research engagement
Focus
Systems · Memory · Isolation · AI
Standard
Reproduced & demonstrated
Based in
Prague
The work

Understand a system well enough to find what nobody was looking for.

Scanners find what they already know to look for. Research finds the rest.

Most security tooling operates on signatures and patterns — it recognises the known. The findings that matter most are the ones no catalogue describes: a subtle lifetime bug, an assumption that holds everywhere except one path, a boundary that is documented but never actually enforced.

That work takes time, depth, and a particular kind of curiosity. It is the core of what Edictum Labs does.

Domains

Where the implementation detail decides the outcome.

The areas where a boundary either holds or it doesn't, depending entirely on how the code was written.
  • Operating-system and kernel security
  • Memory corruption and memory safety
  • Virtualization and isolation boundaries
  • AI inference systems and native execution
  • Security architecture and trust boundaries
  • Implementation-level defect analysis
Approach

How the research is actually done.

01

Hypothesis first

We start from a specific, falsifiable question about how a system could fail — then design the work to disprove it. Breadth is cheap; a sharp question is what finds the deep bug.
02

Capability, not crash

A crash is a starting point. We reason about what a primitive actually grants — the read, the write, the control — and establish the precise conditions under which it holds.
03

Executed evidence

Every finding is reproduced with working proof. We do not report what might be exploitable; we demonstrate what is, and document exactly how far it goes.
04

Defect-class thinking

The instance is rarely the whole story. We trace a bug back to the assumption that produced it, so the fix can close the class rather than the single case.
What you receive

Findings written to be acted on.

Precise enough for the engineer who has to fix it, honest enough for the people carrying the risk.
  • Root-cause analysis of each finding
  • Reproducible proof-of-concept
  • Precise impact and exploitability assessment
  • Affected-surface and variant analysis
  • Concrete, engineer-ready remediation guidance
  • Coordinated-disclosure support where third parties are involved
Disclosure

Research is only responsible if it is handled responsibly.

We do not publish private or unpatched vulnerability details.

When research touches third-party software, we follow coordinated disclosure: the affected vendor is given a reasonable window to remediate before anything is made public. Verified advisories are published only after that process is complete.

See the coordinated disclosure policy for how we report and handle vulnerabilities.

Engagements

Have a system worth looking at closely?

Whether it is your own software or a dependency you rely on, tell us what you need understood. We will tell you honestly whether deep research is the right instrument.

Reply
Within two business days
Authorization
Written, before any testing
Based in
Prague, Czech Republic