From bbfdf6042b7a7a1e8d37b4d0868af13be569c3ba Mon Sep 17 00:00:00 2001 From: Jasper van Woudenberg Date: Thu, 4 Dec 2025 13:31:05 -0800 Subject: [PATCH 1/2] Add Short-Form Report Guidance to framework documentation Signed-off-by: Jasper van Woudenberg --- Documentation/framework.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/Documentation/framework.md b/Documentation/framework.md index 1425a88..827dec7 100644 --- a/Documentation/framework.md +++ b/Documentation/framework.md @@ -326,6 +326,17 @@ use the findings in the report to improve design, engineering, build, and test p Several SRP sample reports can be found in [Appendix A](#appendix-a-example-reports). + + +## 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). + * 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.” +* **Classifying “Informational”:** A finding can only be Informational when the CVSS score is 0.0. As such, informational findings are not 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. + + # Appendix A: Example Reports * Atredis Partners - [Sample Deliverables](https://www.atredis.com/sample-deliverables) From c7ac42c1091cbe853994f292a9452185a546f6ed Mon Sep 17 00:00:00 2001 From: jasperkeysight Date: Thu, 18 Dec 2025 11:51:35 -0800 Subject: [PATCH 2/2] Update Documentation/framework.md Co-authored-by: Evan Anderson <1253158+evan-a-a@users.noreply.github.com> --- Documentation/framework.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/framework.md b/Documentation/framework.md index 827dec7..ed5441d 100644 --- a/Documentation/framework.md +++ b/Documentation/framework.md @@ -333,7 +333,7 @@ Several SRP sample reports can be found in [Appendix A](#appendix-a-example-repo * **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.” -* **Classifying “Informational”:** A finding can only be Informational when the CVSS score is 0.0. As such, informational findings are not included in the SFR. +* **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.