3 replies
@iMichaela Thanks. For the moment the integration is quite light:
- We can import any OSCAL Catalog and use any Control defined in it
- The edition of an OSCAL catalog are quite light for the moment.
We plan to improve the handling of user properties in the next release. @david-waltermire-nist thanks for your support
13 replies
Is this workshop slide deck moved or has it been relocated somewhere?
https://pages.nist.gov/OSCAL/downloads/OSCAL-workshop-20191105.pdf
2 replies
2 replies
Is there a reason we enforce disable-output-escaping as always true and not parameterize it? Is the processing instruction wrapper just to be cautious and inspect the JSON prior to returning it? I notice running the transform on the shell with the command line does not wrap, and I got caught trying to figure this out when converting a catalog programmaticly with eXist-DB and XQuery/XSLT, but not shell. Took me a while to figure this out.
11 replies
22 replies
20 replies
All: I’ve mostly just lurked in this group since departing the FedRAMP PMO and the NIST OSCAL Program at the end of February, and wanted to break that silence to congratulate all of you for achieving OSCAL 1.0.0 this week!
This would not have been possible without contributions from so many of you on this channel.
We would not be here at all if Michaela hadn’t been so tenacious with her vision for OSCAL and convinced NIST to fund it, and then went on to be the champion for it across government, industry, and even across continents.
We would also not be here if not for Dave’s technical vision and leadership - keeping us prioritized and on track - and incorporating lessons learned from similar initiatives.
Wendell’s amazing knowledge of XML and its associated technologies, his ability to churn out robust XSLT, and his decades of insights/experience with similar efforts were also critical to reaching this point.
Others like Andrew, Anil, AJ, Dmitry, and Avril have all contributed significantly to OSCAL’s arrival at this point.
Departing was a difficult decision, so this week is bitter/sweet for me. I’m proud to say I was a part of this community and was able to contribute to this critical milestone.
Many vendors were waiting for 1.0.0 before they invested. Now they can!
I am eager to see all of the positive ways OSCAL will disrupt our industry.
THIS is when everything changes!
Congratulations!
1 reply
1 reply
8 replies
oscal-tools repo that could be useful (to @ohsh6o @mruge @degenero at least) - it contains an XSLT you can use to produce valid 'stub' documents. In my branch (before merging) this is at https://github.com/wendellpiez/oscal-tools/tree/updates-v1.0.0-jun2021/xslt/generate/generate-oscal.xsl
So forgive my ignorance but I am trying to track down documentation and example references that break schema. A previously existing SAP field prop[@name=“updates-uuid’] is referenced in some remarks without a custom @ns tag in docs, but I do not see a lot of explanation about this being supported in OSCAL.
Is this an old, obsolete, and unsupported prop in the OSCAL namespace? I cannot find anything explicitly about updates-uuid in either NIST or FedRAMP docs.
Ok 2nd inquiry: does it stand to reason inside a assessment-subject of a given type that inside it you would exclude-subject or include-subject where it does not match the same type? This seems repetetive but I had not noticed before.
Would you use this to exclude specific others kind of types nested within //assessment-subject[@type=“component”]? Because I am not sure how else you would want them to not match.
24 replies
1 reply
5 replies
4 replies