Technical Program Manager Security Cvd

Technical Program Manager, Security (Coordinated Vulnerability Disclosure)

When to Use

• Stand up or improve CVD / responsible disclosure policy and operating model
• Run intake triage queue (email, portal, bounty platform) with SLAs
• Coordinate researcher communication, extensions, and safe harbor questions
• Track remediation milestones across product and platform teams
• Manage embargo, coordinated disclosure date, and publication checklist
• Operate bug bounty scope, rewards, and platform workflows
• Produce program status, RAID, and steering updates for security leadership
• Plan advisory/CVE release with legal and communications

When NOT to Use

• Execute authorized exploitation or write PoCs → offensive-security-analyst
• Triage SOC alerts or tune detections → defensive-security-analyst
• Implement scanner gates, SBOM, pipeline fixes → devsecops
• Remediate findings in code (own the fix) → information-security-engineer, senior-software-engineer
• Enterprise security architecture or GRC strategy → cybersecurity, compliance-engineer
• Generic multi-team delivery (non-security) → technical-program-manager
• Customer contract security exhibits → commercial-counsel
• Public crisis comms narrative (non-advisory) → communication-lead

Related skills

Core Workflows

1. CVD program charter

Policy scope, channels, SLAs, roles, escalation.

See `references/program_charter_cvd.md`.

2. Intake and triage

Receive report, dedupe, severity, assign DRI, researcher ack.

See `references/intake_triage.md`.

3. Remediation and validation tracking

Fix milestones, retest, waiver/exception path.

See `references/remediation_tracking.md`.

4. Coordinated disclosure timeline

Embargo, extensions, publication date, multi-party coordination.

See `references/disclosure_timeline.md`.

5. Advisory and publication

CVE, advisory draft, legal/comms gates, customer notification.

See `references/advisory_publication.md`.

6. Bug bounty operations

Scope, rewards, platform hygiene, researcher relations.

See `references/bug_bounty_operations.md`.

Outputs

Prefer structured artifacts:

• Intake record — reporter, asset, severity, status, DRI, dates
• Disclosure tracker — embargo end, parties, blockers, go/no-go
• Weekly program status — inflow, SLA breaches, aging criticals, upcoming publications
• RAID — risks (premature leak, incomplete fix), actions, decisions (severity disputes)
• Publication checklist — signed advisory, CVE, comms, support/KB, bounty payout

Principles

• Coordinated disclosure by default — align publication with fix readiness unless active exploitation forces earlier notice
• Single intake DRI — one queue owner; engineering DRIs per product/component
• Document researcher comms — timestamps, promises, extension rationale
• No legal advice — route safe harbor, bounty terms, and advisory language to qualified counsel
• Separate incident response — active exploitation in production may parallel IR (incident-management-engineer) while CVD track continues

Advisory and publication

Table of contents

1. Publication checklist 2. Advisory content 3. CVE coordination 4. Customer and support

Publication checklist

Gate before public release:

• [ ] Fix validated in production (or supported releases listed)
• [ ] Security advisory draft — technical accuracy reviewed by engineering
• [ ] Legal approval — wording, liability, credit
• [ ] Comms approval — blog, social, press hold release if needed
• [ ] CVE ID reserved or published per CNA process
• [ ] Support / KB article for customer-facing impact
• [ ] Bounty reward processed (if applicable)
• [ ] Reporter notified before public post (embargo lift)
• [ ] Internal distribution — sales, CS, exec briefing if customer impact

Go/no-go — CVD DRI + security lead + legal; comms for external-facing.

Advisory content

Typical sections (counsel may edit):

Avoid: exploit recipes, unnecessary attack detail, customer-identifying data.

CVE coordination

Track CVE state in disclosure tracker (reserved → published).

Customer and support

• Severity to customers may differ from internal severity (communicate impact, not CVSS alone)
• Prepare FAQ for support: symptoms, detection, upgrade steps
• Notification — email, in-app, status page per policy and contracts
• Log customer comms sent time relative to advisory URL live

For regulated or contractual disclosure windows, legal owns interpretation — TPM tracks deadlines.

Bug bounty operations

Table of contents

1. Program setup 2. Scope management 3. Reward workflow 4. Platform hygiene 5. Researcher relations

Program setup

Align bounty with CVD policy:

Launch checklist: legal review of terms, security review of scope, comms for announcement, support briefed on bounty vs support tickets.

Scope management

• Update scope when new products launch or domains retire
• Mark out-of-scope clearly (third-party, physical, social engineering unless allowed)
• Rate limits and DoS — prohibit destructive testing in rules
• Sync scope with attack surface owners quarterly

Reward workflow

1. Triage validates finding (same bar as non-bounty CVD) 2. Severity set → reward tier from matrix 3. Mediation — platform dispute process; TPM documents decision 4. Payout — finance/tax forms per platform; timing in SLA

Do not promise reward in triage before validation. Duplicates — split or deny per policy.

Platform hygiene

• Close stale submissions with reason
• Tag components for reporting analytics
• Export metrics: submissions, valid, payout, mean time to bounty
• Rotate program admins; least privilege on platform

Researcher relations

• Thank-you for valid reports; professional tone on declines
• Hall of fame — opt-in credit on advisory
• Repeat researchers — consistent DRIs; avoid re-triage by new analysts each time
• Conferences — coordinate swag or invites with comms/legal

Escalate harassment, threats, or extortion to security leadership and legal immediately — outside normal bounty flow.

Coordinated disclosure timeline

Table of contents

1. Default timeline 2. Embargo management 3. Extensions 4. Early disclosure triggers 5. Multi-party coordination

Default timeline

1. Agreement — reporter accepts coordinated disclosure (implicit via policy or explicit) 2. Fix window — engineering delivers validated fix 3. Embargo end — publication date (often 0–14 days after fix deploy) 4. Publication — advisory, CVE, comms, bounty payout

Record all dates in disclosure tracker visible to legal and comms.

Embargo management

Embargo means: no public details until agreed date.

Pre-release builds — restrict access; no public issue titles with exploit strings.

Extensions

Request extension when:

• Fix complexity underestimated
• Holiday / release freeze
• Retest failed; additional work needed

Communicate to reporter:

• New target date
• Brief reason (not internal blame)
• What changed since last update

Document extension approval (TPM + security lead; legal if near prior public commitment).

Early disclosure triggers

May accelerate publication without full fix when:

• Active exploitation in the wild
• Leak or partial public disclosure
• Regulatory or customer notification duty (coordinate with legal)

Run parallel incident response track; CVD TPM syncs advisory timing with IR comms.

Multi-party coordination

When issue spans vendors or open source:

• Identify CVE assignment owner (CNA vs upstream)
• Align credit lines and advisory wording
• Single coordinated release time (UTC); use shared calendar invite
• Avoid staggered leaks between parties

TPM owns calendar and checklist — not technical content of upstream patches.

Intake and triage

Table of contents

1. Intake channels 2. Triage workflow 3. Severity assignment 4. Researcher communication

Intake channels

• Dedicated email — alias with ticketing integration
• Web form / portal — structured fields (asset, steps, impact)
• Bug bounty platform — HackerOne, Bugcrowd, Intigriti, etc.
• Internal — red team, employees via internal channel (separate queue if needed)

Log every report with: received time, channel, reporter identity (if known), duplicate-of link.

Triage workflow

1. Ack — auto-reply with ticket ID and policy link; human ack within SLA for critical 2. Dedupe — same root cause, same component; merge tickets 3. Reproduce — security engineering or delegated product team; document result 4. Severity — apply rubric; record CVSS vector if used 5. Assign DRI — engineering owner for fix; TPM tracks dates 6. Disclosure track — open embargo record if external reporter

Out of scope — respond with policy pointer; do not debate at length.

Spam / noise — close with template; no bounty.

Severity assignment

Balance technical severity and exploitability in context:

Disputes: security lead decides; document decision in ticket.

Researcher communication

Templates should cover:

• Acknowledgment and expected next steps
• Request for clarification or retest steps
• Severity notification (without promising bounty amount in email)
• Extension request for disclosure date (rationale, new date)
• Fix deployed — invite retest
• Publication notice and credit line (if offered)
• Closure — duplicate, not applicable, or resolved

Do not share customer data, internal URLs, or other researchers’ reports.

CVD program charter

Table of contents

1. Charter sections 2. Roles 3. SLA targets

Charter sections

Roles

SLA targets

Example starting points (tune to policy):

Document business days vs calendar and holiday coverage for ack SLA.

Remediation tracking

Table of contents

1. Work breakdown 2. Milestones 3. Exceptions 4. Validation

Work breakdown

Per finding, track:

Use same RAID patterns as technical-program-manager — risks: slip on embargo, incomplete backport, missing test env.

Milestones

Typical sequence:

1. Confirmed — reproducible, in scope 2. Fix in progress — PR or patch branch 3. Fix in staging — ready for security retest 4. Fix in production — or shipped release train 5. Validated — security sign-off on retest 6. Ready to disclose — publication checklist started

Flag critical path items blocking coordinated date (e.g., mobile app store review).

Exceptions

Validation

Before closing remediation:

• [ ] Original PoC no longer works in target environment
• [ ] Regression test or automated check where applicable
• [ ] No scope creep (adjacent issues filed separately)
• [ ] Bounty severity finalized if applicable

Validation owner: security engineering — TPM confirms checklist complete.