// for engineering and AppSec
The defects in your own code, found before anyone else finds them.
Your own C and C++, analysed while you are still building it. Your engineers get a defect with the exact input that triggers it, so the proof that it is real arrives with the report. Found here it costs a ticket. Found after you ship it costs a release.
Where this fits beside what you already do
Each of these answers a different question, and this one answers the question the others leave open.
- Your dependency scanner reports known issues in code other people wrote. This reports what is in the code your own team wrote, where a published advisory will never exist.
- A penetration test examines the product you already shipped. This examines the build before it becomes that product, while the branch is still open.
- A bug bounty pays a stranger for what they found after release. This finds it first, and the finding stays between you and us.
Anything we find is new by construction: it lives in code that you wrote and that nobody outside your team has analysed. That is the defect an attacker is looking for, because it is the one with no patch and no advisory.
What this changes for you
The same defect costs three different amounts depending on when you meet it.
- Fewer defects reach production, because they are found while the code is still being written and a fix is a normal ticket.
- Fewer emergency releases. An unplanned release costs engineering time, customer trust and the roadmap behind it.
- Attackers spend their budget elsewhere. Hardening raises what an attack on your product costs, and attention moves to softer targets.
- Your team stays on scale. Time spent on incidents is time taken from the product you are trying to grow.
What you receive
A defect your engineers can act on the same day, rather than a list to triage.
- A confirmed defect, with the input that triggers it. Your engineers re-run it themselves, fix it, and re-run it again to see it gone.
- The file, the line and the variable. Where the defect lives, so the fix starts in the right place.
- What it would let an attacker do, stated plainly, so you can rank it against everything else on the board.
- Candidates we have yet to confirm, kept in their own list, so a maybe arrives as a maybe.
The defects we look for
The classes that cause most of the memory-safety incidents in shipped C and C++.
- Memory safety. Writing or reading past the end of a buffer, and using memory after it has been handed back.
- Untrusted input reaching a dangerous operation, traced from where the data arrives to where it does damage.
- Size arithmetic that wraps, leaving an allocation smaller than the thing about to be written into it.
How it runs with your team
Our engineers do the work and bring your engineers the result.
You give us
A build of your product, and someone on your side who knows it. Scoped and quoted up front, from what the code is, what worries you, and when the answer has to exist.
We hand back
Confirmed defects with their inputs, worked through with your engineers until each one is understood and closed. The reproduction stays yours, so the fix is verified rather than argued.
Then it repeats
The value compounds per release: each round starts from a codebase the last round already hardened, and the classes your team learns to avoid stop arriving.
A run that surfaces nothing is a statement about that run. Deciding whether an arbitrary program has a vulnerability is undecidable, so every analyser has a reach, ours included, and we tell you where ours ended.
We publish no precision or recall figure, and will decline to quote one on request. It would describe one version of the product against one body of code, and reading it as a property of your codebase would be wrong.
This is delivered as an engagement today. Our engineers run it and work it through with yours. If you want it standing in your own pipeline instead, that is work we would scope with you.