Test our python scripts with multilevel profiles

[aaronlippold]

Given that organizations make dependant profiles that take the raw STIG or CIS benchmark and make a dependant profile, our parsing solutions must be 'smart' and know how this constitution works.

You can use https://github.com/mitre/inspecjs as a guide and the https://github.com/mitre/inspecjs/tree/master/parse_testbed as well which has both double and triple-level overlay examples in it.

[aaronlippold]

https://github.com/mitre/heimdall2/tree/master/apps/frontend/src/assets/samples

[tohch4]

Ha, I see you beat me to it, @aaronlippold. Nice!

[aaronlippold]

Not that I mind the python, we just put a lot of work into the Typescript/Javascript API to ensure it absolutely works with any level of complexity in HDF data, mapping, our Passed, Failed, NA, Manual, Profile Error, etc data types etc. If we are going to write a python library. I would like to make sure we keep feature parity between the libraries.

[tohch4]

Totally makes sense to me. Are you going to be on the call tonight? If so, two things:

1. I will admit my ignorance on the multi-level profile scenario, but will try to read up before tonight's meeting, but will likely have questions.
2. If we are talking a library level of functionality and not just some utility scripts, let's discuss how we match expectations on "any level of complexity in HDF data, mapping, our Passed, Failed, NA, Manual, Profile Error, etc data types etc" as different libraries in different langs. It is a pleasant learning experience for me to understand the models better.

Re 2, Having reviewed InspecJS last night quickly, @aaronlippold , can I presume from what I read you all are generating the JS/TS classes from the JSON Schemas direct? Perhaps it is time I give that a hand in OSCAL as well to try and see if the mapping approach will work.

FYI, @gregelin re 2 from your end, this is exactly how compliance-trestle is doing it on the Python side for OSCAL and JSON, but not without many headaches and setbacks from following the repo, so maybe this is not a concern for now, but a viable approach for the medium-to-long term?

I bring this up in both these examples because you all have a good notion of your model and maybe the OSCAL model tool, but we have to rebuild the model of OSCAL out of band multiple times for different languages as util libraries and to go beyond basic util scripts, I think we will ought to think about reducing the lead-up time there. :-)

[aaronlippold]

https://github.com/mitre/inspecjs/tree/master/schemas

[tohch4]

Did some reading after the call tonight and it is making a little more sense, comparing a basic profile and that side by side helped.

[aaronlippold]

See I did think it through :P

On Wed, Jan 27, 2021 at 8:55 PM Alexander Stein ***@***.***> wrote: Did some reading after the call tonight and it is making a little more sense, comparing a basic profile and that side by side helped. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALK42DDPC5LKFS656NPX2TS4C7ZDANCNFSM4WURKETA> .

-- -------- Aaron Lippold [email protected] 260-255-4779 twitter/aim/yahoo,etc. 'aaronlippold'