Formatting

Signed-off-by: Natalie Arellano <narellano@vmware.com>

text/0000-refactor-sbom.md

@@ -43,22 +43,20 @@ Notably, these new specs codify ways of "attaching" arbitrary OCI artifacts to a
 # Motivation
 [motivation]: #motivation
 
-- Why should we do this?
+- Why should we do this? Our current approach has a few drawbacks, namely:
+  * It can make application images quite large
+  * It can be hard to find SBOMs for buildpacks-built images; ecosystem tooling such as `cosign download sbom` won't work (see [PR 278](https://github.com/buildpacks/rfcs/pull/278))
+  * There is no clear way to associate SBOMs for build and run base images with an application image (today this is unspec'd and entirely up to the platform to manage)
 
-Our current approach has a few drawbacks, namely:
-* It can make application images quite large
-* It can be hard to find SBOMs for buildpacks-built images; ecosystem tooling such as `cosign download sbom` won't work (see [PR 278](https://github.com/buildpacks/rfcs/pull/278))
-* There is no clear way to associate SBOMs for build and run base images with an application image (today this is unspec'd and entirely up to the platform to manage)
 
 - What use cases does it support?
+  * TODO
 
-TODO
 
 - What is the expected outcome?
-
-* Smaller application images
-* Integration with ecosystem tooling
-* (Eventually) A more complete SBOM for buildpacks-built images
+  * Smaller application images
+  * Integration with ecosystem tooling
+  * (Eventually) A more complete SBOM for buildpacks-built images
 
 # What it is
 [what-it-is]: #what-it-is