Making (sub-sub-)section structured information more visible

[eskultety]

A couple of observations that would have helped me a lot when reading the RC where I accidentally ended up making wrong conclusions initially after the first read.

1. Making structured information more visible
   

   slsa/docs/spec/v1.2-rc1/source-requirements.md

   Lines 622 to 627 in 6ff3cd7

   	Summary: The final revision was reviewed by all relevant experts prior to submission.
   	Intended for: The highest-of-high-security-posture repos.
   	Benefits: Provides the maximum chance for experts to spot and reject problems before they ship.

   
   I think Italic should be used ^^^^here for the optical separation of the structuring elements AND the actual informative contents, IOW this should be consistent with e.g.:
   

   slsa/docs/spec/v1.2-rc1/threats.md

   Lines 239 to 246 in 6ff3cd7

   	<details><summary>Copy a reviewed change to another context<span>(Source L4)</span></summary>
   	*Threat:* Get a change reviewed in one context and then transfer it to a
   	different context.
   	*Mitigation:* Approvals are context-specific.
   	*Example:* MyPackage's source repository requires two-person review. Adversary

2. Making heading level 5 more visible
   

   slsa/docs/spec/v1.2-rc1/source-requirements.md

   Line 684 in 6ff3cd7

   ##### Informed Review

   
   

   slsa/docs/spec/v1.2-rc1/source-requirements.md

   Line 691 in 6ff3cd7

   ##### Use only rebase operations on the protected branch

   
   When you look at how ^these render in https://slsa.dev/spec/v1.2-rc1/source-requirements#mitigations the heading font ends up being smaller and less contrasted than the rest of the content. I know this is a common markdown problem, but in the past I just used plain "bold" and a bit of manual formatting in other projects once I reached level 5 headings. The reason I'm even mentioning ^this is because when I read through the whole source track and got to the Every revision reachable from a branch was approved section, I didn't notice the logical separation under mitigations and instead drew the wrong conclusion that the only way of mitigating this "theoretical-rather-than-practical" attack you're offering (despite mentioning thorough reviews) is by using squash merges which is a practice I find questionable in general and even in context of mitigating the problem at hand vs the practical real life consequences on SW maintenance and so I initially prepared a few paragraphs to disagree AND only after like a 3rd read and having gone to the actual markdown source I noticed the heading separation and so I ended up discarding my whole comment because now that I know this I can read it as either/or, but ultimately your choice, the spec isn't opinionated which I completely agree with, it should be each project's decision how to assess this problem and hence the choice to ensure long term maintainability and sustainability.

[TomHennen]

Ah, this is great feedback. That makes sense to me. Thanks!