On Fri, Jun 5, 2020 at 5:50 PM Gabe Alford <redhatrises(a)gmail.com> wrote:
I would rather welcome some specific ideas or comments on how to
improve the proposed format to get this feature finished soon.
If you would like to work on real policy evaluation, there are projects that we can hook
you up with.
It is intentionally proposed this way to avoid dependencies on other
projects and repositories.
There is a lot more to policy evaluation than what this proposal is
and incorporates more work than the
members of this project have time for. This problem is being worked on in other spaces
and has standards
being developed around them which the proposed format doesn't take into
We were considering OSCAL, but we have received feedback that its
purpose is different from what we do in SCAP Security Guide. To me
personally OSCAL seems overly complex for this purpose. Do you know
any other standard which we should consider?
This is major scope creep to the purpose of this repo which is about security scanning
and remediation of content
and will fundamentally break our downstream users. This project is not positioned to
correctly tackle policy
evaluation and is going to slow down our release and build process even further. This is
also a roadblock to getting
the requests that current customers are demanding completed. There are other higher
priority upstream tasks
that have received no attention in OpenSCAP, SCAP Workbench, etc. repos. Those need to be
dealt with and
We don't want to break any downstream user by this change. What
specific problem can it cause?
What customer requests is it blocking?
Which issues need to be completed first? I think that this is an
On Fri, Jun 5, 2020 at 8:36 AM Jan Cerny <jcerny(a)redhat.com> wrote:
> The policy source data format proposal is available and ready for
> comments. The text has been submitted as a pull request on GitHub to
> make the discussion easier using comments and reviews.
> See https://github.com/ComplianceAsCode/content/pull/5817
> We are looking forward to seeing your feedback on GitHub.
> What is it about? We will use the policy source data format to improve
> development of our profiles. It will allow us to store security
> controls and requirements in the repository and then define profiles
> by using their IDs instead of separate rules.
> This is done in order to solve the problem that there is no easy way
> to demonstrate to profile stakeholders the status of their profile.
> Intended workflow:
> * SME identifies security controls the policy consists of. Those
> controls serve as direct input for our profiles.
> * SME goes through controls, and makes sure that they are sufficiently
> covered by rules.
> * SME fine-tunes the profile by overriding a couple of individual
> rules in the profile file.
> Once the format is accepted we can start developing tools that support
> this new workflow.
> In future, we can also use it for further refactoring, for example
> streamlining the generation of HTML tables.
> Best regards
> Jan Černý
> 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:
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
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
Security Technologies | Red Hat, Inc.