GASP: AICF

Search controls

Search by control ID, name or domain

APP-014 Vulnerability Disclosure Programme

Tier 2+

Description

A publicly accessible vulnerability disclosure programme (VDP) or responsible disclosure policy exists. The policy defines how external researchers and customers can report security vulnerabilities, the expected response timeline, and the triage and remediation process. Reported vulnerabilities are acknowledged, triaged, and tracked to closure.

Rationale

External researchers discover vulnerabilities in products. Without a clear disclosure channel, reports go to public forums or are abandoned, leaving vulnerabilities unaddressed. A VDP turns external discovery into a security asset.

Framework Mappings (3)

TVM-01Threat and Vulnerability Management Policy and Proceduresinformative
8.29Security testing in development and acceptanceinformative
SI-5Security Alerts, Advisories, and Directivespartial

Evidence (2)

policymanual

Publicly accessible vulnerability disclosure policy (VDP) or responsible disclosure programme defining the submission channel, scope, expected response timelines, and safe-harbour statement.

Example: Public-facing VDP page at a known URL (e.g. https://example.com/security or a security.txt file at /.well-known/security.txt) or HackerOne/Bugcrowd programme policy page, containing: submission contact or form, scope definition, response SLA (e.g. acknowledgement within 5 business days), and a safe-harbour / legal protection statement for good-faith researchers.

Test: Navigate to the organisation's publicly accessible VDP page or security.txt file. Verify: (1) a submission channel (email, form, or bug bounty platform) is clearly listed, (2) a scope statement defines what systems are in-scope, (3) response timeline commitments are stated, (4) a safe-harbour clause protects good-faith researchers from legal action, (5) the page is reachable without authentication.

recordmanual

VDP intake and tracking records showing that externally reported vulnerabilities were acknowledged, triaged, and resolved within the defined response timelines.

Example: Jira, HackerOne, or Bugcrowd report tracker export showing all vulnerability disclosures received in the last 12 months, each with: submission date, acknowledgement date, severity rating, assigned owner, resolution date, and closure status.

Test: Request the vulnerability disclosure intake log for the last 12 months. Verify: (1) every reported vulnerability has an acknowledgement record within the SLA defined in the VDP (commonly ≤ 5 business days), (2) valid reports were triaged and assigned to an owner, (3) critical/high findings were resolved within the policy-defined remediation SLA, (4) reporters were notified of the outcome — check for a communication record per report.

Questions (2)

boolean

Does your organisation have a publicly accessible vulnerability disclosure programme (VDP) or responsible disclosure policy that defines how external researchers can report security vulnerabilities?

The VDP must be publicly reachable without authentication, include a defined submission channel, scope statement, response timeline commitment, and a safe-harbour clause protecting good-faith researchers.

select

How is your vulnerability disclosure programme operated?

Managed bug bounty programme on a dedicated platform (e.g. HackerOne, Bugcrowd) with defined scope and rewardsPublic VDP page with a defined submission channel and response SLA, but no financial rewardssecurity.txt file referencing an email address, without a formal programme pageAd hoc — no formal VDP; reports are handled informally if they arriveNo vulnerability disclosure mechanism in place

A formal VDP page with a defined SLA is the minimum. A managed bug bounty programme with scope, triage, and tracking provides stronger coverage. The absence of any disclosure channel leaves reported vulnerabilities without a clear path to resolution.