Add `supplemental_data` to `saf attest` to support data exchange and provide evidence to the attested claim.

[aaronlippold]

[aaronlippold]

We could either allow the user to provide a specific cci or cci's.

We could also use @ejaronne process for deriving a cci from an 800-53 control.

This may cause use to add a --derive-cci flag if we take option b.

[aaronlippold]

In the use case for CCI specification:

The list of CCIs from the control family level would be too broad given in the end you really need to widdle it down to the specific part of the sub-control family item or area you are really talking about.

If we add the ability to get the cci list at the control family or even enhancement level, then allow the user to sub-select given the title, and the topic this would be very useful given they can 'pick the one or two which are relevant during the attestation process.

[aaronlippold]

So after talking with @cwolf I think we should wrap this in another object called either,

• supporting_data
• supplepmental_data

So that we have a more generalized approach and it doesn't tie it to just a 'CCI' much as we have with passthrough - this data is there to support the 'claim' of the attestation, be that a CCI or link to a file, link to a screenshot, etc.

[aaronlippold]

So we would have:

attestation: {
  stuff...
  supporting_data: {
    cci: [string],
    ref: https://www....
    img: https://link...
  } 
}

[aaronlippold]

This would be an optional - but highly suggested in HDF style - field that would allow us to maintain cross-data support between eMass and HDF data and allow users to be a bit more correct and specific when working at the control family level.

Attesting to AC-3 or IA-4 doesn't really help much - given my next question is what in AC-3 or IA-4 are you saying you covered?