Note

This content has been integrated into the CERT® Guide to Coordinated Vulnerability Disclosure and is no longer being maintained here. See https://certcc.github.io/CERT-Guide-to-CVD/reference/policy_templates/

Vulnerability Disclosure Policy Templates

This repository contains a collection of resources intended for use in constructing a vulnerability disclosure policy. It's based on work done by the CERT Coordination Center (CERT/CC) at Carnegie Mellon University's Software Engineering Institute (SEI).

In recent years the CERT/CC has advised a number of organizations on their vulnerability disclosure policies. Here we are attempting to capture common verbiage in order to help others develop or improve their own policies. We've taken these items from a variety of vulnerability disclosure policies including our own, generalized them, organized them by topic, and put it into markdown files in a git repository.

Approach

The policy templates in this repository are meant to be remixed and adapted for different organizations and contexts. It is unlikely that any single organization would choose to adopt all of these items wholesale without some modification.

We've taken the approach of using RFC-style "MUST, SHALL, SHOULD..." language in active-voice sentences to describe what researchers/reporters and vendors/coordinators/recipients should expect of each other.

Also, organizations using these templates might change some of the SHOULDs to MUSTs or MAYs to SHOULD NOTs etc.

It's a start at having a general set of templates from which you can derive and spawn a disclosure policy for an organization. The idea is not that you'd just wantonly take the whole thing -- in fact as currently drafted some points could conflict with or mutually exclude others -- it's that you'd take it as a draft and edit it into whatever you want your policy to say. But hopefully it has enough breadth of coverage across issues that the words address most of what you might want a policy to cover.

Organizations will likely find that some expectations do not apply to their situation based on the kind of stakeholder they are. In particular we anticipate that product vendors, service providers, and coordinators will have related but distinct needs. Inclusion or exclusion of items from these templates into your organization's policy should be based on which combination of stakeholder roles you expect to play.

Style Guide

This style guide applies to the collected policy statements we've assembled here, but we think it's likely to be useful when constructing your policy too.

• Each item in a policy should cover a single expectation. Rationale: Items should be clear and simple to facilitate interpretation by all participants.
• Each item SHOULD use "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" consistent with their meaning in RFC 2119. (See Terminology.md) Rationale: RFC-style makes clear the distinction between expectations that are recommendations versus those that are requirements.
• Write each policy expectation item in the active voice. This means every statement has a clear actor and an expectation on that actor. (ORGANIZATION SHALL..., Reporter MAY..., etc.) Rationale: Active voice makes it easy to recognize to whom the expectation applies.
• In general, expectations of others should use "MAY", "SHOULD", "MUST", "MUST NOT", "REQUIRED", or "OPTIONAL". Expectations that the ORGANIZATION sets for itself should prefer "SHALL" and "SHALL NOT" in place of "MUST" or "MUST NOT". Similarly, it seems unlikely that ORGANIZATION would use "SHOULD" to refer to its own behavior, rather preferring to use "SHALL", "SHALL NOT", or "MAY" formulations. Rationale: The policy creator is declaring limits and expectations on their own behavior, not recommending to others what they can/should/might do. In other words, use imperatives for others, declaratives for self.
• To the degree possible, separate expectations by role. For example, as we have done by splitting Reporters.md and Receivers.md into separate files. In a real policy, these would become different sections of the document.
• Limit the logical complexity of individual expectations. A single conditional is fine. Consider splitting statements containing multiple conditionals into separate statements.
• Consider symmetry in policy expectation items. For example, if you expect politeness from Reporters, do you also commit to being polite?
• Use CAPITAL LETTERS to denote KEYWORDS. These are essentially variables to be substituted in the policy development process.
• Put relevant KEYWORDS in Terminology.md to provide definitions or references to definitions. This is especially important if the KEYWORD is being used with some specific meaning that may otherwise be ambiguous.

Usage guide

Here's a checklist of tasks you should complete in order to make use of these templates.

1. Review the content of these files.
2. Select the policy expectation items you want to use.
3. Replace any KEYWORDS with an appropriate substitution (e.g., "45 days" instead of "SLC").
4. Contruct a single policy document from the collected items.
5. Add any needed introduction, boilerplate, or legal info to the document.
6. Review the entire document for internal consistency and fix any contradictions.
7. Review the document for external consistency with other organization policies, applicable laws, regulations, etc.

• We are not lawyers, and these documents are not legal advice. You are encouraged to consult your own legal counsel.

8. Get approval for the policy and to publish the document from necessary decision makers
9. Establish sufficient operational capability in order to provide the serivce(s) the policy commits you to offer.
10. Publish the policy

Content Organization

Most of the content is in the Receivers.md and Reporters.md files.

We've split the content into segments based on topic areas.

• Reporters.md contains a set of policy templates that an organization can use to prescribe or constrain researcher activity
• Receivers.md contains a set of policy templates that an organization can use to describe its own activity.
• Terminology.md contains some definitions and pointers to what we mean by words in ALL CAPS in the other pages.
• TODO.md has any outstanding known improvements not yet implemented

Contributing

Contributors should feel empowered to suggest whatever you think would improve this collection. In order to keep the project focused, though, we ask that Contributors adhere to these guidelines:

1. Read and understand this Readme.md.
2. Follow the style advice above.
3. Create your own fork of this repository, and make edits there.
4. Submit issues or pull requests (preferred) with suggested changes or create issues in this project with feedback.
5. Ask questions if anything is unclear.

References

See References.md

License

See LICENSE