SkarpChapter 7 of 8
Disclosure Policy for Machine-Scale Findings
Traditional disclosure clocks assume that findings arrive at a manageable rate. AI-generated backlogs force difficult choices about validation, maintainer capacity, public deadlines, patch availability, and the risk of giving adversaries a roadmap.
1. Reframe Disclosure for Machine-Scale Reporting
The machine-scale problem
AI-assisted testing can create suspected findings faster than teams can reproduce, patch, and communicate them. Disclosure therefore manages information flow, not only a calendar deadline.
Protect three groups
A workable policy balances users needing protection, maintainers needing actionable reports, and researchers needing predictable communication and fair escalation.
Do not confuse leads with vulnerabilities
A bulk automated backlog is not a validated vulnerability inventory. Start clocks after a report reaches a defined evidence threshold, not when a tool produces an alert.
2. Establish the Policy Baseline
CVD is the baseline
Coordinated vulnerability disclosure aligns reporters, maintainers, and affected parties so that public information is accurate and users have a practical route to protection.
Use the current standard
As of July 19, 2026, ISO/IEC 29147:2018 remains the current published disclosure standard. The 2014 edition was withdrawn and replaced by the 2018 edition.
Publish operational commitments
State scope, secure intake, safe harbor, response expectations, evidence requirements, escalation, and public-advisory rules. A policy must be backed by actual triage capacity.
3. Design a Submission-Pacing Gate
Scenario
An AI agent generates 1,200 suspected flaws in an open-source authentication library. Bulk-sending them to a volunteer maintainer would overwhelm triage and expose unverified attack ideas.
Pace submissions
Batch by root cause, deduplicate, validate with a human reviewer, send a small high-confidence tranche, then wait for acknowledgment before releasing more.
Make each report actionable
Include affected versions, exact reproduction, preconditions, security impact, and available mitigation. Keep related lower-confidence reports in a private, tracked inventory.
4. Activity: Triage the AI Backlog
Your turn: Choose the first submission batch
A scanner reports the following five leads against a healthcare scheduling platform:
- A probable reflected XSS finding, but the evidence is only a screenshot from an automated browser.
- A reproducible authorization bypass exposing appointment records, reachable from the public internet without login.
- Fifty reports of the same outdated JavaScript package in separate pages; exploitability is unknown.
- A reproducible remote code execution path in an internal development environment that is isolated from production.
- A possible injection issue in an unsupported product version that is still widely deployed by customers.
Task
Create a first batch of no more than three items. For each selected item, write:
- Its priority.
- What evidence must be included.
- Whether you would request an accelerated response.
- What you would hold back until validation or maintainer acknowledgment.
Suggested reasoning path
Start with confirmed, externally reachable, high-consequence issues. Then consider systemic exposure and unsupported-but-deployed products. Do not treat the number of duplicate alerts as proof of fifty independent vulnerabilities.
A strong answer should select item 2 immediately, investigate item 5 for customer exposure and compensating controls, consolidate item 3 into one dependency-level record, and require stronger proof for item 1.
5. Set Clocks That Reflect Evidence and Risk
A clock needs a start event
A 90-day window is a policy choice, not a universal law. Track receipt, acknowledgment, human validation, coordination target, and public disclosure as separate events.
Avoid automation-driven clocks
Starting the public clock at validated_at prevents raw AI output from forcing disclosure. Still acknowledge receipt quickly and state when validation will occur.
Use exceptions deliberately
Active exploitation, available mitigations, multi-vendor dependencies, safety risk, and invalid reports may change timing. Capacity alone must not create an endless embargo.
5.1 Knowledge Check: When Does the Clock Start?
Choose the policy design that best controls the risk of machine-scale false positives while treating reporters fairly.
An AI system submits 800 suspected issues. Which clock design is most defensible?
- Start a 90-day public-disclosure clock for every machine-generated alert at ingestion.
- Never commit to any response time because AI reports are difficult to validate.
- Acknowledge intake promptly, define a validation service target, and start the coordinated public-disclosure clock when a qualified reviewer validates a security-relevant issue.
- Start a public-disclosure clock only after a patch has been released.
Show Answer
Answer: C) Acknowledge intake promptly, define a validation service target, and start the coordinated public-disclosure clock when a qualified reviewer validates a security-relevant issue.
This design avoids treating unverified alerts as confirmed vulnerabilities while preserving accountability. It separates fast acknowledgment and validation expectations from the disclosure deadline. Waiting until after a patch is released removes useful urgency and can create indefinite delay.
6. Build an Escalation Matrix
Escalation is structured
Escalation does not automatically mean full public disclosure. It identifies who must act, what defenders need now, and which technical details should remain restricted temporarily.
High-risk triggers
Create explicit routes for active exploitation, systemic dependencies, unsupported but deployed products, unresponsive maintainers, and high-confidence issues without patches.
Use coordinators when needed
Multi-vendor and high-consequence cases may need a neutral coordinator. CERT/CC prioritizes systemic, safety, critical-infrastructure, and national-security cases.
7. Thought Exercise: Embargo or Limited Advisory?
Decide what to disclose under pressure
A validated flaw in a widely used open-source library enables remote denial of service. A proof of concept exists, but exploitation has not been observed. The upstream maintainer has a patch, yet dozens of downstream products will need time to integrate it.
Choose a posture
Option A: Full immediate disclosure
- Maximum transparency.
- May give attackers a reliable roadmap before downstream users can patch.
Option B: Indefinite embargo
- Protects technical details temporarily.
- Leaves users unaware and can become an excuse for inaction.
Option C: Time-bounded coordinated disclosure with a limited early advisory
- Notify affected downstream parties privately.
- Publish defensive guidance, affected-version ranges, and mitigation steps when useful.
- Withhold exploit-enabling details until the coordinated date or until active exploitation changes the risk.
Task
Select an option and define:
- The embargo end date or review milestone.
- The minimum information downstream maintainers receive.
- The information users receive before full technical publication.
- The event that would trigger earlier public escalation.
For this scenario, Option C is often the most defensible because it creates user protection without allowing the embargo to become open-ended. Document the rationale and reassess whenever exploitation evidence changes.
8. Flashcards: Essential Terms
Flip each card, then explain how the term changes when findings arrive at machine scale.
- Coordinated vulnerability disclosure
- A process that aligns reporters, maintainers, affected parties, remediation, and public communication to reduce exploitation risk.
- Human validation
- A qualified review confirming reproducibility, affected scope, preconditions, and security impact before a suspected finding is treated as a vulnerability.
- Submission pacing
- Deliberately limiting and sequencing reports so maintainers can triage high-value findings without being overwhelmed by duplicates or low-confidence leads.
- Embargo
- A time-bounded restriction on public technical details while affected parties coordinate remediation, mitigation, or notifications.
- Systemic dependency
- A shared component whose vulnerability can affect many downstream products, requiring upstream and downstream coordination.
- Limited advisory
- A public communication that gives defenders actionable mitigation or exposure information while withholding unnecessarily exploit-enabling details.
9. Scenario Quiz: The Right Escalation
Apply the escalation matrix to a realistic machine-scale reporting case.
A researcher submits 300 AI-generated reports. After review, one is reproducible, remotely exploitable, and affects an unsupported product still used by hospitals. The vendor says it has no engineering capacity. What is the best next step?
- Keep all details private indefinitely because the product is unsupported.
- Publish all 300 reports immediately to pressure the vendor.
- Escalate the validated issue through a coordinator or relevant response channel, assess active exploitation and compensating controls, provide time-bounded mitigation-focused communication, and keep the other 299 reports private pending validation.
- Close the report because unsupported products are outside normal patch commitments.
Show Answer
Answer: C) Escalate the validated issue through a coordinator or relevant response channel, assess active exploitation and compensating controls, provide time-bounded mitigation-focused communication, and keep the other 299 reports private pending validation.
The validated issue has high potential consequence because it affects healthcare environments and an unsupported but deployed product. A coordinator, compensating controls, and a time-bounded mitigation-focused advisory address real risk. The unvalidated bulk reports should not be publicly released.
10. Implement the Policy: A 30-Day Playbook
Week 1 and 2: Make intake operable
Publish scope, safe harbor, a secure contact, and evidence requirements. Label automated reports, group them by root cause, and use clear workflow states with human owners.
Week 3: Pre-decide hard cases
Set a default coordinated timeline after validation and document exceptions for exploitation, safety, systemic dependencies, unsupported products, and unavailable maintainers.
Week 4: Measure the system
Tabletop-test a high-consequence scenario. Measure acknowledgment, validation, duplicate rate, root-cause consolidation, owner assignment, and customer-ready guidance.
Key Terms
- Embargo
- A temporary, time-bounded restriction on public vulnerability details to allow coordination and protective action.
- Root cause
- The underlying defect or design issue that produces one or more observed vulnerability reports.
- Safe harbor
- Policy language stating that an organization will not pursue legal action against good-faith, in-scope security research that follows the policy.
- Disclosure clock
- The defined time period and start event used to target public disclosure of a validated vulnerability.
- Human validation
- Expert review that confirms a report is reproducible, security-relevant, and sufficiently evidenced.
- Limited advisory
- A public notice that gives defenders actionable protective information while limiting details that could unnecessarily enable exploitation.
- Submission pacing
- The controlled sequencing and batching of reports to match maintainer capacity and reduce duplicate or low-quality reporting.
- Systemic dependency
- A shared upstream component whose vulnerability can affect many downstream products or services.
- Unsupported product
- A product or version that is outside the vendor's stated maintenance or security-update period but may remain deployed.
- Coordinated vulnerability disclosure (CVD)
- A structured process for validating, remediating, and communicating vulnerability information among reporters, maintainers, affected parties, and users.