️ GHSA was a "Conversation," not a Database — 2026: Communication Skills Security Professionals Must Learn Anew for Maintainers

“Finding a vulnerability takes 30 minutes; responsibly communicating it takes 30 days.”

— From an anonymous maintainer

What This Article Covers

Current operational status and statistics of GHSA (GitHub Security Advisory) in 2026
Why now is the most challenging period in GHSA history — The era of “AI Slop”
7 essential attitudes security professionals must adopt when reporting to GHSA
Why communication with maintainers determines the quality of security

Introduction — The Realization on the Day I First Submitted a GHSA

When I first reported a GHSA (GitHub Security Advisory), I honestly thought, “If I just organize the vulnerability well, that’s it.” I figured I’d get a CVE number, assign a CVSS score, throw in a patch PR, and the maintainer would handle the rest.

But in reality, it wasn’t like that. When the maintainer’s response was delayed, frustration mounted; if the reported content was misinterpreted, I had to explain it again; and I was refreshing the GHSA comment window daily until the patch was merged.

Suddenly, I realized: GHSA is not a database; it’s a space for human-to-human collaboration. And at this very moment, knowing the reality maintainers face means our attitude as security professionals must completely change.

GHSA’s Present — The Landscape of 2026 in Numbers

First, let’s summarize the scale at which GHSA operates.

Exploding Advisories, Review Pipeline Reaching Its Limit

According to an academic analysis published in early 2026, approximately 288,000 advisories were registered in GHSA from 2019 to 2025, of which only about 23,000 received official review from GitHub. This means that officially reviewed advisories account for only about 8% of the total.

The review paths are also divided into two:

Fast Path: Advisories directly raised by maintainers via GitHub Repository Advisory (GRA). Most initial reviews are fast, and the reviewer is often the maintainer of the repository.
Slow Path: Advisories that flow into GHSA after being first registered in NVD. Review delays are longer, and experienced external reviewers tend to handle them.

What this data tells us is clear: helping maintainers operate GHSA directly is the fastest way.

Decentralization of the Ecosystem — The Emergence of ENISA

There’s another significant change. In November 2025, ENISA was promoted to CVE Program Root, gaining the authority to directly authorize new CNAs within the EU, and the EUVD (EU Vulnerability Database) was launched under the NIS2 directive. EU government CNAs increased by 46%, while US CNAs decreased by 10%.

Furthermore, the EU Cyber Resilience Act will come into effect on September 11, 2026, requiring all manufacturers selling products with digital elements in the EU to report actively exploited vulnerabilities to ENISA within 24 hours.

GHSA is no longer GitHub’s sole stage. It has become one pillar of a multi-layered, international vulnerability ecosystem, and with that, the responsibility of security professionals has also grown heavier.

⚠️ The Most Challenging Period in GHSA History — The “AI Slop” Crisis

This is where the main point begins. Why is communication with maintainers more crucial now than ever?

The Threshold Revealed by the curl Incident

In January 2026, a major incident occurred in the open-source world.

Daniel Stenberg, the founder and lead developer of curl, announced the termination of their bug bounty program, which had been run through HackerOne. Although the program had been operating since 2019, low-quality and invalid reports surged, with many appearing to be AI-generated “slop.”

Before 2025, the ratio of genuine vulnerabilities exceeded 15%; from 2025, it plummeted to less than 5%. This is the collapse of maintainer economics.

Maintainers’ Psychological Limits

There’s an even more shocking statistic: 60% of maintainers have quit or considered quitting, and 44% cited burnout as the reason.

Node.js cited receiving over 30 AI slop reports during major holiday periods as a key reason for strengthening HackerOne Signal requirements. And an Apache httpd maintainer recently lamented in a post, “Two security researchers independently discovered the same vulnerability — this means malicious actors can no longer be kept in the dark, and coordinated disclosure no longer works.”

This landscape can be summarized in one sentence: “Maintainers now approach security reports with suspicion.”

Therefore, the first impression our GHSA report makes now determines its fate.

✅ 7 GHSA Attitudes Security Professionals Must Adopt

So, what should we do? Here are 7 principles for becoming a security professional welcomed by maintainers.

1. Read SECURITY.md First

According to research by GitHub Security Lab, if a project has a security policy (SECURITY.md), simply following its “engagement rules” significantly increases the likelihood of an issue being handled quickly and privately. Security policies are usually found in the root, docs, or .github folders.

Ignoring this and simply opening an issue or throwing a PoC on Twitter instantly reduces trust to zero.

2. Use Private Advisory (GRA) from the Start

Public issues or PRs make a project a target for N-day vulnerability exploitation. Attackers often target the short window between a patch being merged and the advisory being publicly disclosed.

GHSA’s most powerful feature is draft advisory + temporary private fork. This allows you to work with maintainers to create a patch in a private environment. Security professionals should be adept at guiding this workflow.

3. Verify to Avoid “AI Slop”

There’s a lesson to be learned from the case that revived cURL. Researcher Joshua Rogers used AI tools like ZeroPath to analyze the cURL codebase, but only submitted results after filtering them with his own expertise. This contributed to over 100 bug fixes that had survived years of fuzzing and static analysis.

This doesn’t mean don’t use AI. It means end AI-generated suspicion with human verification.

4. Attach a Minimal, Reproducible PoC

A good report includes the following four things:

Exact affected version range
Minimal reproduction code or command (within 5 lines)
Expected impact and threat model
Environment information (OS, runtime, dependency versions)

A PoC that a maintainer can reproduce in their environment within 5 minutes is 100 times more valuable than a lengthy explanation.

5. Propose a Patch or Mitigation

Maintainers highly welcome reporters who act like contributors. Insights from a security research background often lead to more robust remediation.

If possible, upload a patch candidate as a PR to a private fork. This is the best way to save maintainers more than half their time.

6. Entrust Embargo and Disclosure Timing to the Maintainer

Coordinated disclosure is the practice where reporters and vendors collaborate to privately resolve vulnerabilities before public disclosure. Disclosure only occurs after a fix or mitigation is in place.

While there are general guidelines like the 90-day rule, respecting the maintainer’s resource situation is paramount. 90 days can be short for voluntary, unpaid maintainers.

7. Stay Involved Until the End

It doesn’t end when the GHSA is published and a CVE is issued. Follow-up questions, backports for downstream distributions (Debian, Ubuntu, Alpine, etc.), correcting incorrect scope of impact — a security professional’s responsibility continues even after the advisory is public. A good maintainer relationship becomes a trust asset for the next report.

In Practice — A Good GHSA Report Template

Below is an example template organized so that maintainers can grasp the essence of the matter within 30 seconds.

## Summary
[한 문장으로 취약점의 종류와 영향]
예: Path traversal in `extractFile()` allows arbitrary file write outside target directory.

## Affected Versions
- 영향: < 1.4.3
- 확인된 fix: 1.4.4 (제안 패치 첨부)

## CVSS 4.0 (제안)
Vector: AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N
Score: 9.3 (Critical) — 메인테이너 검토 부탁드립니다.

## Reproduction
1. `npm install <pkg>@1.4.2`
2. 다음 코드 실행:

const x = require(‘‘);

x.extractFile(‘../../../etc/passwd’, ‘/tmp/out’);

3. /etc/passwd 가 /tmp/out 으로 복사됨

## Suggested Fix
- private fork PR #1 에 patch 첨부
- 핵심: path normalization 후 target dir 내부 검증 추가

## Threat Model
- 공격자: 신뢰할 수 없는 archive 입력을 처리하는 환경
- 전제: 외부 입력이 extractFile()에 전달되어야 함

## Disclosure
- 메인테이너 일정에 맞춰 진행 가능
- AI 도구(ZeroPath) 사용 후 수동 검증 완료

A report with this level of care sends a signal to the maintainer: “I want to work with this person.”

⚠️ Common Pitfalls

Do not unilaterally dictate CVSS scores. Maintainers know the actual threat model better. Treat it as a subject for discussion.
Do not overuse the word “critical.” This is a common characteristic of AI slop reports.
Never upload PoCs to public issues. A single mistake can lead to an N-day.
Do not interpret maintainers’ silence as disregard. They have primary jobs, and GHSA is usually unpaid volunteer work.
Do not obsess over credit. True security professionals are judged by results, not by name.

✅ Summary — GHSA is Not a Database, but an Infrastructure of Trust

In 2026, GHSA is not just a CVE repository. It is a vast network of trust where 1.4 million open-source maintainers and tens of thousands of security researchers meet.

As we enter the AI era, this network faces its biggest test. Will we exhaust maintainers with slop reports, or will we build trust through diligent collaboration? This choice will ultimately determine the security of our entire open-source ecosystem.

The true skill of a security professional is no longer measured by “how many CVEs they’ve received,” but by “how many maintainers want to work with them again.”

The next time you write a GHSA, please remember that a sleepless maintainer sits on the other side of the screen. That person is our colleague.

️ GHSA was a “Conversation,” not a Database — 2026: Communication Skills Security Professionals Must Learn Anew for Maintainers