Minimum Project Deliverable

[brandtkeller]

Relating to #35 and #31

Description

Discussion i-progress for merging the outputs of this work into the Security TAG repository.

I'd like to propose defining or aggregating a set of minimum requirements before doing so. Would love feedback on if anyone disagrees.

Proposed Requirements

• Valid OSCAL Catalog model (passes schema validation and optionally model validation with the oscal-cli)
• Uses latest OSCAL version (1.1.2)

Optional Requirements

• Framework for converting between CSV and OSCAL is more universal than this use case

Open Questions

• What deliverables are intended to the Security TAG repository?
  • Typically code does not live with the repo
• What happens to this project after merge into TAG Security?
  • Is there any interest in continuing development?
  • Could this be rolled into another group?

Open to Feedback.

[JonZeolla]

@brandtkeller ultimately I would like to couple OSCAL artifacts with TAG-Security deliverables. I have been working on a way to automate that, and should have something well ahead of KubeCon. Then the artifact I propose we include in the TAG Security repo would be the OSCAL (skipping the interim CSV format we use here).

My focus has been extraction of controls, named entities, and other details from the white papers. Getting from that to OSCAL is (somewhat) straightforward, but getting those details was entirely manual in the past, and aside from its value proving out the concept isn't something I would wish to do again

[brandtkeller]

Sounds valuable and the proposed items would still stand, yes?

Otherwise this issue can capture the intent to mature the current process and produce an artifact for delivery in the TAG Security Repository.

[JonZeolla]

Yup!

[brandtkeller]

Revisiting to document for posterity

Given the above outcomes (merging this work - or the outputs therein - into the STAG repository) - we've discussed a potential strategy that allows for the production of the minimum deliverables with more clear steps for future iterations or reproduction.

1. Acceptance of documenting some process of translating whitepaper to CSV
2. The translation of whitepaper to CSV
3. Tooling that exists in a separate repository for transforming CSV to OSCAL

This would allow CSV and OSCAL artifacts to be merged into the STAG repository with documentation to support how the process can be replicated. Code would exist outside the STAG repository for the CSV to OSCAL transformation with steps for building and replicating the process.

Does that align with your understanding @JonZeolla ?