Added Controls class as an Element instance variable, moved control b…

[nozmore]

…ased annotations to control class, updated threatlib, enabled json output and updated existing tests.

[nozmore]

I still need some comments on this one. Its still draft but is functional, I think the only thing left is to remove the commented out control annotations on the various Element subclasses.

I had previously started some discussion on Slack but didn't get a thumbs up or down.

I wanted to have some separation between controls. I think there are still room for documentation so this could allow us to focus on documenting element-based annotations ("what the thing is") then focus on the controls. Having them here we can document them once rather than some annotations are on multiple Element subclasses.

I was debating if:

1. we should have a single Controls class or have multiple subclasses.
   I think the single class is good enough for now and we could easily have a follow on PR to separate them out to lock things down or bring clarity. I could see differences between Dataflow vs Server/Process/Lambda. The only place I would see different controls is for a future PR I plan to submit for Data. I want to define Data once then have a DataUsage object on an Element. As an example one Data control would be isValidated instead of validatesInput on an Element. With this change I want to be able to produce a diagram to see how a specific piece of data flows thru the system and where controls are in place, possibly have ties to Classification requirements.

2. are all the attributes pulled out actually meant to be controls, there were some I didn't know what the original intent was and they were not used in the threatlib.

3. likewise is there any controls I missed.

[ghost]

CodeSee Review Map:

Review in an interactive map

View more CodeSee Maps

Legend