Vendors deserve a fair window to ship a fix. Customers deserve accurate severity assessment. Researchers deserve credit. Defenders deserve early notification when their environment is at risk. Coordinated 90-day disclosure is the policy that balances all four. Here is how the Sherlock Forensics Labs team actually runs that pipeline from first finding to published advisory.
Why this matters as a sales point
A digital forensics firm that runs original offensive research is unusual. A firm that runs that research with cowboy discipline is a liability. The distinction between "we found a zero-day" and "we found a zero-day and handled it like adults" is the distinction that lets enterprise buyers, insurers, courts and vendor security teams take Sherlock Forensics seriously.
This article walks the policy. Use it as a reference when a procurement team asks whether your DFIR partner does original security research and how they handle it.
The 5-step pipeline
Every Sherlock Forensics Labs disclosure follows the same five-step pipeline. The codenames change. The vendors change. The process does not.
- Authorized own-host research only. Every finding is reproduced on infrastructure the Sherlock Forensics lab owns and controls. No client environment, no production system, no third-party network is ever involved in vulnerability research. The same lab that runs DFIR engagements for clients runs its research on an isolated bench. Those two surfaces never touch.
- Reproducible confirmation. A finding is not a finding until it can be triggered reliably on a freshly-installed target. The lab maintains a clean reference environment per vendor product, walks the reproduction from scratch then proceeds. Half the time what looks like a vulnerability on first read turns into a misconfiguration the user introduced. The reproducible confirmation step kills those false positives before any vendor gets pinged.
- Conservative impact assessment. The lab characterizes findings at the most defensible level, not the most dramatic. PARTY LINE on the Labs page is currently scoped as missing authorization with potential service availability impact and stored configuration exposure. The full privilege impact remains under measured assessment because we will not publish a SYSTEM-level claim until we have walked every code path that could rule it out.
- Vendor notification with full technical detail. The vendor receives a complete report. Reproduction steps. Affected versions. Class identification. Suggested remediation direction. The lab uses the vendor's PSIRT or HackerOne coordinator where one exists and direct security contact where one does not. The clock starts at vendor receipt.
- Public placeholder during the window. The Sherlock Forensics Labs page publishes the codename plus advisory ID plus vendor plus product plus impact class plus status. No exploitation detail. No reproduction steps. No specific vulnerable-function names. The public artifact is enough for defenders to track active research without arming attackers.
The 90-day window
The lab's default disclosure window is 90 days from vendor notification. This matches industry-standard practice across major coordinated disclosure programs. Within that 90 days:
The vendor is expected to acknowledge receipt within reasonable time (usually 14 days). To investigate and confirm or dispute the finding. To plan a fix or document why no fix is required. To ship the fix or coordinate a release timeline with the lab if more time is genuinely needed.
The lab is expected to remain in communication. To answer technical questions. To provide reproduction guidance. To accept reasonable extensions when the vendor is making demonstrable progress. To hold the public release of full technical detail until either the vendor ships a fix or the 90-day window expires, whichever is first.
Extensions are real but not automatic. The lab grants an extension when the vendor shows a credible release plan with a concrete date. The lab declines an extension when the request is "we need more time" without specifics. The discipline keeps the window meaningful.
Why we do not weaponize
Sherlock Forensics will not publish a weaponized proof-of-concept during an active disclosure window. The reasons are practical and ethical.
Practical: a weaponized PoC during the window hands attackers a working exploit before defenders have a patch. The asymmetric advantage goes to whoever shows up first. Historically that is not the patching teams. The lab's research surfaces are valuable as advance notice, not as the loaded gun.
Ethical: the lab does the research because we want the surface improved. We do not want our research to be the reason a school district, a hospital network or a small business goes down to ransomware. The 90-day window with no PoC publish is the discipline that keeps the work aligned with the mission.
After the window closes, the lab publishes full technical detail. By then the vendor has had fair time to ship a fix. Customers who patch quickly are protected. Customers who do not patch carry the responsibility for that decision. The asymmetric advantage shifts back to defenders.
Early-release for incident response teams under NDA
Coordinated disclosure does not mean defenders are blind during the window. The lab maintains a vendor-acknowledged early-release channel for incident response teams and forensic examiners who need to know what is hunting their fleet.
The mechanism is simple. IR teams under NDA can request pre-release notification at labs@sherlockforensics.com. The lab provides technical detail sufficient for defenders to detect, mitigate or contain in their own environment, under terms that prevent public re-disclosure during the window. Vendors are notified of the early-release program as part of the coordination so there are no surprises.
This channel covers the case where a defender's environment is actively being attacked using a class the lab knows about. The vendor still owns the patch timeline. The defender gets actionable detail to protect their own assets without having to wait.
What this looks like in the current sprint
The four findings currently active on the Sherlock Forensics Labs page are running through this pipeline in real time:
BIG BROTHER (Brother Windows software, SYSTEM-level LPE). Reported to Brother PSIRT 2026-06-12. Currently awaiting vendor acknowledgement. 90-day expiry 2026-09-10.
BLANK CHECK (Intuit QuickBooks Desktop, SYSTEM-level LPE). Reported to Intuit via HackerOne 2026-06-12. Awaiting vendor acknowledgement. 90-day expiry 2026-09-10.
SILENT NIGHT (Intuit QuickBooks Desktop, second distinct SYSTEM-level LPE). Reported to Intuit via HackerOne 2026-06-13. Awaiting vendor acknowledgement. 90-day expiry 2026-09-11.
PARTY LINE (Brother iPrint&Scan for Windows, missing authorization). Discovered by the Sherlock EoP Auditor. Vendor report in preparation as of writing. The lab will not publish the EoP Auditor binary as a public download while PARTY LINE is in its disclosure window because the tool reproduces the finding. The product page is live in Coming Soon state with an early-access notification list.
How the disclosure pipeline ties into the Sherlock Forensics tool program
The lab does not run vulnerability research as an isolated activity. The research feeds directly into the Sherlock Forensics product line. The Sherlock EoP Auditor exists because the lab spent years finding the same three classes of Windows local privilege escalation by hand. The tool productizes that workflow. The classes the tool checks are the classes the lab discloses against on the Labs page. Research and product reinforce each other on a quarterly cadence.
Other tools in the Sherlock Forensics catalog follow the same pattern. The Sherlock PST Viewer and Sherlock NSF Viewer exist because corporate email forensics requires reading proprietary container formats without vendor clients. The Sherlock Disk Imager exists because forensic acquisition needs chain of custody discipline that consumer disk tools do not provide. Each tool was a working internal workflow before it shipped as a product. The disclosure pipeline operates on the same principle: process the lab actually runs, then publish the process.
For the Sherlock Forensics services practice, the integration is even tighter. When an incident responder is reading an active breach timeline and recognizes a third-party privileged Windows service interaction pattern, the question "is this a Sherlock Forensics Labs known class" gets asked first. The Sherlock Universal Events Viewer surfaces the relevant event log entries. The disclosure pipeline data tells the examiner whether the class is known and what the vendor coordination status is. The tool and the disclosure tracker work together.
Court-defensible rigor
The same rigor that runs the disclosure pipeline runs the Sherlock Forensics digital forensics practice. The chain-of-custody discipline that makes a forensic report admissible is the same discipline that makes a coordinated disclosure credible. The reproducibility that wins in court is the reproducibility that earns vendor trust.
For DFIR engagements, this matters because the lab's vulnerability research builds the expertise that reads incident timelines. When local privilege escalation shows up in a breach (it almost always does), the examiner who recognized the class in research recognizes it faster in casework.
For vendor security teams reading this
If you have received a Sherlock Forensics Labs advisory or are about to, here is the short version of what you can expect from us and what we expect from you.
From us: Full technical detail at notification. Reproduction guidance. Class identification and remediation direction. Reasonable communication cadence. Willingness to grant extensions for vendors making demonstrable progress. Pre-coordinated public release timing. Credit attribution that respects your team's contribution to the fix.
From you: Acknowledgement within reasonable time. Honest engagement on the technical detail. Communication when timelines slip. Coordinated public release planning. Customer notification once the patch ships. The willingness to issue a CVE through your assigned coordinator where applicable.
For vendor coordinator inquiries, contact labs@sherlockforensics.com.
Frequently asked questions about Sherlock Forensics Labs disclosure
How many disclosures does the lab handle simultaneously? The current sprint has four active disclosures (BIG BROTHER, BLANK CHECK, SILENT NIGHT and PARTY LINE) running in parallel. The lab maintains capacity for additional disclosures when research finds them.
What happens if a vendor disputes the finding? The lab engages in good faith on the technical detail. Most disputes resolve once the reproduction is walked through together. Genuine disputes (the lab is wrong about reproducibility or impact) result in a withdrawal or scope correction. Bad-faith disputes (the vendor wishes the finding away without engaging technically) get the standard 90-day window applied without extension.
Can the lab assign CVE numbers? The lab works through the vendor's assigned CVE coordinator (HackerOne for many vendors, CISA for vendors without a program, MITRE direct in some cases). Sherlock Forensics does not unilaterally assign CVEs. The advisory ID (SF-LABS-YYYY-NN) is the lab's internal tracking identifier and stays separate from the eventual CVE.
For IR teams reading this
If you are running an incident response practice and want pre-release notification on findings the lab has open, the NDA early-release channel is open at labs@sherlockforensics.com. The lab provides technical detail sufficient for defensive action under terms that align with the active disclosure window.
For Sherlock Forensics DFIR engagements directly (incident response retainer, breach investigation, court-defensible forensics), talk to our team.
Coordinated disclosure is how a vulnerability research practice earns the right to be taken seriously. Track active Sherlock Forensics Labs disclosures or request the NDA early-release channel for your IR practice.