Proposal: Switch security reporting to GitHub private vulnerability reporting by bupd · Pull Request #292 · goharbor/community

bupd · 2026-07-08T08:50:57Z

Proposal to replace the CNCF groups.io security mailing list (cncf-harbor-security@lists.cncf.io) with GitHub private vulnerability reporting and repository security advisories as Harbor's vulnerability intake and handling workflow.

Why

The mailing-list process is manual and fragmented: CVE requests are filed out-of-band with MITRE, fix PRs get developed in the public repo before embargo lifts, and email is a hurdle for reporters and maintainers.

Highlights

Every advantage in the proposal is backed by a GitHub Code Security doc reference
Intake, triage, embargoed fix (temporary private fork), CVE assignment (GitHub as CNA), and disclosure become one advisory artifact
Distributor coordination (cncf-harbor-distributors-announce) and disclosure timing are unchanged
CNCF does not mandate the list; Argo CD, in-toto, and Backstage already use GitHub's report form
Trade-offs and open issues are called out (GitHub account requirement, no CI on private forks, OCI/container Dependabot gap, spam triage)

Discussion: Harbor community meeting 8 July 2026

…ty reporting Co-authored-by: Vadim Bauer <vb@container-registry.com> Co-authored-by: Orlin Vasilev <orlin@orlix.org> Co-authored-by: Prasanth Baskar <bupdprasanth@gmail.com> Signed-off-by: Orlin Vasilev <orlin@orlix.org> Signed-off-by: Vadim Bauer <vb@container-registry.com> Signed-off-by: Prasanth Baskar <bupdprasanth@gmail.com>

thcdrt

LGTM

OrlinVasilev

it was about time to improve here! +1

wy65701436 · 2026-07-10T03:46:00Z

@@ -0,0 +1,98 @@
+# Proposal: Switch Security Reporting to GitHub Private Vulnerability Reporting


thanks guys for your proposal, overall, I support this migration!

Just one comment for for Non-GitHub Users, we should establish a clear fallback (like a PGP-encrypted security email) for researchers who cannot or will not use a GitHub account to report.

@Vad1mo @bupd

hmm... Wonder if such cases exist? Since people need to have access to GitHub in the first place to be able to conduct their research and find out about the reporting process in security.md..

My concern with that approach is, if we offer a possibility with minimal resistance, people will use it.
And then we have two processes in parallel, defeating the purpose.

As a compromise, I would suggest the following:
We keep our mailing list and set an autoreply telling people where and how to submit.
Moreover, we monitor the mailing list for complaints about the new process or the case where people cannot use GitHub... If we see something legitimate, we can act case by case.

It's fine to have this limitation, just we should explicitly mention it in the documentation. Not a blocker for me.

chlins · 2026-07-10T05:41:56Z

+
+1. **Governance sign-off** (maintainers / CNCF liaison): agree to the switch and to decommissioning the list; name the org owners / security managers who own the config.
+2. **Enable private reporting** (org owners / security managers): org-level security configuration across public repos, defaulted for new repos.
+3. **Define the workflow** (security team): triage ownership, SLA, labels, per-advisory scoping, CVSS usage, private-fork process, in-band CVE request.


Currently, I don't think Harbor has such a security team.

(security team) --> (maintainer)

chlins · 2026-07-10T05:42:08Z

+2. **Enable private reporting** (org owners / security managers): org-level security configuration across public repos, defaulted for new repos.
+3. **Define the workflow** (security team): triage ownership, SLA, labels, per-advisory scoping, CVSS usage, private-fork process, in-band CVE request.
+4. **Update docs** (maintainers): rewrite `SECURITY.md`; note the GitHub-account requirement and any fallback.
+5. **Pilot** (security team): run one or two reports end-to-end (report → draft → fork → CVE → publish) before cutover.


wy65701436 · 2026-07-10T06:28:05Z

@bupd Im good to go, however, please resolve the above comments.

wy65701436

lgtm

Yanni8 · 2026-07-14T14:56:42Z

love the proposal +1

Implements the reference version of goharbor/community#292 on harbor-next: - SECURITY.md: supported-versions table, concrete response targets (ack 3 business days, triage 7 days, critical fix 14 business days, disclosure within 90 days), reporter expectations (advisory collaboration, CVE, credit), fallback for reporters without a GitHub account, and a known-CVE deflection rule. - docs/security-process.md: maintainer runbook covering intake, triage with CVSS severity ladder, embargoed fix in a temporary private fork, in-band CVE request via GitHub as CNA, coordinated disclosure, release-note conventions, and a per-advisory checklist. - .github/ISSUE_TEMPLATE/bug_report.yml: warning at the top telling reporters not to file security vulnerabilities as public issues. - .github/workflows/codeql.yml: CodeQL scanning for Go and TypeScript (build-mode none, security-extended queries). - .typos.toml: allow the CNA acronym. Signed-off-by: aloui ikram <ikram@container-registry.com>

chlins

lgtm

…ting Replace the cncf-harbor-security mailing list with GitHub private vulnerability reporting as the intake channel for security reports, per goharbor/community#292. Private vulnerability reporting is enabled on the repository. - SECURITY.md: point reporters at the Security tab / Report a vulnerability form; describe the advisory-based triage, CVSS, in-band CVE request, and temporary private fork workflow; keep the mailing list only as a fallback for reporters without a GitHub account and for distributor list membership requests - Add issue template contact link routing vulnerability reports to the private advisory form - Add a security warning to the bug report template Signed-off-by: Vadim Bauer <vb@container-registry.com>

bupd requested review from a team as code owners July 8, 2026 08:50

github-actions Bot assigned OrlinVasilev, stonezdj and zyyw Jul 8, 2026

bupd force-pushed the github-private-vulnerability-reporting branch from b9fc0b0 to 1aedd73 Compare July 8, 2026 08:52

Vad1mo approved these changes Jul 8, 2026

View reviewed changes

bupd force-pushed the github-private-vulnerability-reporting branch 5 times, most recently from 5d7b0f1 to d93490e Compare July 8, 2026 09:06

bupd force-pushed the github-private-vulnerability-reporting branch from d93490e to e740938 Compare July 8, 2026 09:09

thcdrt approved these changes Jul 8, 2026

View reviewed changes

bupd assigned wy65701436 and unassigned zyyw Jul 8, 2026

OrlinVasilev approved these changes Jul 8, 2026

View reviewed changes

wy65701436 reviewed Jul 10, 2026

View reviewed changes

chlins reviewed Jul 10, 2026

View reviewed changes

wy65701436 approved these changes Jul 10, 2026

View reviewed changes

Vad1mo requested changes Jul 10, 2026

View reviewed changes

Comment thread proposals/github-private-vulnerability-reporting.md

Vad1mo approved these changes Jul 10, 2026

View reviewed changes

Vad1mo mentioned this pull request Jul 14, 2026

docs: switch security reporting to GitHub private vulnerability reporting goharbor/harbor#23559

Open

stonezdj approved these changes Jul 16, 2026

View reviewed changes

Aloui-Ikram mentioned this pull request Jul 19, 2026

docs: Adopt GitHub Private Vulnerability Reporting Workflow container-registry/harbor-next#477

Open

chlins approved these changes Jul 21, 2026

View reviewed changes

chlins merged commit e426b1f into goharbor:main Jul 21, 2026
4 checks passed

		@@ -0,0 +1,98 @@
		# Proposal: Switch Security Reporting to GitHub Private Vulnerability Reporting

Uh oh!

Conversation

bupd commented Jul 8, 2026 • edited by Vad1mo Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why

Highlights

Uh oh!

thcdrt left a comment

Choose a reason for hiding this comment

Uh oh!

OrlinVasilev left a comment

Choose a reason for hiding this comment

Uh oh!

wy65701436 Jul 10, 2026

Choose a reason for hiding this comment

Uh oh!

Vad1mo Jul 10, 2026

Choose a reason for hiding this comment

Uh oh!

wy65701436 Jul 10, 2026

Choose a reason for hiding this comment

Uh oh!

chlins Jul 10, 2026

Choose a reason for hiding this comment

Uh oh!

Vad1mo Jul 10, 2026

Choose a reason for hiding this comment

Uh oh!

chlins Jul 10, 2026

Choose a reason for hiding this comment

Uh oh!

wy65701436 commented Jul 10, 2026

Uh oh!

wy65701436 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Yanni8 commented Jul 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chlins left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

bupd commented Jul 8, 2026 •

edited by Vad1mo

Loading

Yanni8 commented Jul 14, 2026 •

edited

Loading