Review Fedora security documents to align with "Vulnerability and Incident Policy" CRA requirement #14
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
As mentioned here council/tickets#559 we (as a community) would like to work together on the CRA and overall Security improvement roadmap for Fedora. We at Red Hat recently released a CRA and Security Playbook largely based on the good and known community practices (e.g, OpenSSF).
One of the items - Cybersecurity, Vulnerability Management and Incident Response Policy. It can be 1 document, it can be series of the documents, but should contain (at minimum) the basic required info.
What we were able to find so far which is relevant to "Security Policy" somehow:
The ask:
Review these (and possibly other related security documents) against these requirements and adjust where needed.
Next step (will create another ticket) will be to adopt security.md file.
The teams that maintain these repositories/Docs are:
Skimming through the points on that stewardship list, I think this is the state of play for Fedora.
This is something we'd need to collaborate with Red Hat to write a process for.
I think the docs you've linked are the closest things we have today. Writing proper policies has been discussed (security/docs#6 & security/docs#7) but no one has actually done it yet.
Not yet but I think https://fedoraproject.org/wiki/Changes/Adopt_PURL_Metadata will make it much easier to adopt SBOMs.
Not something we do today but I'm sure one could be written as part of the policy.
This is the remit of the Join SIG (https://docs.fedoraproject.org/en-US/fedora-join/) who have lots of documentation for new contributors, and operate things like the Mentorship scheme and Outreachy (https://docs.fedoraproject.org/en-US/mentored-projects/).
Individual packages have changelogs in their RPM metadata (
rpm -q --changelog <packagename>). A changelog for the distribution as a whole is maintained on https://fedoraproject.org/wiki/Changes.Needs to be written (security/docs#7).
As of recently, MFA is enforced for
provenpackagers(users who can commit to any repo) fesco/tickets#3618. Discussions are ongoing about applying it to the entire contributor base fesco/tickets#3625.I think most individual components maintained by the Fedora team (e.g. things on https://github.com/fedora-infra) use Branch Protection. dist-git repositories (https://src.fedoraproject.org) does not currently use branch protection. When this has been suggested in the past, concerns have been raised about the overhead it'll add to many single-maintainer packages.
The entire Fedora project is covered by the MIT license (https://docs.fedoraproject.org/en-US/legal/fedora-linux-license/). Some components may also have a
LICENSE.mdin their repos.This one is new to me but I think we already meet a lot of the controls https://baseline.openssf.org/versions/2026-02-19. We'll need a tracker for checking them more precisely.
I'd need to do some closer reading, but I think the way we use Koji as a hosted build platform and do artifact signing (https://docs.fedoraproject.org/en-US/security/cryptography/signatures/) aligns with SLSA Level 2. Maybe Level 3 but I'm not certain from a quick look.
Requirements for this all look pretty doable https://www.bestpractices.dev/en/criteria/0. We should start a separate tracker for collecting answers but I'm happy to blitz through most of them.
Individual contributors may decide to sign their commits, but enforcing it is blocked behind forge/forge#446
Thanks for the comprehensive analysis! I created this issue to have closer look into the policy docs + discuss security.md file adoptions (and use cases when it doesn't make sense, for instance). But @thebeanogamer got the full reqs assessment, bravo! I'd suggest let's continue conversation how to approach it all step by step on the next SIG meeting
Is there a security policy for container images produced by Fedora?
Handling of security updates for packages works. But as soon as these packages are published as a container image the policies and best practices do not seem to apply anymore. It is unclear who built an image, images do not get updated, EOL images do not get unpublished.
See https://forge.fedoraproject.org/docs/tickets/issues/19.
@tk2345 wrote in #14 (comment):
There's a broader audit going on there as part of #6. There's a very different toolchain between the base container images and everything else, which we need to try and standardise.
Related #19
I remove the meeting label for now, assuming there is nothing to discuss at this particular ticket at the moment but rather at its split follow-up tickets (?), but feel free to add the label again!
Created security/docs#19 to publish the security.md