From 576f968f1f15cb26087d992798e6082c45180c0a Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Mon, 26 Oct 2020 13:43:22 -0400 Subject: [PATCH] reset inadvertent change --- doc/version_1/040_treesForVulMgmt.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/version_1/040_treesForVulMgmt.md b/doc/version_1/040_treesForVulMgmt.md index ba9ba24e..112fd9d6 100644 --- a/doc/version_1/040_treesForVulMgmt.md +++ b/doc/version_1/040_treesForVulMgmt.md @@ -20,7 +20,7 @@ Relatedly, C-level executives and public policy professionals often make, shape, ## Enumerating Decisions -Stakeholders with different responsibilities in vulnerability management have largely different decisions to make. This section focuses on the differences among organizations based on their vulnerability management responsibilities. Some decision makers may have different responsibilities in relation to different software. For example, an Android app developer is a supplier of the app, but is a deployer for any changes to the Android OS API. This situation is true for libraries in general. A web browser supplier makes decisions about applying patches to DNS lookup libraries and transport layer security (TLS) libraries. A video game supplier makes decisions about applying patches released to the Unreal Engine. A medical device supplier makes decisions about applying patches to the Linux kernel. The list goes on. Alternatively, one might view applying patches as, de facto, including some development and distribution of the updated product. Or one might take the converse view, that development, de facto, includes updating libraries. Either way, in each of these examples (mobile device apps, web browsers, video games, medical devices), we recommend that the professionals making genuine decisions do three things: (1) identify the decisions explicitly, (2) describe how they view their role(s), and (3) identify which software projects their decision relates to. If their decisions are explicit, then the decision makers can use the recommendations from this document that are relevant to them. +Stakeholders with different responsibilities in vulnerability management have largely different decisions to make. This section focuses on the differences among organizations based on their vulnerability management responsibilities. Some decision makers may have different responsibilities in relation to different software. For example, an Android app developer is a developer of the app, but is a deployer for any changes to the Android OS API. This situation is true for libraries in general. A web browser developer makes decisions about applying patches to DNS lookup libraries and transport layer security (TLS) libraries. A video game developer makes decisions about applying patches released to the Unreal Engine. A medical device developer makes decisions about applying patches to the Linux kernel. The list goes on. Alternatively, one might view applying patches as, de facto, including some development and distribution of the updated product. Or one might take the converse view, that development, de facto, includes updating libraries. Either way, in each of these examples (mobile device apps, web browsers, video games, medical devices), we recommend that the professionals making genuine decisions do three things: (1) identify the decisions explicitly, (2) describe how they view their role(s), and (3) identify which software projects their decision relates to. If their decisions are explicit, then the decision makers can use the recommendations from this document that are relevant to them. ### Supplying Patches