02 Service
Closed-source software taken apart to find the flaws in what actually shipped, for the teams that build and buy them.
01 Overview
This work asks what is wrong with the software itself, whether that is a product you release or one you are about to depend on.
Research is open-ended, so it is bought as a block of time against a defined target. Two weeks is the smallest block that produces anything worth reporting on a non-trivial target, and we will say so if a target needs more than you want to spend.
02 Engagements
Vendors and manufacturers tend to start with the first three.
Compiled software, components, protocols
Taking apart what shipped: executables, libraries and the protocols they speak. Useful when there is no source to review, when the source and the binary have diverged, or when the question is what a component actually does.
Finding what nobody has reported
Structured hunting for previously unknown flaws in a target: fuzzing, static and dynamic analysis, and manual review of the code paths that handle untrusted input. This is open-ended work, so it is scoped by time.
Establishing real impact
We build a working proof of concept to establish whether an issue is genuinely exploitable and what it grants, which is what separates a finding a vendor fixes from one they defer. Written for your environment and handed over with the report.
The code you did not write
Verifying that the software bill of materials (SBOM) matches what is actually linked into the build, and assessing the components that carry real risk. Most modern products are largely third-party code, and the manifest is not always an accurate description of it.
Handling reports, and making them
Two directions. If you receive vulnerability reports, we help you triage, reproduce, and respond without the process becoming adversarial. If we find something in someone else's product, we handle disclosure to the vendor under an agreed timeline and coordinate the teams.
03 Process
Closer to research than to testing, so the shape differs from our other services.
We agree the target, the depth, and what constitutes success. Product work differs from a penetration test here: research is open-ended, so it is bought as a block of time against a defined target.
Written authorization from whoever owns the target and, where the target is a third party product, confirmation that you are entitled to have it tested.
Static and dynamic analysis, instrumentation, fuzzing where the target suits it, and manual review of anything reachable by untrusted input. Progress is reported as it happens, because research does not run to a predictable curve.
Anything found is proven. We establish exploitability and impact before reporting it.
Technical detail sufficient for your engineers to reproduce and fix, plus a summary for whoever decides whether it is released. If a CVE is appropriate, we handle the request.
If the finding is in a third party product, we manage the vendor conversation under an agreed timeline and keep you informed. Nothing is disclosed without your agreement.
04 Deliverable
Everything below ships with the engagement, whether or not the result is a finding.
05 Questions
A penetration test asks whether a system as deployed can be compromised, and works to a defined scope. Product security asks what is wrong with the software itself, usually without source, and is open-ended.
That is a real outcome. Research buys a defined depth of examination over a defined period. The report documents what was examined and how, which is itself evidence.
Yes, and it is a common reason to engage us. We assess the security posture of what you are about to depend on, the controls it actually implements, and whether that meets your organization's requirements.
You do. Findings, proof of concept code, and any tooling written during the engagement are yours, delivered with the report. We publish nothing without your written agreement.
Yes. Setting up a vulnerability disclosure policy, a security.txt, and a triage process is usually cheaper than handling the first unsolicited report badly, and it changes how researchers and bug bounty hunters approach you.
06 Contact
TowerVector will assist you in taking your security strategy to the next level. Please feel free to contact us: