Increase resolution of mapping applicability

[funnelfiasco]

as I stated in https://github.com/ossf/security-baseline/pull/427/files#r2565105191, when doing these mappings, I'd sort them into COMPLETE (coverage), PARTIAL (Coverage), SUPPORTS (as I feel the case is here), or N/A NONE (does not apply). If any of the 1st three states were triggered as I was doing my review, I'd "map" it. If we want to, we all could go back and refactor all of our mappings to show how strong the connection is to the framework under consideration. I'm unsure how that might complicate things, but if the team is interested in pursuing that, I certainly would be glad to contribute.

Originally posted by @SecurityCRob in https://github.com/ossf/security-baseline/pull/431#discussion_r2565160852

[eddie-knight]

@jpower432 @ossf/gemara Can we add any color to the approach here? I'm thinking "strength"

[jpower432]

@jpower432 @ossf/gemara Can we add any color to the approach here? I'm thinking "strength"

I agree—I think gemara Layer 2 supports this use case through the strength field in the guideline-mappings.

There is some background in https://github.com/ossf/gemara/issues/86, but essentially we decided to implement strength as a 1-10 integer scale to demonstrate the level of coverage. This field is available in the gemara version used by the baseline-compiler (introduced in gemara v0.3.0 I think).

Exploring below how these categories could map to strength:

COMPLETE (10): The control fully satisfies the requirement. PARTIAL / SUPPORTS (1-9): A sliding scale of support (≈). N/A (0): Do not map (or explicitly 0).

guideline-mappings:
  - reference-id: NIST-CSF
    entries:
      - reference-id: PR.DS-1
        strength: 3
  - reference-id: CCM
    entries:
      - reference-id: DCS-04
        strength: 4
      - entry-id: DCS-06
        strength: 2
  - reference-id: ISO-27001
    entries:
      - reference-id: "2013 A.10.1.1"
        strength: 6