Anything that is metadata should conform to the Dublin Core per the XCCDF specification for the .profile files, or it can be a commented out section at the top of the .profile. Alternatively, a single file like maintainers or profile maintainers would be better as a single source of truth.
nitpick: I think that "comes_into_force" should be something else like "when", "applicability", or "profile_enforcement". But this also makes me wonder if tracking this is even necessary as technically in all compliance regimes a newly released profile becomes applicable on release. On Fri, Aug 7, 2020 at 9:21 AM Watson Sato <[email protected]> wrote: > Hello all, > > With the increasing number of products and profiles in > ComplianceAsCode/content, keeping track of the policies, profiles and > people involved has become more complex. > In an effort to better maintain the profiles in the project, I'm looking > for a way to have the following questions easily answered WRT to a profile: > > - Who should be consulted in case of questions about how a profile > aligns (or should be aligned) with the policy? > - Where does one get to know about new policy releases? > - When is a policy version considered out of date? > > > Below is a draft proposal of a set of *optional* metadata to be added to > the ".profile" file. Everything is pretty much free form and optional. > > - policy_hub: (URL pointing to page or organization that publishes the > policy) > - version: (version of the policy implemented) > - comes_into_force: (text stating when a policy starts being enforced, > in other words, when a policy version is in practice obsolete) > - maintainers: (contact of policy SME, stakeholder, or person > responsible for the profile, can be in form of GitHub handle for example) > > Here is an example of how it can look like. (I have used profiles with > known implicit maintainers or SMEs, in CC): > > https://github.com/yuumasato/scap-security-guide/commit/ba967716ef966048357228675a353801017485a9 > > I think these data will bring profile transparency to project maintainers, > and profile maintainers can be kept in the loop with regards to changes in > the profiles they care about. > > Let me know what you think about it, do you have other ideas? > > -- > Watson Sato > Security Technologies | Red Hat, Inc > _______________________________________________ > scap-security-guide mailing list -- > [email protected] > To unsubscribe send an email to > [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/[email protected] >
_______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
