# Vulnerability Disclosure Policy: [Organisation name]

> Public coordinated vulnerability disclosure (CVD) policy: what security
> researchers may test, how we protect good-faith research (safe harbour),
> how to report, what we promise in return (acknowledgement, triage and
> remediation timelines), how we coordinate publication and embargoes, how
> CVE IDs are assigned and how we credit finders. The structure follows the
> topics covered by ISO/IEC 29147:2018 *Vulnerability disclosure* (receiving
> reports, coordination, publishing advisories, disclosure policy), and
> Appendix A gives a ready `security.txt` file in the format of RFC 9116
> (April 2022). Notes cover the EU Cyber Resilience Act, Regulation (EU)
> 2024/2847, Articles 13 and 14 and Annex I Part II. Replace every
> `[bracketed]` value and every row marked *Example*. Worked examples use
> Corvid Commerce, a fictional SaaS company. This is a documentation format,
> not legal advice: have counsel review the safe harbour wording before
> publication.

<!--
Guidance: How to use this template
- This is the public promise you make to people outside the organisation who
  find vulnerabilities. Write it in plain language, publish it at a stable URL
  (for example https://[domain]/security/disclosure-policy) and point to it from
  /.well-known/security.txt (Appendix A) and from SECURITY.md in each public
  repository (Security Policy, `dev/security-policy`).
- Keep internal mechanics out of the published text. Intake, verification,
  scoring, fix development and advisory production belong in the internal
  procedure (PSIRT Vulnerability Handling Procedure,
  `security/psirt-vulnerability-handling`). Enterprise scanning and patching of
  your own estate belongs in the Vulnerability Management Policy
  (`security/vulnerability-management-policy`). EU CRA reporting duties belong
  in CRA Vulnerability Handling (`security/cra-vulnerability-handling`).
- Sections 1 to 9 are the published policy. Sections 10 and 11 and the
  Document control block are internal: remove them, or keep them in an
  internal copy, before you publish.
- Only promise timelines you can meet with the current team on a holiday
  weekend. A missed promise damages researcher trust more than a modest one.
- Pitfall: a safe harbour clause that says "we will not pursue legal action"
  while the scope section is vague. Researchers rely on the scope to know
  whether the promise covers them.
-->

## Document control

<!-- Guidance: Internal block. Record who owns the published promise, who approved the legal wording and when it must be reviewed. Remove before publishing or keep only Version and Last updated in the public page footer. -->

| Field | Value |
|---|---|
| Document ID | [VDP-001] |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Published / Superseded] |
| Owner | [@psirt-lead] |
| Approvers / reviewers | [@ciso], [@general-counsel], [@head-of-engineering], [@communications-lead] |
| Last updated | YYYY-MM-DD |
| Classification | Public (sections 1 to 9 and Appendix A); Internal (sections 10 and 11) |
| Published URL | [https://www.corvid-commerce.example/security/disclosure-policy] *Example* |
| security.txt location | [https://www.corvid-commerce.example/.well-known/security.txt] *Example* |
| Reporting mailbox | [security@corvid-commerce.example] *Example* |
| Related internal procedure | PSIRT Vulnerability Handling Procedure (`security/psirt-vulnerability-handling`) |
| Next review | YYYY-MM-DD (at least annually, and after any change of scope, legal entity or regulation) |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Chief information security officer | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| General counsel (safe harbour wording) | [@name] | [Decision] | YYYY-MM-DD |
| Head of engineering | [@name] | [Decision] | YYYY-MM-DD |
| Communications lead | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Keep a public changelog of material changes (scope, timelines, safe harbour). Researchers testing under an older version need to know what changed and when. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved by CISO and general counsel; published with security.txt |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Mobile apps added to scope; CVE section updated after becoming a CNA |

## Contents

<!-- Guidance: Keep aligned with the headings. -->

1. [Introduction and our commitment](#1-introduction-and-our-commitment)
2. [Scope](#2-scope)
3. [Authorised testing and safe harbour](#3-authorised-testing-and-safe-harbour)
4. [How to report a vulnerability](#4-how-to-report-a-vulnerability)
5. [What happens after you report](#5-what-happens-after-you-report)
6. [Coordination, disclosure and embargo](#6-coordination-disclosure-and-embargo)
7. [CVE assignment and security advisories](#7-cve-assignment-and-security-advisories)
8. [Recognition and credit](#8-recognition-and-credit)
9. [Your data and confidentiality](#9-your-data-and-confidentiality)
10. [Internal: regulatory and standards alignment](#10-internal-regulatory-and-standards-alignment)
11. [Internal: governance, measurement and review](#11-internal-governance-measurement-and-review)
12. [Glossary and references](#12-glossary-and-references)
13. [Appendix A: Ready security.txt file](#appendix-a-ready-securitytxt-file)
14. [Standard and licence note](#standard-and-licence-note)

## 1. Introduction and our commitment

<!-- Guidance: Open with why you welcome reports and what you commit to. Two short paragraphs. Avoid marketing language; researchers read this to decide whether reporting to you is safe and worthwhile. -->

[Organisation name] (*Example:* Corvid Commerce Ltd, "Corvid Commerce", "we") builds and operates
[describe products and services, *Example:* a hosted commerce platform, its public APIs, two mobile
apps and an open source command-line tool]. We believe that people who find and report security
weaknesses in good faith make our customers safer, and we want reporting to us to be simple, safe
and worth the effort.

This policy explains which systems you may test, the rules for testing, how to send us a report,
what you can expect from us and how we coordinate public disclosure. If you follow this policy, we
will treat your research as authorised, work with you to understand and fix the issue, and credit
you if you wish.

We commit to the following:

1. Acknowledge every report within the time stated in section 5.
2. Keep you informed while we investigate and fix, at least at the intervals stated in section 5.
3. Fix confirmed vulnerabilities in line with their risk, and tell you when a fix is available.
4. Coordinate the timing and content of public disclosure with you.
5. Credit you publicly, unless you ask us not to.
6. Not take legal action against good-faith research that follows this policy (section 3).

This policy does not create a bug bounty. [If a bounty exists, state where its rules are published
and which document prevails when they differ.]

## 2. Scope

<!-- Guidance: List assets precisely: domains with wildcard rules, API hosts, app store identifiers, repositories and downloadable products with supported versions. Vague scope is the most common reason researchers test the wrong thing. List what is out of scope with equal precision. -->

### 2.1 In-scope assets

| ID | Asset | Type | Notes |
|---|---|---|---|
| SCOPE-001 *(Example)* | `*.corvid-commerce.example` | Web applications and APIs | Includes the merchant dashboard and checkout. Excludes hosts listed in 2.2 |
| SCOPE-002 *(Example)* | `api.corvid-commerce.example` | Public REST and GraphQL API | Use your own test account; rate limits apply (3.2) |
| SCOPE-003 *(Example)* | Corvid Shop for Android (`com.corvidcommerce.shop`) and iOS (App Store ID `[id]`) | Mobile apps | Latest store release and the one before it |
| SCOPE-004 *(Example)* | `github.com/corvid-commerce/corvid-cli` | Open source tool | Supported versions as listed in its SECURITY.md |
| SCOPE-005 *(Example)* | Corvid Edge Agent, versions 4.x and 5.x | Downloadable software | Self-hosted component installed by merchants |
| SCOPE-006 | [Asset] | [Type] | [Notes] |

You may also report vulnerabilities in assets not listed here that clearly belong to us. We will
review them, but the safe harbour in section 3 applies in full only to listed assets, and you should
not perform active testing against unlisted assets without asking us first.

### 2.2 Out-of-scope assets

| ID | Asset | Reason |
|---|---|---|
| OOS-001 *(Example)* | `status.corvid-commerce.example` | Hosted by a third-party status page provider; report to that provider |
| OOS-002 *(Example)* | Merchant storefronts on custom domains | Owned and operated by our customers |
| OOS-003 *(Example)* | Corporate email, office networks and employee devices | Not part of the product |
| OOS-004 | [Asset] | [Reason] |

### 2.3 Out-of-scope findings

We usually do not treat the following as vulnerabilities unless you can show a concrete security
impact. Please still report them if you believe the impact is real, and explain why.

| ID | Finding type |
|---|---|
| OOSF-001 *(Example)* | Missing security headers or cookie flags without a demonstrated attack |
| OOSF-002 *(Example)* | Reports produced only by automated scanners, without verification |
| OOSF-003 *(Example)* | Clickjacking on pages with no state-changing action |
| OOSF-004 *(Example)* | Login or logout cross-site request forgery |
| OOSF-005 *(Example)* | Email spoofing reports limited to the absence of a DMARC reject policy |
| OOSF-006 *(Example)* | Rate limiting on non-sensitive endpoints |
| OOSF-007 *(Example)* | Vulnerabilities in outdated browsers or rooted or jailbroken devices only |
| OOSF-008 *(Example)* | Publicly known vulnerabilities in third-party components with no demonstrated exploit path in our product, reported within [14] days of the upstream fix |
| OOSF-009 *(Example)* | Social engineering of staff, physical attacks and denial of service |

## 3. Authorised testing and safe harbour

<!-- Guidance: This is the section counsel must review. Keep the promise specific: what is authorised, under which conditions, and what you will do if a third party complains. Check local computer misuse and copyright anti-circumvention laws in each jurisdiction where you operate. Pitfall: promising immunity from third parties or authorities, which you cannot give. -->

### 3.1 What we authorise

When you research an in-scope asset (2.1) in good faith and follow the rules in 3.2, we consider
your activity authorised. Good faith means that your purpose is to find and report vulnerabilities
so that they can be fixed, that you avoid harm to our customers, our staff and our systems, and that
you do not use findings for any other purpose.

### 3.2 Rules of engagement

You must:

1. Test only against accounts you own or accounts you have the explicit permission of the account
   holder to use. Create test accounts with an email address that identifies you as a researcher,
   for example one that contains `+security-research`.
2. Stop as soon as you have enough evidence to demonstrate the issue. Do not pivot to other systems,
   escalate further, or keep access.
3. Not access, change, delete or keep data that does not belong to you. If you encounter personal
   data, payment data or credentials, stop, do not copy them, and tell us immediately.
4. Not degrade the service. Keep automated requests below [10] requests per second per host
   *Example*, and do not run denial of service, load or resource-exhaustion tests.
5. Not use social engineering, phishing or physical access.
6. Not install persistent code, backdoors or cryptocurrency miners.
7. Give us a reasonable time to fix the issue before any public disclosure (section 6).
8. Comply with the laws that apply to you.

### 3.3 Safe harbour

[*Example wording; counsel to review:*] If you make a good-faith effort to follow this policy, we
will:

1. Consider your research authorised for the purposes of the computer misuse laws that apply to us,
   and not bring or support legal action against you for it.
2. Not pursue claims against you for circumventing technical measures that we use to protect the
   in-scope assets, to the extent the circumvention was necessary for the research.
3. Waive restrictions in our terms of service and acceptable use policy that would otherwise
   prohibit the research, for the limited purpose of the research.
4. If a third party starts legal action against you for activity that followed this policy, make it
   known that your activity was authorised by us.

We cannot authorise testing of systems we do not own, and we cannot bind third parties, including
law enforcement. If you are unsure whether an activity is consistent with this policy, ask us at the
address in section 4 before you proceed.

Some vulnerabilities you find may be in software or services supplied to us by others. You may
report them to us and we will coordinate with the supplier (section 6.3). Testing a supplier's own
infrastructure is not covered by this safe harbour; follow that supplier's disclosure policy.

## 4. How to report a vulnerability

<!-- Guidance: Offer one primary channel that is monitored by a team, not a person. Publish an encryption option, but never make encryption mandatory: it filters out good reports. If you run a CNA or a bounty platform, say whether reports there are equivalent. -->

### 4.1 Reporting channels

| Channel | Address | Use |
|---|---|---|
| Web form (preferred) *(Example)* | https://www.corvid-commerce.example/security/report | Structured report, file upload, ticket reference returned at once |
| Email *(Example)* | security@corvid-commerce.example | Any report; encrypt with the key in 4.3 if you wish |
| Repository private reporting *(Example)* | "Report a vulnerability" in the `github.com/corvid-commerce/corvid-cli` repository | Vulnerabilities in the open source tool |
| Coordinator *(Example)* | A national CSIRT or a coordinator of your choice | If you prefer not to contact us directly |

Do not report vulnerabilities through public issue trackers, social media or customer support chat.
If you do not receive an acknowledgement within the time stated in section 5, please use another
channel listed above.

### 4.2 What to include

A good report lets us reproduce the issue quickly. Please include:

1. The affected asset (URL, API endpoint, app version, product version or commit).
2. The type of vulnerability, using a CWE identifier if you know it.
3. Step-by-step reproduction instructions, including any test account IDs you used, request and
   response samples, and screenshots or a short video.
4. The impact you believe an attacker could achieve, and any preconditions.
5. Your own severity estimate, if you have one, with the scoring system and vector you used.
6. Whether the issue is already public or known to others, and any date by which you plan to
   publish.
7. How you would like to be credited (name, handle, affiliation) or that you prefer to stay
   anonymous.

Partial reports are welcome. We will ask for more information if we need it.

### 4.3 Encryption and language

You may encrypt reports with our OpenPGP key, published at
[https://www.corvid-commerce.example/.well-known/security-pgp.asc] *Example* with fingerprint
`[fingerprint]`. The key and its expiry are also referenced from our security.txt file (Appendix A).
Encryption is optional.

We accept reports in [English] *Example*. Reports in other languages are welcome; we may take longer
to respond while we translate them.

## 5. What happens after you report

<!-- Guidance: Publish targets, not guarantees, and make them business days or calendar days explicitly. Take the values from the internal targets in the PSIRT procedure (`security/psirt-vulnerability-handling`, 7.4), which are the source of truth: each published value must be equal to or looser than the internal one. The *Example* values below match the Corvid Commerce PSIRT example and are common in practice; they are not normative in any standard. Quote the same values in SECURITY.md and the CRA procedure. -->

### 5.1 Response timeline

| Step | Our target | Notes |
|---|---|---|
| Automated receipt | Immediately *(Example)* | Ticket reference such as `CC-VDP-2026-0147` *(Example)* |
| Human acknowledgement | Within 2 business days *(Example)* | Named contact assigned |
| Initial assessment (valid, duplicate, out of scope) | Within 7 calendar days *(Example)* | We tell you our decision and reasoning |
| Status updates | At least every 14 calendar days *(Example)* | Until the fix is released |
| Remediation, critical severity | Fix or mitigation within 30 calendar days *(Example)* | Faster when actively exploited |
| Remediation, high severity | Within 60 calendar days *(Example)* | |
| Remediation, medium and low | Within 90 to 180 calendar days *(Example)* | May ship in a scheduled release |
| Disclosure | Coordinated with you (section 6) | Default: the earlier of 14 days after the fix and advisory, or 90 days after acknowledgement *(Example)* |

We assess severity using a published scoring system, currently [CVSS v4.0] *Example*, adjusted for
the context of our service. If we disagree with your severity estimate, we will explain why.

### 5.2 Report lifecycle

Every report follows the same path. You will hear from us at each step that changes the status of
your report.

```mermaid
flowchart LR
    A["Report received"] --> B["Acknowledged"]
    B --> C{"Valid and in scope?"}
    C -- "No" --> D["Closed with explanation"]
    C -- "Duplicate" --> E["Linked to original, finder told"]
    C -- "Yes" --> F["Triaged and scored"]
    F --> G["Fix developed and tested"]
    G --> H["Fix released"]
    H --> I["Advisory and CVE published"]
    I --> J["Finder credited, case closed"]
```

### 5.3 Outcomes you can expect

- **Accepted:** we confirm the vulnerability, share our severity rating and a target fix window, and
  keep you informed.
- **Duplicate:** we tell you that the issue was already known and, where possible, when it was first
  reported. Credit goes to the first reporter, unless your report adds material new impact.
- **Informative or not applicable:** we explain why the report does not describe a vulnerability or
  is out of scope.
- **Accepted risk:** in rare cases we may decide not to fix an issue. We will explain the reasoning
  and agree with you whether and how it may be published.

## 6. Coordination, disclosure and embargo

<!-- Guidance: State a default disclosure window and the reasons it may move. Coordinated disclosure is a negotiation: give researchers a predictable default and clear rules for extension and acceleration. Pitfall: asking for indefinite silence, which pushes researchers to publish without you. -->

### 6.1 Default disclosure window

We aim to publish an advisory when a fix is available. Unless we agree otherwise with you, we ask
that you wait until the earlier of:

1. [14] days *(Example)* after we release a fix and publish an advisory, so that customers running
   self-hosted products have time to update; or
2. [90] days *(Example)* after your report was acknowledged.

### 6.2 Extensions and early publication

- We may ask you for an extension when a fix is complex, requires coordination with several vendors,
  or would expose customers if published before most of them can update. We will explain the reason
  and propose a new date. Extensions are by agreement, not by default.
- We may publish earlier than agreed if the vulnerability is being actively exploited or becomes
  public through another route. We will tell you before we do, where possible.
- If you intend to publish before a fix is available, please give us at least [7] days' notice
  *(Example)* and share a draft so we can correct factual errors and prepare mitigation guidance for
  customers.

### 6.3 Multi-party coordination

When a vulnerability affects other vendors, open source projects or an upstream component, we will,
with your agreement:

1. Contact the affected parties, or a coordinator such as a national CSIRT, and share only what each
   party needs.
2. Propose a common embargo end date and publish at the agreed time.
3. Keep you informed of who has been told.

We follow the principles of the FIRST *Guidelines and Practices for Multi-Party Vulnerability
Coordination and Disclosure* where relevant.

### 6.4 Embargo rules

Information shared under embargo is confidential until the agreed date. We share embargoed details
only with people who need them to fix, test or prepare communications. If an embargo breaks (for
example the issue appears publicly), we will inform all parties and move to publication as soon as a
fix or mitigation guidance is ready.

If we cannot agree on severity, scope or timing, either party may ask a neutral coordinator, such as
[a national CSIRT or CERT/CC] *Example*, to help. We will not use disagreement as a reason to stop
communicating.

## 7. CVE assignment and security advisories

<!-- Guidance: State who assigns CVE IDs for your products. If you are a CVE Numbering Authority (CNA), say so and name your scope. If not, say which CNA you use. Hosted-only services may still receive CVE IDs under current CVE Program rules; decide your approach with the PSIRT. -->

### 7.1 CVE IDs

[*Example:*] Corvid Commerce is [a CVE Numbering Authority (CNA) for its own products / not a CNA
and requests CVE IDs from [the CNA of last resort or a named CNA]]. We request or assign a CVE ID
for every confirmed vulnerability in software that customers install or run (SCOPE-003 to SCOPE-005)
and, where the CVE Program rules permit and customer action or awareness is useful, for
vulnerabilities in our hosted service. We publish the CVE Record when we publish our advisory. You
may suggest a CVE description; we will consider it.

### 7.2 Security advisories

We publish advisories at [https://www.corvid-commerce.example/security/advisories] *Example* in
human-readable form and, for installable products, as machine-readable [CSAF 2.0] *Example*
documents. Each advisory states the affected and fixed versions, severity, a description, mitigation
steps, credit and references. For hosted-service issues that required no customer action, we may
publish a shorter notice. The format is described in the Security Advisory template
(`security/security-advisory`).

Where customers ask whether a vulnerability in a third-party component affects our products, we
publish exploitability statements (VEX) as described in our SBOM and VEX Policy
(`security/sbom-vex-policy`).

## 8. Recognition and credit

<!-- Guidance: Decide whether you pay rewards. If not, say so plainly and offer meaningful recognition. If you run a bounty, link to its rules and state which terms prevail. Hall of fame pages should credit by the finder's chosen name only. -->

We thank researchers who help us:

1. **Advisory credit:** we name you in the advisory and the CVE Record, in the form you choose,
   unless you ask to remain anonymous.
2. **Hall of fame:** we list researchers who reported valid issues during the year at
   [https://www.corvid-commerce.example/security/thanks] *Example*.
3. **Rewards:** [*Example:* We do not currently pay monetary rewards under this policy. / Rewards
   are paid through our bug bounty programme at URL, whose terms apply in addition to this policy.]
4. **Letters of appreciation:** on request, for researchers who want to show their contribution to
   an employer or institution.

We credit the first person who reports a given issue. If several people report the same issue
independently before we publish, we may credit all of them with their agreement.

## 9. Your data and confidentiality

<!-- Guidance: Say what personal data you collect from reporters, why, how long you keep it and who sees it. Reference your privacy notice. Researchers often report from personal addresses. -->

We use the contact details and report content you send us only to handle your report, to credit you
as you request and to meet legal duties. Report data is kept for [5] years *(Example)* after the
case closes, then deleted or anonymised, and is visible only to the product security team and people
who need it to fix the issue. Our privacy notice at [URL] explains your rights.

We will not share your identity with third parties (including affected vendors under section 6.3)
without your consent, except where the law requires us to. Please keep the details of your report
confidential until publication as described in section 6.

## 10. Internal: regulatory and standards alignment

<!-- Guidance: Internal section. Record which obligations this policy helps you meet and where the evidence lives. Remove from the public version. Check the consolidated text of each law; dates and article numbers below are as published in the Official Journal and may be amended. -->

### 10.1 EU Cyber Resilience Act (Regulation (EU) 2024/2847)

For manufacturers of products with digital elements placed on the EU market. Details, roles and the
reporting runbook are in CRA Vulnerability Handling (`security/cra-vulnerability-handling`). This
policy supports the following provisions (summaries in our own words; check the consolidated text on
EUR-Lex):

| Provision | What it expects (summary) | How this policy contributes | Applies from |
|---|---|---|---|
| Annex I, Part II, point (5) | Put in place and enforce a coordinated vulnerability disclosure policy | Sections 1 to 9 are that policy | 11 December 2027 |
| Annex I, Part II, point (6) | Make it easy to report vulnerabilities, including by providing a contact address | Section 4 and Appendix A | 11 December 2027 |
| Annex I, Part II, points (4) and (8) | Disclose fixed vulnerabilities publicly with information for users, and distribute security updates without delay | Sections 5 and 7 | 11 December 2027 |
| Article 13(8) | Handle vulnerabilities effectively during the support period, normally at least five years | Section 5 targets and the PSIRT procedure | 11 December 2027 |
| Article 13(17) | Designate a single point of contact for users, including for vulnerability reports | Section 4 channels | 11 December 2027 |
| Article 14 | Notify actively exploited vulnerabilities and severe incidents through the ENISA Single Reporting Platform (24-hour early warning, 72-hour notification, final report) | Section 6.2 early publication; reporting itself is run by the PSIRT procedure | 11 September 2026 |

A report received under this policy can start the Article 14 clock if it contains reliable evidence
of active exploitation. The PSIRT procedure defines how intake staff recognise that case and
escalate it.

### 10.2 Standards and guidance

| Source | How it is used here |
|---|---|
| ISO/IEC 29147:2018, *Vulnerability disclosure* | Topic coverage: receiving reports (sections 4 and 5 of this policy), coordination (section 6), publishing advisories (section 7) and the disclosure policy itself. Structure only, no text reproduced. A third edition is in development: check iso.org |
| ISO/IEC 30111:2019, *Vulnerability handling processes* | The internal process behind section 5 (see `security/psirt-vulnerability-handling`) |
| RFC 9116, *A File Format to Aid in Security Vulnerability Disclosure* (April 2022) | Appendix A |
| OpenSSF *Guide to coordinated vulnerability disclosure for open source software projects* (CC BY 4.0) | Repository reporting channel (SCOPE-004) and embargo practice for the open source tool |
| CERT Guide to Coordinated Vulnerability Disclosure (SEI, CMU/SEI-2017-SR-022) | Background concepts of CVD roles and phases (concepts only) |
| CVE Program, CNA Operational Rules 4.2.0 (effective 2026-08-25) | Section 7.1 |
| CISA Secure by Design Pledge (2024) | Publishing a VDP and CVE transparency are pledge goals; see `security/secure-by-design-roadmap` |

Also check: national transposition of the NIS2 Directive (EU) 2022/2555, which encourages national
CVD schemes (see `compliance/nis2-security-measures`); national computer misuse laws and
prosecutorial guidance on good-faith research; and customer contracts with fixed vulnerability
notification times.

## 11. Internal: governance, measurement and review

<!-- Guidance: Internal section. Name the owner, the measures that show the promise is kept, and how exceptions are approved. Report the measures to the security steering group each quarter. -->

### 11.1 Roles and responsibilities

| Role | Responsibility |
|---|---|
| PSIRT lead (policy owner) | Maintains this policy and security.txt; owns the response targets in section 5 |
| Intake rota | Monitors channels in 4.1 every business day; acknowledges within target |
| General counsel | Approves section 3 wording and any departure from it in a specific case |
| Communications lead | Approves advisory wording for high-profile issues and press responses |
| Product engineering owners | Fix vulnerabilities within the targets agreed by the PSIRT |
| CISO | Approves extensions beyond published targets and accepted-risk decisions |

### 11.2 Policy statements

- VDP-PS-01: Every product listed in 2.1 MUST have a monitored reporting channel and appear in
  security.txt or SECURITY.md.
- VDP-PS-02: The security.txt `Expires` value MUST be refreshed before it passes; the PSIRT lead
  SHOULD renew it every [6] months *Example*.
- VDP-PS-03: Any response to a researcher that departs from section 3 MUST be approved by general
  counsel.
- VDP-PS-04: Internal targets in the PSIRT procedure (7.4) MUST be equal to or tighter than the
  targets published in section 5; published targets MUST NOT be tighter than the internal ones.
  SECURITY.md files and the CRA procedure MUST quote the same published values.
- VDP-PS-05: New products and acquired assets SHOULD be added to scope within [90] days *Example* of
  launch or acquisition.

### 11.3 Measures

| Measure | Formula | Target |
|---|---|---|
| Acknowledgement within target | Reports acknowledged within 2 business days / all reports received, per quarter | ≥ 95 % *(Example)* |
| Median time to triage decision | Median of (triage decision date minus receipt date) | ≤ 7 days *(Example)* |
| Fix within published target | Valid reports fixed within the section 5 window / valid reports due in the quarter | ≥ 90 % *(Example)* |
| Coordinated disclosure rate | Valid reports published on the agreed date / valid reports published | ≥ 90 % *(Example)* |
| security.txt freshness | Days until `Expires`, checked weekly | > 30 days at all times *(Example)* |

*Example quarter for Corvid Commerce:* 48 reports received, 46 acknowledged within 2 business days
(46 / 48 = 95.8 %); 12 valid, 11 fixed within target (11 / 12 = 91.7 %).

**Exceptions and review.** Exceptions to published targets are approved by the CISO, recorded in the
case, and explained to the finder. Review this policy at least annually, after any significant
incident involving a researcher, and when scope, legal entities or applicable law change. Record
each review in the Revision history.

## 12. Glossary and references

<!-- Guidance: Keep definitions short and consistent with the PSIRT procedure. -->

### 12.1 Glossary

| Term | Meaning in this policy |
|---|---|
| Coordinated vulnerability disclosure (CVD) | Practice of finders, vendors and coordinators working together so that a fix or mitigation is available before details become public |
| Vulnerability disclosure policy (VDP) | The public statement of how an organisation receives and handles vulnerability reports |
| Finder, reporter, researcher | The person or organisation that reports a vulnerability |
| Embargo | Agreed period during which vulnerability details stay confidential |
| CNA | CVE Numbering Authority: an organisation authorised by the CVE Program to assign CVE IDs and publish CVE Records within a defined scope |
| CVE Record | The public entry describing a vulnerability with a CVE ID |
| VEX | Vulnerability Exploitability eXchange: a statement of whether a product is affected by a vulnerability |
| PSIRT | Product security incident response team: the team that handles vulnerabilities in the products we make |
| Safe harbour | Our commitment not to pursue claims against good-faith research that follows this policy |

### 12.2 References

| Reference | Use |
|---|---|
| ISO/IEC 29147:2018, *Information technology, Security techniques, Vulnerability disclosure* (iso.org/standard/72311.html) | Topic structure |
| ISO/IEC 30111:2019, *Information technology, Security techniques, Vulnerability handling processes* (iso.org/standard/69725.html) | Internal process link |
| RFC 9116, E. Foudil and Y. Shafranovich, April 2022 (rfc-editor.org/info/rfc9116) | security.txt format |
| Regulation (EU) 2024/2847 (Cyber Resilience Act), OJ L, 20.11.2024 (eur-lex.europa.eu/eli/reg/2024/2847/oj) | Section 10.1 |
| CVE Program, CNA Operational Rules 4.2.0 (cve.org) | Section 7.1 |
| OpenSSF, *Guide to coordinated vulnerability disclosure for open source software projects* (github.com/ossf/oss-vulnerability-guide), CC BY 4.0 | Open source channel and embargo practice |
| CERT Guide to Coordinated Vulnerability Disclosure, SEI (certcc.github.io/CERT-Guide-to-CVD) | Background concepts |
| FIRST, *Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure* v1.1 | Section 6.3 (cited by name) |
| Security Policy (`dev/security-policy`) | Short SECURITY.md per repository that links here |
| PSIRT Vulnerability Handling Procedure (`security/psirt-vulnerability-handling`) | Internal handling |
| CRA Vulnerability Handling (`security/cra-vulnerability-handling`) | EU CRA duties |
| Security Advisory (`security/security-advisory`) | Advisory format |
| SBOM and VEX Policy (`security/sbom-vex-policy`) | VEX statements |
| Vulnerability Management Policy (`security/vulnerability-management-policy`) | Consumer-side scanning and patching |
| Penetration Test Report (`security/pentest-report`) | Commissioned testing, which is separate from this policy |
| Incident Communication (`dev/incident-communication`) | Customer communication when a vulnerability becomes an incident |

## Appendix A: Ready security.txt file

<!-- Guidance: Publish at https://[domain]/.well-known/security.txt over HTTPS as text/plain; charset=utf-8. Contact and Expires are required by RFC 9116; all other fields are optional. Keep Expires less than a year ahead, sign the file with an OpenPGP cleartext signature, and include Canonical when you sign. Publish one file per domain: the file applies only to the domain it is served from. -->

The file below follows RFC 9116. Replace the *Example* values and sign it with the key named in
`Encryption`.

```text
# security.txt for corvid-commerce.example (Example)
# Report security vulnerabilities to the contacts below.
# Our disclosure policy explains scope, safe harbour and timelines.

Contact: https://www.corvid-commerce.example/security/report
Contact: mailto:security@corvid-commerce.example
Expires: 2027-04-30T23:59:59.000Z
Encryption: https://www.corvid-commerce.example/.well-known/security-pgp.asc
Acknowledgments: https://www.corvid-commerce.example/security/thanks
Preferred-Languages: en
Canonical: https://www.corvid-commerce.example/.well-known/security.txt
Policy: https://www.corvid-commerce.example/security/disclosure-policy
Hiring: https://www.corvid-commerce.example/careers/security
```

Field notes:

| Field | Required | Notes |
|---|---|---|
| `Contact` | Yes, one or more | List in order of preference; use `mailto:`, `tel:` or `https:` URIs |
| `Expires` | Yes, exactly once | RFC 3339 date and time; recommended less than one year ahead |
| `Encryption` | No | Link to the key, never the key itself |
| `Acknowledgments` | No | Link to the hall of fame (section 8) |
| `Preferred-Languages` | No, at most once | Comma-separated language tags |
| `Canonical` | No | The URI where this file lives; include it when signing |
| `Policy` | No | Link to this policy |
| `Hiring` | No | Link to security job openings |
| `CSAF` | No (registered extension field) | Link to a CSAF provider metadata file, if you publish CSAF advisories; check the IANA security.txt fields registry |

Operational checks: serve the file with HTTP status 200 and `Content-Type: text/plain;
charset=utf-8`, redirect the legacy root path `/security.txt` to the well-known path if you serve
both, add a monitoring check that alerts 30 days before `Expires` *(Example)*, and test that the
reporting form and mailbox deliver to the intake rota.

## Standard and licence note

Structure aligned with the topics of ISO/IEC 29147:2018 *Vulnerability disclosure*; no text, tables
or definitions from that copyrighted standard are reproduced, and a new edition is in development,
so check the current edition at iso.org. Appendix A is based on RFC 9116 (April 2022), whose field
names are used under the IETF Trust's provisions for reuse. EU Cyber Resilience Act references are
original summaries of Regulation (EU) 2024/2847: check the consolidated text on EUR-Lex. Open source
practice draws on concepts from the OpenSSF *Guide to coordinated vulnerability disclosure for open
source software projects* (CC BY 4.0, github.com/ossf/oss-vulnerability-guide); the CERT Guide to
Coordinated Vulnerability Disclosure (SEI) and the FIRST multi-party guidelines are cited by name
and concept only. The safe harbour structure follows the pattern common to public-domain VDP templates; all
wording, including the safe harbour example, is original text written for this collection and is
not legal advice. Check the current official versions of every source before
publication. Template licence: MIT.