Add Short-Form Report Guidance to framework documentation #63
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Jasper van Woudenberg <[email protected]>
Contributor
|
Unrelated to the immediate changes in this PR, but related in general, this sentence in the framework has caused a lot of confusion:
Since, technically speaking, every finding has a CVSS score, but it may not be a positive CVSS score. We should probably also reword this section to say:
|
evan-a-a
reviewed
Dec 10, 2025
Co-authored-by: Evan Anderson <[email protected]>
rob-tetrel
reviewed
Dec 19, 2025
|
|
||
|
|
||
|
|
||
| ## Short-Form Report Guidance |
Contributor
There was a problem hiding this comment.
Suggested change
| ## Short-Form Report Guidance | |
| ### Short-Form Report Guidance |
|
|
||
| ## Short-Form Report Guidance | ||
|
|
||
| * **Issue detail level:** The SFR should describe risks for product consumers and encourage vendors to improve security. Include enough detail to explain impact, but avoid exploit-enabling specifics. Protect IP by omitting code identifiers (variable, module, or function names). |
Contributor
There was a problem hiding this comment.
Suggested change
| * **Issue detail level:** The SFR should describe risks for product consumers and encourage vendors to improve security. Include enough detail to explain impact, but avoid exploit-enabling specifics. Protect IP by omitting code identifiers (variable, module, or function names). | |
| * **Issue detail level:** The SFR should describe risks for CSPs and encourage the DV to improve security. Include enough detail to explain impact, but avoid exploit-enabling specifics. Protect IP by omitting code identifiers (variable, module, or function names). |
| * **Issue detail level:** The SFR should describe risks for product consumers and encourage vendors to improve security. Include enough detail to explain impact, but avoid exploit-enabling specifics. Protect IP by omitting code identifiers (variable, module, or function names). | ||
| * Example phrasing: “Integer overflow in secure boot could lead to arbitrary code execution in ROM”; “Insecure protection configuration allows loading unsigned code.” | ||
| * Avoid: “external_parser.c:195 parse_xml(xml_string) has a stack overflow when xml_string exceeds 1024 bytes, leading to arbitrary code execution.” | ||
| * **Qualitative Risk Ratings:** Any qualitative risk rating used by the SRP when reporting findings is not relevant for the purposes of the SFR. For the avoidance of doubt, the CVSS score is the **only** factor determining whether a finding should be included in the SFR. As such, any finding with a non-zero CVSS score **must** be included in the SFR. |
Contributor
There was a problem hiding this comment.
Suggested change
| * **Qualitative Risk Ratings:** Any qualitative risk rating used by the SRP when reporting findings is not relevant for the purposes of the SFR. For the avoidance of doubt, the CVSS score is the **only** factor determining whether a finding should be included in the SFR. As such, any finding with a non-zero CVSS score **must** be included in the SFR. | |
| * **Quantitative Risk Ratings:** The SFR uses CVSS for quantitative risk ratings. The CVSS score is the primary factor determining whether a finding should be included in the SFR. As such, any finding with a non-zero CVSS score **must** be included in the SFR if it is within the defined security review scope. Findings with a CVSS score of zero, by definition pose no risk to the CSP and must be excluded. |
| * Example phrasing: “Integer overflow in secure boot could lead to arbitrary code execution in ROM”; “Insecure protection configuration allows loading unsigned code.” | ||
| * Avoid: “external_parser.c:195 parse_xml(xml_string) has a stack overflow when xml_string exceeds 1024 bytes, leading to arbitrary code execution.” | ||
| * **Qualitative Risk Ratings:** Any qualitative risk rating used by the SRP when reporting findings is not relevant for the purposes of the SFR. For the avoidance of doubt, the CVSS score is the **only** factor determining whether a finding should be included in the SFR. As such, any finding with a non-zero CVSS score **must** be included in the SFR. | ||
| * **Configuration-dependent findings:** If a finding hinges on deployment configuration and the secure configuration plus associated risks are clearly documented in integration guidelines, it should be excluded from the SFR. If integration guidelines are missing and insecure configurations are plausible, include the finding in the SFR. |
Contributor
There was a problem hiding this comment.
Suggested change
| * **Configuration-dependent findings:** If a finding hinges on deployment configuration and the secure configuration plus associated risks are clearly documented in integration guidelines, it should be excluded from the SFR. If integration guidelines are missing and insecure configurations are plausible, include the finding in the SFR. | |
| * **Configuration-dependent findings:** Findings may exist that depend on configuration. | |
| * If a finding depends on the CSPs deployment configuration and the secure configuration plus associated risks are clearly documented in DV-providedd integration guidelines, it should be excluded from the SFR. If integration guidelines are missing and insecure configurations are plausible, include the finding in the SFR. | |
| * If a finding depends on DV-provided configuration (such as factory fuse configuration) in a way that allows a configuration change to undermine the security of the target without altering the firmware hash recorded in the SFR, then the finding should be included in the SFR. |
Contributor
@evan-a-a |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Added “Short-Form Report Guidance” section before Appendix A in Documentation/framework.md, covering appropriate issue detail, informational classification, and handling configuration-dependent findings. I suggest we leave this open for a few weeks for comments.