Linking evidence to CALM doc
- Dominant language
- JavaScript
- Stars
- 2
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
We have some ongoing POC work with CALM evidence and would like to bring up an issue we are facing with uniquely attaching CALM evidence to control implementations. We are creating a wrapper around evidence that maps some id to the evidence object.
```json
{
"some-unique-id": {
"unique-id": "",
"evidence-paths": [],
"control-configuration-url": ""
}
}
```
This way we can easily identify what control implementation an evidence object is for.
Currently there is no opinion on what the wrapper would look like so for this id we considered a few options:
1. Using the node/relationship unique id to link to the evidence. This was not specific enough as nodes and relationships would have many controls implemented and the same controls could be implemented across multiple relationships.
2. Concatenation of node/relationship unique id, and control label. Same as previous. Many control implementations could be under a control block. We could make this more unique by using the control id of the requirement. This could work although it feels a bit hacky and would break as there is currently no suggestion that control labels would be unique.
3. Concatenation of node/relationship unique id and control id in control config/control requirement. Similar to the above but at least both of the aforementioned have some implicit notion of uniqueness
4. Adding a unique id to the control requirement definition so this can be used in the control config. This could work but would be push the decision to the user to define it in their control config and for we didnt deem this suitable for something that could be a common use case.
Another option would be to have a nested structure that references the path of keys in the document. So for
```json
{
"nodes": [
{
"unique-id": "example-system",
"node-type": "system",
"name": "Example System",
"description": "Example System",
"controls": {
"cbom": {
"description": "Control requirements for delivering patterns",
"requirements": [
{
"control-requirement-url": "http://calm.finos.org/controls/domains-example/security/schema/permitted-connection.json",
"control-config-url": "http://calm.finos.org/controls/domains-example/security/configuration/permitted-connection.json"
}
]
}
}
}
],
}
```
```json
{
"example-system": {
"cbom": {
"security-002": {
"unique-id": "evidence-id",
"evidence-paths": ["some/path/to"],
"control-configuration-url": "url-or-inline-hopefully"
}
}
}
}
```
But then this requires some uniqueness in the pattern options to be enforced
Contributor guide
Research direction
Start by reviewing the CALM control requirement and control configuration structures described in the issue, along with the proposed evidence wrapper examples. Compare the listed identifier and nested-path approaches and determine which uniqueness guarantees the schema can enforce. Done means the project has an agreed linkage model for evidence and a clear definition of its uniqueness rules.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- json
- Domain
- backend-api-design
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100