Coordinated disclosure OS

VAPT incident workflow, AI triage, and publication readiness.

Build the CNA-grade operating system where AI reduces noise, operators own incident management, researchers stay protected, vendors coordinate in dedicated spaces, and the entire lifecycle stays traceable from intake to publication.

Role model

Every account type has a precise remit.

Researchers submit, operators coordinate, vendors respond only when invited, and pentest firms/security companies share a single role class.

Individual researcher

Researcher

Submits reports, tracks status, uploads new evidence, receives notifications, and remains shielded until public attribution is approved.

Submissions include title, scope, vendor/product, evidence, attachments, CVSS/CWE/MITRE data, PoC, and attribution details.
Sees statuses: Submitted → Awaiting Review → Case Assigned (plus case number once created).
Communicates with operators only inside the researcher thread and can respond with attachments or answers.

Collaborative discovery

Team

Acts like a researcher but represents a collective, allowing multiple internal contributors while still attributing discoverers.

Appears as a single reporting entity while still supporting per-discoverer credit splits.
Shares the researcher dashboard, uploads, timeline, and notifications with solo researchers.
Receives case-assigned notices, linked case numbers, and publication-ready attribution flags.

Security organization

Security Company / Pentest Firm

Both account types share one class: they submit disclosures for engagements and still attach named discoverers.

Uses the same AI triage, timeline, notification, and chat experience as other researchers.
Registers named researchers or teams for credit splits and optional public attribution.
Operates inside the same status model and sees the VAPT-{YEAR}-{NUMBER} case once a case is created.

Incident command

Operator

VAPT incident manager/service-desk role that owns AI triage, case creation, vendor onboarding, and disclosure coordination.

Reviews AI-optimized cards with spam/duplicate/CNA risk scores, vendor inferences, and missing info checklists.
Rejects, requests info, assigns, reassigns, or creates cases with auto-generated VAPT-{YEAR}-{NUMBER} identifiers.
Manages researcher and vendor conversations, status transitions, notifications, and publication timelines.

Disclosure partner

Vendor

Invited by operators, vendor accounts get dedicated incident views and chat threads without researcher exposure.

Registers after invitation, views shared summaries/remediation notes, and updates patch status.
Communicates only in vendor threads with operators, never directly with researchers.
Receives notifications for updates, remediation confirmations, and publication milestones.

Object model

Records that keep disclosures accountable.

The model captures reports, cases, CVEs, conversations, notifications, and attribution so every decision is traceable.

Report

Every submission becomes a Report record even if AI rejects it instantly.

Captures submitter (researcher/team/security company), vendor/product, evidence, CVSS/CWE/MITRE data, PoC, attachments, and metadata.
AI triage runs first to filter spam, ads, duplicates (reports, cases, CVEs, published records), and infer vendor/CNA status.
Researcher-facing statuses remain simple: Submitted, Awaiting Review, Rejected, Case Assigned.

Case

Operator-created canonical disclosure record with auto-numbered VAPT-{YEAR}-{NUMBER}.

Links reports, researchers, discoverers, CVEs, vendor communication, and credit allocations.
Supports multiple researchers/discoverers, optional lead researcher flag, credit split configuration, and optional public attribution.
Includes case statuses: UNASSIGNED, OPEN, CLOSED and internal states mapping to the researcher view.

CVE

Cases can attach zero or more CVEs and feed into CVE Services when ready.

Operators can reserve IDs, attach CVSS/CWE/MITRE metadata, and stage publication without exposing secret credentials.
Serves as the bridge to server-side CVE Services flows, validation rules, and public advisory publishing.

Conversation

Separate conversation objects isolate researcher and vendor chats with optional fresh sessions.

Researcher thread: researcher/team/security company + operator(s) for intake, clarification, evidence, and attribution updates.
Vendor thread: vendor + operator(s) for disclosure coordination, remediation, patch confirmation, and publication prep.
Operators can spawn ad hoc sessions per side when new legal/remediation topics emerge.

Notification

Event records highlight every major workflow transition per actor.

Researcher alerts include report receipt, rejection, awaiting review, case creation/number, status changes, operator replies, and publication/closure.
Operator alerts focus on new AI-approved reports, assignments, vendor registrations, researcher/vendor replies, and updated intelligence scores.
Vendor alerts cover invitations, account creation, operator messages, case updates, remediation confirmations, and publication milestones.

Credit & attribution

Internal records maintain discoverer data, enable credit splits, and expose public attribution only when approved.

Supports multiple discoverers, credit split ratios, and lead researcher flags that can be kept private until disclosure.
Public attribution is toggled at publication while internal metadata preserves the real discoverer list.

Report intake pipeline

Submit → AI triage → operator review → case creation.

AI triage comes first, reducing spam and duplicates while readying data for operators.

Step 1 — Report submission

Researchers, teams, or security companies file new reports with structured metadata (vendor, product, scope, evidence, PoC, CVSS/CWE/MITRE data, attachments, contact information).

Every submission creates a Report record before any triage decisions occur.
AI normalization ensures consistent language, translation, and metadata extraction.

Step 2 — AI initial triage

AI runs language normalization, translation, spam/ad detection, duplicate checks (reports, cases, CVEs, published VAPT records), and infers vendor/CNA status.

Produces operator-facing summary, duplicate/spam risk scores, missing-information checklist, and next-action recommendation.
Outputs either Immediate Reject (status=Rejected, reason logged, researcher notified) or Awaiting Review (operator queue entry).

Step 3 — Operator review

Operators evaluate AI summaries, review evidence, check vendor/CNA intelligence, and decide: reject, request more info, reassign, or create a case.

Actions include reject/discard, leave unassigned, assign to self/others, or promote to case creation.
Operators also manage attachments, vendor invitations, and timeline entries during review.

Step 4 — Case creation & coordination

Promoted reports become Cases with auto-generated VAPT-{YEAR}-{NUMBER}, assigned operator, researchers, CVEs, and attached vendors.

Case status turns OPEN, researcher receives notifications with case number and timeline update.
Operators coordinate researcher and vendor threads, schedule vendor onboarding, and track validation/patch milestones.

Immediate Reject

AI can instantly reject a report while keeping the Report record visible; status becomes Rejected and researchers can review the reason.

Awaiting Review

AI-approved submissions enter the operator queue with risk scoring, duplicate intelligence, CNA hints, and summary notes.

Status model

Simple public statuses backed by rich operator states.

Researchers only see Submitted, Awaiting Review, Rejected, Case Assigned, plus the public case states (UNASSIGNED, OPEN, CLOSED).

Researcher-facing

Submitted
Awaiting Review
Rejected
Case Assigned

Case states

UNASSIGNED
OPEN
CLOSED

Internal/operator

AI Rejected
Pending Manual Review
Awaiting Reporter Response
Awaiting Vendor Onboarding
Awaiting Vendor Response
In Validation
Patch Confirmed
Ready for Publication
Blocked
Closed

Case creation flow

Every accepted report becomes VAPT-{YEAR}-{NUMBER}.

Cases link reports, researchers, CVEs, vendors, notifications, and credit allocations.

Case automation

Operators click “Create Case,” the system issues VAPT-{YEAR}-{NUMBER}, assigns operators, and notifies researchers with the case number and OPEN status.

Multiparty coordination

Cases support multiple researchers/discoverers, CVEs, credit splits, and optional public attribution toggles.

Notifications

Status transitions trigger researcher, operator, and vendor alerts while keeping the audit trail intact.

Operator console

Incident Management System / service desk.

The workspace contains triage, assigned work, unassigned pools, vendor onboarding, big chat center, AI insights, and action menus.

Triage queue: AI flags, submitter type, vendor mapping, priority, duplicate hints, CNA intelligence, and aging metrics.
Assigned work, unassigned pool, and vendor onboarding queue (pending invites, new registrations, confirmations).
Conversation center: researcher and vendor threads separated plus quick actions to open new sessions.
Status management controls: Set In Review, Blocked, Resolved, Reject, Delete/Discard, Invite Vendor, with confirmation/reason modals for destructive actions.
Service-desk table (report ID, submitter, subject, priority, status, action menu) that exposes Send Message, Assign, Create Case, Invite Vendor, and status overrides.
AI decision-support card surfaces duplicate risk, spam risk, likely CVEs/CNAs, recommended next action, missing info checklist, and evidence notes.

Segregated communication

Researcher and vendor threads never mix.

Operators are the only bridge between researchers and vendors; conversations remain separate and auditable.

Researcher thread

Researchers/teams/security companies + operator(s): intake clarifications, evidence exchanges, reproduction discussion, and attribution/timeline updates.

Vendor thread

Vendors + operator(s): disclosure coordination, remediation plans, patch confirmations, rollout scheduling, and publication readiness.

Ad hoc sessions

Operators can spawn new sessions per side for fresh topics, legal separation, or sensitive remediation threads.

Researcher side

My Reports + chat + timeline + notifications.

`/my-reports` is the researcher portal with case summaries, statuses, linked case IDs, timelines, chat, and uploads.

Per-report view shows summary, researcher-visible status, linked case number, timeline, and comment composer.
Uploads, additional evidence, and operator question responses live inside this experience.
Notifications and unread markers keep researchers aware of replies, requests, and publication steps.

Researcher routes: /my-reports, /my-reports/:reportId, /my-reports/:reportId/chat, /cases/:caseId, /hacktivity/:caseId.

Vendor experience

Invitation, onboarding, and remediation coordination.

Vendors receive invitations, register, and interact through vendor-only dashboards and conversations.

Vendor overviews display involved cases/reports, statuses, product scope, remediation notes, and timeline entries shared by operators.
Vendor conversations remain isolated from researchers and expose only operator-approved materials.
Notifications cover invitations, account creation, operator messages, remediation confirmations, and publication milestones.

Vendor routes: /vendor/profile, /vendor/reports, /vendor/reports/:reportId, /vendor/conversations/:conversationId.

Notifications

Event feeds for every actor.

Researcher alerts

Report received
Report rejected by AI or operator
Report moved to Awaiting Review
Case created and number assigned
Case status changed
Operator replied or requested more information
Publication or closure event

Operator alerts

New AI-approved report in triage
Report assigned to you
Vendor registered
Researcher replied
Vendor replied
Duplicate or CNA intelligence recalculated

Vendor alerts

Invitation received
Vendor account created
Operator message
Case update shared
Remediation confirmation requested
Publication milestone approaching

Routes & APIs

All access points with public timeline.

Operator routes, researcher routes, vendor routes, and a public `/hacktivity/:caseId` timeline keep navigation structured.

Researcher

/my-reports, /my-reports/:reportId, /my-reports/:reportId/chat, /cases/:caseId, /hacktivity/:caseId

Operator

/operator/triage, /operator/reports, /operator/reports/:reportId, /operator/cases/:caseId, /operator/vendors/invites, /operator/conversations/researcher/:conversationId, /operator/conversations/vendor/:conversationId

Vendor

/vendor/profile, /vendor/reports, /vendor/reports/:reportId, /vendor/conversations/:conversationId

AI + CNA readiness

Quality control, duplicates, and CVE Services.

AI detects duplicate submissions across reports, cases, CVEs, and published VAPT records.
Spam/ad detection and invalid submission filtering keep operator time safe.
CVE Services integration stays server-side with CVE-ready case metadata.
Public `/hacktivity/:caseId` timelines show submission, AI triage, vendor onboarding, patch confirmation, and disclosure milestones.

Product truths

Codex must not miss these facts.

Security companies and pentest firms use the same role type.
Every submission becomes a Report record with AI triage before operator review.
AI detects spam, ads, duplicates, known CVEs, and vendor CNA status, and can immediately reject while preserving the report.
AI-approved reports move into operator queues; operators can reject, assign, reassign, or create cases.
Case creation auto-generates VAPT-{YEAR}-{NUMBER}, researchers see the number, and status OPEN is visible.
Researcher/operator and vendor/operator conversations remain segregated.
Researchers never chat directly with vendors inside VAPT.
Operators invite vendors, receive registration notifications, and vendors get dedicated overviews/conversations.
Operators can spawn new conversation/ticket sessions for either side when needed.
Notifications capture major transitions for researchers, operators, and vendors.