edits to make docs more stand-alone

znlstar · Jan 10, 2019 · 3879ae9 · 3879ae9
1 parent e9c6248
commit 3879ae9
Show file tree

Hide file tree

Showing 2 changed files with 56 additions and 38 deletions.
diff --git a/landscape/README.md b/landscape/README.md
@@ -1,20 +1,34 @@
 ## Goal
 
-We propose the creation of a separate security-focused landscape (similar to the separate, Serverless-focused landscape)
-that uses major categories that are similar to those used in the primary CNCF Landscape, but with sub-categories that
+The [SAFE roadmap](../roadmap.md) includes describing the landscape of
+cloud-native security. We evaluated categories in the CNCF Landscape and
+determined the need for a [modified approach](cncf.md).
+
+We propose major categories that are similar to those in the
+[CNCF Landscape](https://landscape.cncf.io/), but with sub-categories that
 highlight the main security considerations in each category.
 
-In this document we propose the draft structure of the “Security Landscape”. At this stage we are _only_ proposing
-the structure of the Security Landscape and are not attempting to fill it in with tools from the existing CNCF Landscape.
-We drafted this document after reviewing the current list of projects in the CNCF Landscape and recommendations by SANS and
-Gartner for good security practices, as well as drawing on our own experience. In future work, we will work with the
-community to determine how best to map cloud-native tools into the sub-categories of the "Security Landscape" we propose below.
+We propose [categories](categories.md) as a draft structure for a “Cloud Native
+Security Landscape”. We drafted this document after reviewing the current list
+of projects in the CNCF Landscape and recommendations by SANS and Gartner for
+good security practices, as well as drawing on the experience of the SAFE WG.
+
+Next steps:
+[ ] Determine approach to category mapping (see below)
+[ ] Map cloud-native tools into categories (adjusting categories as needed)
+[ ] Validate categories and landscape with review by makers and users of
+    cloud-native security solutions, as well as partner working groups
 
-A note on how the work of mapping tools into the sub-categories may proceed: we do not currently have plans for precisely
-how projects will be mapped into the Security Landscape. If we were to follow the model of the current CNCF landscape we
-would require each project to be placed in exactly one security landscape sub-category, but this forces tools with multiple
-common uses to artificially choose a “most common” use case as its sub-category. A possible alternative will be to define a
-list of key features, map the key features into the landscape sub-categories, and then list the key features of each tool.
-In this flow, individual tools may appear in multiple sub-categories. Deciding precisely how to map tools into the security
-landscape sub-categories is future work and will occur after gathering feedback from the community on the preferred solution.
+A note on how the work of mapping tools into the sub-categories may proceed:
+we do not yet have plans for precisely how projects will be mapped into the
+Security Landscape. If we were to follow the model of the current CNCF landscape
+we would require each project to be placed in exactly one security landscape
+sub-category, but this forces tools with multiple common uses to artificially
+choose a “most common” use case as its sub-category. A possible alternative
+will be to define a list of key features, map the key features into the
+landscape sub-categories, and then list the key features of each tool.
+In this flow, individual tools may appear in multiple sub-categories.
+Deciding precisely how to map tools into the security landscape sub-categories
+is future work and will occur after gathering feedback from the community on the
+preferred solution.
 
diff --git a/landscape/cncf.md b/landscape/cncf.md
@@ -1,13 +1,13 @@
-** This is a DRAFT document **
+# How does this release to the CNCF Landscape?
 
-# Adding a “Security Landscape” to the CNCF Landscape
-## Background
-The CNCF Landscape is a valuable resource for companies building cloud-native software. It’s a single place
-with a fairly comprehensive resource map of cloud-native technologies to enable organizations to build, test,
-deploy and scale cloud native applications.
+The [CNCF Landscape](https://landscape.cncf.io/) is a valuable resource for
+companies building cloud-native software. It’s a single place with a fairly
+comprehensive resource map of cloud-native technologies to enable organizations
+to build, test, deploy and scale cloud native applications.
 
-Currently the Landscape is primarily broken into categories that are meant to highlight key phases of the cloud-native
-software development life cycle (SDLC). In particular, it contains the following categories:
+The CNCF Landscape is primarily broken into categories that are meant to
+highlight key phases of the cloud-native software development life cycle (SDLC).
+In particular, it contains the following categories:
 
 - App Definition & Development
 - Orchestration & Management
@@ -23,20 +23,24 @@ Among these categories there are few sub-categories with a security focus. Notab
 - Provisioning - Key Management
 - Serverless  - Security
 
-The representation of security-related tools in the CNCF Landscape is not sufficient to serve as a guide on healthy security
-practices to anyone developing cloud-native software. Companies building real-world applications have security considerations at
-each phase of the SDLC, which is not well represented on the current Landscape. We believe it would be beneficial to have
-a resource with clearer suggestions on security considerations at each stage of the SDLC as well as recommendations for
-cloud-native tools that an organization could use to help them practice better security.
-
-In addition, the format of the current landscape focuses on tools that solve a particular area of
-concern (e.g. “source code management” or “container registries”). We believe security is an area of focus that
-requires a different approach. For example, there are many tunables that are exposed at various layers that allow
-organizations to secure their cloud native platform. A good example are Linux Security Modules (LSMs) such as seccomp,
-SELinux, and apparmor that can be used to further secure the container runtime environment. These tunables are often
-abstracted away from the end user by the container runtime or orchestration layers to hide this layer of complexity
-from developers. However, these low level tunables are an important consideration for providing an effective layered
-approach to security. In creating a separate security-focused landscape, we are aiming to more effectively highlight
-the various layers of security considerations, as well as tools that can help companies with fine-tuning their approach
-at each layer.
+Companies building real-world applications have security considerations at each
+phase of the SDLC, which requires a different approach. In evaluating needs for
+cloud-native security, we believe it would be beneficial to have a resource with
+clearer suggestions on security considerations at each stage of the SDLC as well
+as recommendations for cloud-native tools that an organization could use to help
+them practice better security.
+
+Additionally the CNCF Landscape focuses on tools that solve a particular area of
+concern (e.g. “source code management” or “container registries”). Security is a
+cross-cutting concern, requiring a different approach. For example, there are
+many tunables that are exposed at various layers that allow organizations to
+secure their cloud native platform. A good example are Linux Security Modules
+(LSMs) such as seccomp, SELinux, and apparmor that can be used to further secure
+the container runtime environment. These tunables are often abstracted away from
+the end user by the container runtime or orchestration layers to hide this layer
+of complexity from developers. However, these low level tunables are an important
+consideration for providing an effective layered approach to security. In
+creating a separate security-focused landscape, we are aiming to more
+effectively highlight the various layers of security considerations, as well as
+tools that can help companies with fine-tuning their approach at each layer.