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 <wsato(a)redhat.com> 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/ba967716ef9660483...
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 --
scap-security-guide(a)lists.fedorahosted.org
To unsubscribe send an email to
scap-security-guide-leave(a)lists.fedorahosted.org
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/scap-security-guide@lists.fe...