On Sat, Aug 8, 2020 at 12:10 AM Gabe Alford <redhatrises(a)gmail.com> wrote:
Anything that is metadata should conform to the Dublin Core per the
specification for the .profile files, or it can be a commented out section
at the top of the .profile.
I didn't envision this metadata to be included in the built XCCDF profile,
so I didn't look into the formal syntax.
And it is laid out as yaml to ease any eventual build system future
Alternatively, a single file like maintainers or profile maintainers
be better as a single source of truth.
That could work too, in this case I would make the file per product, to
keep them simple.
nitpick: I think that "comes_into_force" should be something else like
"when", "applicability", or "profile_enforcement".
Thank you for the suggestions, I was not sure what would be a good name for
But this also makes me wonder if tracking this is even necessary as
technically in all compliance regimes a newly released profile
applicable on release.
The core of this field is clarity and understanding how the policy is
applied in practice, if it is the case that all policies and profiles are
instantly unusable when a new version is released,
this field is unnecessary.
The proposal for "comes_into_force" assumed that the organizations
implementing and/or enforcing the policy don't update instantly, and have a
time frame to adapt.
On Fri, Aug 7, 2020 at 9:21 AM Watson Sato
>> Hello all,
>> With the increasing number of products and profiles
>> 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
>> 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):
>> I think these data will bring profile transparency to
>> 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
>> Watson Sato
>> Security Technologies | Red Hat, Inc
>> scap-security-guide mailing list --
>> To unsubscribe send an email to
>> Fedora Code of Conduct:
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
> scap-security-guide mailing list --
> To unsubscribe send an email to
> Fedora Code of Conduct:
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
Security Technologies | Red Hat, Inc