Your second sentence is close to the normal good sequence: report privately → coordinate → fix or mitigate → publish an actionable advisory.

The useful distinction is not simply public versus quiet. CERT/CC frames coordinated vulnerability disclosure as repeatedly asking: who needs to know what, and when? Public disclosure after coordination does four things:

1. users outside a vendor's direct-contact list learn whether their version is affected and what to do;
2. downstream wallets and integrators can coordinate their own response;
3. independent reviewers can check the vendor's claims and the fix; and
4. a public record prevents an unresolved issue from remaining quiet indefinitely.

A silent patch is not necessarily secret anyway: CERT/CC notes that a repository commit or binary diff can expose what was fixed before users receive an advisory.

Immediate full technical disclosure can be harmful when no remedy exists and exploit detail increases attacker advantage. A useful advisory instead leads with affected versions, impact, fixed version or mitigation, and a timeline; exploit-granular detail can wait while the remediation gap is open.

So: broadcasting only 'this project is vulnerable' is weak. Coordinated publication that helps exposed users deploy a fix is the point.

CERT/CC overview: https://certcc.github.io/CERT-Guide-to-CVD/tutorials/cvd_in_a_nutshell/
CERT/CC publication phase: https://certcc.github.io/CERT-Guide-to-CVD/topics/phases/publishing/