edit based on comments

Signed-off-by: Brandon Lum <lumjjb@gmail.com>

docs/_posts/2022-04-29-slsa-sbom.md

@@ -29,7 +29,7 @@ difficult problems to solve along the way. For example:
     and [Codecov](https://about.codecov.io/security-update/);
 -   There’s no well-established ecosystem to easily distribute and verify SBOM
     documents;
--   The most common method of generating SBOMs using audit tools after the
+-   The most common method of generating SBOMs using only audit tools after the
     software’s creation can result in less accurate SBOMs.
 
 We believe that [SLSA (Supply-chain Levels for Software
@@ -88,7 +88,7 @@ artifact improves the quality and integrity of its SBOM.
 
 ### Accuracy and Completeness
 
-Many current approaches to creating an SBOM rely on guessing or using
+Many tools' current approach to creating an SBOM rely on guessing or using
 heuristics and information from an end product to generate an ingredient list
 after the fact. This approach has drawbacks, though, since if you try to
 generate an SBOM by scanning compiled artifacts, you may miss things like
@@ -134,10 +134,12 @@ open standard for representation of SBOMs. The SPDX SBOM community is currently
 coming together to determine processes for integrity and signing of SBOM data.
 On top of that, it has kicked off its Canonicalization Committee to write a
 specification for a canonical serialization format for SPDX 3.0 data, which
-will be important for specifying how to verify signed documents. **We believe
-that the SBOM community would benefit from drawing on the same tooling and
-practices as used for SLSA provenance:** Sigstore (for OIDC-based ephemeral
-signing and transparency logs) and in-toto (for metadata format). These tools
+will be important for specifying how to verify signed documents. Another SBOM
+standard, [CycloneDX](https://cyclonedx.org/), is also tackling this problem
+with its features around its authenticity, and provenance use cases.  **We
+believe that the SBOM community would benefit from drawing on the same tooling
+and practices as used for SLSA provenance:** Sigstore (for OIDC-based ephemeral
+signing and transparency logs) and in-toto (for metadata format).  These tools
 help to solve the problem of storing and distributing the metadata documents
 that need to accompany artifacts, and would help build the trust that users
 need in SBOMs.