Investigate how to best decouple SCB version numbers to have them independent for each M365 product

[ahuynhMITRE]

💡 Summary

What is the work, as a high-level summary?
Currently the SCB version numbers are hard coded into the orchestrator when generating the reports. Going forward each baseline will be versioned independently and incremented as policies are updated with subsequent sprint releases.

Motivation and context

As a direct outcome of the continuous baseline update discussions the teams (CISA, M365 and GWS) have decided that baseline versions will remain independent to their respective SaaS product and increment by "1" if there are updates to any of the policies for a release. All SCB versions are currently at v1.0 and will increment to v2.0 if policies are updated in an upcoming release. If an SCB does not have any policy updates the version will remain v1.0.

Implementation notes

Currently the baseline version numbers are hardcoded as a part of the orchestrator and presented in the report generated by ScubaGear.

• Currently the GWS baselines have their version numbers as a part of the title for each of their SCBs. In an effort to keep both projects consistent the same should be done for M365
• Possibly add this version number into the automation currently done pulling the policy IDs, policies, rationale, etc.
• rework the current hardcoded version number to be independent for each SCB
• related issues: outcomes in the continuous baseline update discussions found in issue Research into naming scheme for unique policy IDs  #876

Acceptance criteria

How do we know when this work is done?

• SCB version number approach has been documented and agreed upon by team

• SCB version numbers added to the title of each of the SCBs

• hardcoded SCB version numbers removed

• each SCB has its own independent version number

[schrolla]

Split out the last three acceptance criteria into a new issue for resolution in future release cycle.