Received from someone involved in CERT/CC's CVD service:

We're seeing reporters decline to report through bounty/VDPs that have terms the reporters don't like. 3-4 specific occurrences with us directly / recently. I quoted part of the guide to affected vendors but suggest a stronger "control is an illusion, focus on how badly you want the reports to come in" and related "bounty/VDP terms might dissuade reporting."

Describe the bug

Inline $\LaTeX$ doesn't always render the first time a page loads.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://certcc.github.io/CERT-Guide-to-CVD/howto/preparation/topology/
2. The Pairwise Communiction Complexity inset at top right should have $(N^2-N)/2$ in it. Sometimes it doesn't.
3. If it doesn't show up, reload the page
4. Note that the inline $\LaTeX$ shows up after reload

Expected behavior

Inline $\LaTeX$ should load correctly the first time.

Additional context

Solution is to modify mathjax.js as in CERTCC/Vultron#74

We currently use "remediation" in the guide to mean both fix and mitigate.
For example, see section 4.4 Remediation
But other sources use remediation to mean something disjoint from mitigation.

• The first question to address is whether we are the outlier or not.
• The second question is to suggest how the guide can identify, define, and consistently use terms representing:
• (1) "fix", "patch" (noun) - a complete elimination of the vulnerability
• (2) "mitigation", "partial fix", "workaround" (noun) - a reduction in risk (either impact OR probability) posed by the vulnerability that does not meet the criteria for (1)
• (3) "remediation" (noun) An umbrella term for the set of both (1) and (2) (noun) - any action taken in response to the existence of a vulnerability that decreases associated risk (possibly to zero)
• (4) "vulnerability response" (noun) - An umbrella term for things that one does in response to the existence of a vulnerability, regardless whether it affects the associated risk or not

The list above reflects current usage in the guide, but depending on whether or not we use "remediation" to mean 1 or 3, then any of these may need to change.

References to the "remediation = fix (only)" usage include:

1. https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/853101p.pdf?ver=2020-09-15-143058-347
2. https://blog.rapid7.com/2020/09/14/vulnerability-remediation-vs-mitigation-whats-the-difference/

This issue is closely related to SSVC#46

A PDF of the original 2017 report exists.

The current version is the Confluence wiki space at https://vuls.cert.org/confluence/display/CVD

We currently lack a good way to reconstruct a PDF from the wiki.

Options to consider (suggest others in comments if you have any):

1. A stylesheet in confluence that exports the wiki space to a formatted doc (I think you can do this for individual wiki pages but I'm not sure if you can export a whole space that way)
2. Convert content to markdown, put it in a git repo (possibly this one), and construct toolchain(s) that can (a) generate a PDF and (b) populate content back into Confluence
3. Do 2 and 2a, but skip 2b and replace hosting it in Confluence with something that does more native markdown->webserver stuff, a la github pages or something like that

It would be convenient to have all the defined terms in one place. A glossary would be ideal.
Secondary request is to have the document self-link, so that it's obvious when a term in the text is defined in the glossary.

Chapter 4 of the guide covers the phases of CVD, which makes sense from an individual case level. However, it doesn't address the sorts of processes and capabilities that are needed to sustain a CVD practice. Many of these words are already present in the document, but they're scattered throughout.

The suggestion of this issue is to create a section or possibly up to an entire chapter on the more capability/process oriented stuff. It's probably based off the existing Operational Considerations chapter, but with a bit more content.
What I specifically have in mind are "metacoordination" topics like:

• disclosure & embargo policy management
• the tech stuff from ch7 (case tracking, secure comms, etc.)
• community management (vendor groups, tech groups, researcher groups etc.)
• staffing/analyst considerations (some already present in ch7)

MPCVD requires coordination across potentially large groups of participants (vendors, reporters, coordinators, etc.). Yet the increasing tendency towards portal-based CVD (including VINCE) means that everyone has to have some level of account or access to everyone else's tracking system(s). In the long run, this is unsustainable. There are two possible directions: centralization or decentralized interoperability. Vultron is intended to enable the decentralized option. The guide should talk about that as an emerging issue as things shift away from email-based ad-hoc coordination.

This is from Johannes Clos discussions at Vulncon'24

Is your feature request related to a problem? Please describe.
ENISA presented the idea of how Coordination of Coordinators is expected to happen through bodies like ENISA at Vulncon 24 https://www.first.org/conference/vulncon2024/ How does a guide such as CVD guide address these issues of hierarchy of coordinations.

Describe the solution you'd like
An identification of how Coordinators can work with other Coordinators and what are the expectations/challenges of such workflows. What could be a good way to reduce duplication of work.

Describe alternatives you've considered
None

Additional context
VulnCon where this discussions was initiated.

Describe the solution you'd like

We need to talk about CVD for AI / ML systems and the variation that happens because of this. It might be a special topic like the IoT content.

Additional context

Whatever we include should extend from https://www.nspw.org/papers/2020/nspw2020-spring.pdf

Describe the bug

Double backticks should include a space:

Reporters SHOULD NOT disclose any details of any extant `ORGANIZATION``SYSTEM SCOPE` ...

should be 

```markdown
Reporters SHOULD NOT disclose any details of any extant `ORGANIZATION` `SYSTEM SCOPE` ...

To Reproduce

Steps to reproduce the behavior:

1. Go to https://certcc.github.io/CERT-Guide-to-CVD/reference/policy_templates/reporters
2. See error

Expected behavior

This was a double-search-and-replace that went wonky, so it should just be two terms with single backticks to make them fixed width font.

Screenshots

Describe the solution you'd like

Migrate content from the Confluence wiki
to certcc.github.io/CERT-Guide-to-CVD

Additional context

• We want to migrate off of that confluence instance
• We want to have more transparency/traceability of changes to the guide
• We want to encourage community engagement

Describe the solution you'd like

We have a separate repository https://github.com/CERTCC/vulnerability_disclosure_policy_templates
that contains words one might include in a disclosure policy.
We could just roll these into the CVD guide and eliminate the need for a separate repository.

Describe alternatives you've considered

Status quo is to leave https://github.com/CERTCC/vulnerability_disclosure_policy_templates alone. Which makes it less likely that folks will ever encounter that content.

The words in the templates were condensed from a disclosure policy survey we did a few years ago.

Is your feature request related to a problem? Please describe.
No

Describe the solution you'd like
We should highlight some of the supply-chain CVD processes and concerned areas.

Describe alternatives you've considered
There may be just a potential link to Supply-Chain Disclosure if there is such a generic thing. In this context, Disclosure could be not just Vulnerability but any other incident that supply-chain stakeholders should communicate with each other for reliable usage of products/services.

Additional context
Recent cybersecurity incidents and US National Cybersecurity Strategy have highlighted supply-chain concerns. We need to consider and perhaps expand more of the Vertical and Horizontal supply-chain concerns. The current supply chain concerns are mentioned in

• https://certcc.github.io/CERT-Guide-to-CVD/howto/coordination/cvd_recipes/#16
• https://certcc.github.io/CERT-Guide-to-CVD/howto/coordination/cvd_recipes/#17
• https://certcc.github.io/CERT-Guide-to-CVD/howto/coordination/cvd_recipes/#18
• https://certcc.github.io/CERT-Guide-to-CVD/howto/coordination/mpcvd

We could spend a bit more information on how CVD process should inherently observe and adopt supply-chain for OEM's and their relationships to OCM (Original Component Manufacturer) and multi-level OCM providers. Concerns such as OCM being an open source project - how does supply-chain CVD work ripple impact disclosure from OEM to OCM or the other way.

Github supports privately reporting security information, see

https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability

The guide should say something about this & any other methods we come across specifically for open source projects.

Is your feature request related to a problem? Please describe.

A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]****

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Capturing different versions of the guide:

v1 = initial release
v2 = web version, summarize new content
v3 = current work

etc...

Received from someone involved in CERT/CC's CVD service:

We're seeing reporters decline to report through bounty/VDPs that have terms the reporters don't like. 3-4 specific occurrences with us directly / recently. I quoted part of the guide to affected vendors but suggest a stronger "control is an illusion, focus on how badly you want the reports to come in" and related "bounty/VDP terms might dissuade reporting."

Is your feature request related to a problem? Please describe.

The text on https://vuls.cert.org/confluence/display/Wiki/CVE+IDs+and+How+to+Obtain+Them is outdated

How are CVE IDs Assigned?
MITRE is the primary maintainer of CVE, and therefore the primary assigner for CVE IDs. When a new vulnerability is reported, MITRE researches the vulnerability to determine the details and if the vulnerability has previously been reported by someone else. If the vulnerability appears to be new, then a new CVE ID is assigned to the vulnerability for use in future discussion and communications.

However, MITRE has designated a small group of third party organizations as CVE Numbering Authorities (CNAs), meaning these organizations have limited authority on assigning CVE IDs without MITRE's involvement in some circumstances. CNAs are expected to follow the same assignment rules that MITRE follows; this sometimes means that CVE ID assignment decision does not match what you may expect. The CNAs then report the newly-assigned CVE IDs to MITRE, or publish an advisory with the CVE IDs, so that MITRE can include the CNA-assigned CVE IDs in the overall MITRE CVE dictionary.

Generally, large software vendors are CNAs for their own products; for example, Microsoft and Red Hat can assign CVE IDs to vulnerabilities in their own products, and only their own products. MITRE provides a list of CNAs.

The CERT/CC is a more general CNA; while we can assign CVE IDs for most products, we generally do not assign CVE IDs for vulnerabilities in products handled by other CNAs. We are also generally restricted to only assign CVE IDs to vulnerabilities we directly coordinate.

Describe the solution you'd like
While MITRE is a Root CNA and a CNA of last resort, it no longer runs the CVE program. It acts as the Secretariat for the Board, but the board is independent and MITRE has transitioned formal operations of the CVE program to the board.

There are also now hundreds of CNAs and that number is growing rather quickly, I expect that is a material change since this text was written. So the tone should probably shift from "there are a small number of CNAs" to something more like there are a number of CNA's and the CVE program encourages organizations that regularly interact with CVE assignment to contact their Root CNA to become a CNA themselves.

Describe alternatives you've considered
I think leaving it alone is probably not factually correct any longer; it was correct when written but the world has changed since then.

Describe the solution you'd like

We already have a discussion of TLP in https://certcc.github.io/CERT-Guide-to-CVD/howto/operation/opsec

A recent conversation with a member of the FIRST TLP SIG brought attention to the idea that we can express an embargo in terms of TLP transitions (e.g., AMBER -> CLEAR) so we should mention that in the embargo discussion and link to the existing TLP words too.