We have had increasing requests to scan containers and VM storage images
for compliance. In those use-cases a lot of our rules don't make sense.
For example separate partition for /tmp isn't really applicable to containers.
I thought about how we can deal with this in SSG. We have several options:
1) Separate benchmark and datastreams for containers and VM storage images:
ssg-rhel7-ds.xml and ssg-rhel7-container-ds.xml
2) Separate profile for containers and VM storage images:
pci-dss and pci-dss-container
3) Use applicability and CPE platforms to distinguish between what is being
scanned. That allows us to use the same pci-dss profile for bare-metal, VM,
VM storage image and container image.
Right now I am leaning towards 3) because it "unlocks" the feature
transparently to our users. There is nothing extra they have to study to
start scanning containers. The downside is that we will have to add "fake"
CPE IDs for platforms like "vm-storage" and "container". Rules that apply
to everything will have no <platform> element in them. Rules that apply
to just containers will have something like:
Official NIST CPE ID dictionary has these related CPE IDs
Not sure we want to go with any of those though. I would like to keep it
container and VM tech agnostic.
Before I start hacking this I would like to hear your thoughts.
Identity Management and Platform Security | Red Hat, Inc.
Turns out we never removed the SSG FedoraHosted repo after the migration
Before I blow it away, is there any reason to keep it lingering? Wanted
to double check here before making a irreversible repo deletion. IIRC,
at one point it was mentioned to mirror code there, but I do not believe
that was ever setup (or why it would be a good idea).
-------- Forwarded Message --------
Subject: Fedora 'gitscap-security-guide' sponsor needed for xxxxx
Date: Wed, 10 May 2017 07:04:22 +0000
Fedora user xxxx <xxxx> has requested
membership for xxxx in the gitscap-security-guide group and needs a sponsor.
Please go to https://admin.fedoraproject.org/accounts/group/view/gitscap-security-guide to take action.