Support for OSCAL as configuration input

## Overview

NISTs [OSCAL](https://pages.nist.gov/OSCAL/documentation/) is a public standard used for describing controls, implmentations, systems and their assessment. We have done IBM internal POC work to confirgure Auditree from OSCAL files. This is about how to bring that into the open source project.

## Requirements

1. Read standards compliant OSCAL file (model tbc - see below) to configure Auditree.
1. OSCAL input should be stored as evidence for consistency
1. Identifying controls implemented via a fetcher/check should be simple & inkeeping with the spirit of OSCAL
1. OSCAL should not be a requirement for running Auditree, more a nice to have.

You could image a tool that goes the other way (from an Auditree configuration to an OSCAL file). That's interesting, and might help with adoption of OSCAL, but out of scope here.

## Approach

We have a few potential approaches, depending on how & where in the life cycle we want to introduce OSCAL. There may be more than one approach used, depending on circumstance. This issue is to discuss & form a plan to go forward.

### Component definition

Our current POC uses a [component definition](https://pages.nist.gov/OSCAL/documentation/schema/implementation-layer/component/) to turn on/off fetchers/checks. It does this by scanning the file for `control-implementations` where `type` is `monitoring`, and then scanning the properties of the implementation for a `auditree_{fetcher,check}_path`. This is then "grafted" onto the configuration repository to produce a full config.

To facilitate this, running auditree becomes a three step process:

1. We retrieve the component defintion via a fetcher, placing it in the locker
1. We run our configuration script to make the appropriate `controls.json` from the component defintion
1. We run the complete configuration as normal

This has some useful properties:

- it runs as part of normal execution, and is consequently kept current
- combining the configuration in the component defintion with the one from the config repo happens "naturally"
- input OSCAL is stored as evidence
- the fetchers are "constrained" only by their configuration/permissions - e.g. we can "discover" inventory

However, it doesn't help much with configuring the broader Auditree system, for example is says nothing about how often Auditree itself should run (though could if Auditree was defined as a component) nor which Harvest reports are required.

### SSP

I think this would look a lot like the component defintion, with the potential further constraint of a specified inventory.

### Assessment plan

An [assessment plan](https://pages.nist.gov/OSCAL/documentation/schema/assessment-layer/assessment-plan/) would allow for "bigger" configuration - for example configuring the frequency at which Auditree is run, or schedule [Harvest reports](https://github.com/ComplianceAsCode/auditree-harvest) as additional `assets`/`assessment-activities`.

I think the workflow would look like:

1. Run an independent tool to configure Auditree from the assessment plan
- configure tekton/travis/jenkins/circle... pipeline for fetcher/check execution
- configure tekton/travis/jenkins/circle... pipeline for report execution
1. Retrieve the assessment plan & store as evidence (could use [plant](https://github.com/ComplianceAsCode/auditree-plant/) or a simple fetcher.
1. Use the assessment plan to configure the fetchers and checks, as in the component definition POC
1. Run the complete fetcher/check config.
1. Run harvest reports on independent schedule, using plant to place results into the locker.

An assessment plan seems more idiomatic, too.

### Considerations & open questions

- Auditree should be able to run without OSCAL (as now).
- Should this be baked into the framework (additional CLI option, allowing for multiple), be a separate tool, or perhaps both?
- Where should this code reside, framework + tool?
- Configuration repositories are likely more easily managed than OSCAL, so should at least be used as a baseline.
- What configuration, beyond fetchers/checks to run, should come from OSCAL? Does this require standardisation in fetcher/check development, or could it be embedded JSON blobs?

## Security and Privacy

_Provide the impact on security and privacy as it relates to the completion of
this issue. This level of detail may not be available at the time of
issue creation and can be completed at a later time. N/A if not applicable._

Credential management will be a thing, especially in the more complete integration. Obviously creds should not be placed in the OSCAL files, but maybe names/references to them could be (to then be retrieved from Vault or sealed secrets).

## Test Plan

_Provide the test process that will be followed to adequately verify that the
approach above satisfies the requirements provided. This level of detail may
not be available at the time of issue creation and can be completed at a later
time._

- Define some standard OSCAL files that describe known configurations. Confirm that equivalent configurations are generated by the implementation.