Disclosure

Publishing the details of a vulnerability before its fix is available helps attackers more than defenders. Security keeps the details of every finding that is not public inside Coroid, and only someone with the authority decides when they leave.

Public and not public#

Each finding is one of two kinds:

• Public: the vulnerability is already published, for example a dependency with a published advisory. Fix pull requests may name the advisory.
• Not public: everything else, such as an issue the audit, Coroid Review or a code rule found in your own code, or a leaked credential.

A finding is public only when it is linked to a published advisory that has not been withdrawn, or when an owner or admin publishes its private fix (below).

The publication gate#

Everything Coroid publishes outside Coroid passes the publication gate first: review bodies, inline review comments and summaries, check results and their annotations, pull request titles and descriptions, commit messages, issue comments, Slack and email messages, and exports. The gate looks at any security issue in the text, confirmed or not.

On a public repository, or one whose visibility Coroid cannot confirm, an issue that is not public is replaced by a neutral line with a link:

Coroid found a possible security issue; details are in Coroid

On a private repository, the text is published. An issue that is not confirmed yet is marked "Unverified security claim: Coroid has not verified it yet."

Credentials are always redacted, everywhere. See Leaked secrets.

Repository visibility#

Coroid treats a repository as private only when it has a clear, recent reading that it is private, from GitHub's events or from asking GitHub directly, no more than an hour old. An internal repository counts as public. If Coroid cannot tell, it treats the repository as public.

Notifications and exports#

• Bell: for a finding that is not public, the bell names only the severity and the project, for example "A critical finding needs attention", with a link to the finding in Security.
• Slack and email carry only a line saying that a finding needs attention, and the link. They never carry the vulnerability or the code.
• Exports: the CycloneDX export lists vulnerabilities only for public findings. The organization settings bundle carries no findings at all.

Fixing on a public repository#

On a private repository, a fix for a finding that is not public is a normal pull request. Its commit messages and description describe the fix, not the attack.

On a public repository, or one whose visibility Coroid cannot confirm, a public pull request, branch or commit would reveal the issue before it is fixed. So Coroid does not commit such a fix there at all. The fix task stops with a reason that names no detail of the finding, and the prepared change is kept as a private fix.

Private fixes#

A finding with a private fix shows it under Private fixes. Only owners and admins see it.

• Download the fix saves the prepared change as a .patch file, to review or apply yourself.
• Publish records that the finding is now disclosed, and files a task that applies the prepared change unchanged and opens its pull request. Publish when you are ready for the fix and the issue to be public, for example once a coordinated release date is reached. A fix too large to publish from Coroid can still be downloaded and applied by hand.
• Discard deletes the prepared change.

Publishing and discarding are recorded in the organization's audit log, and both delete the prepared change from Coroid.

A private fix that nobody publishes or discards is kept for a limited time. After 180 days, owners and admins are reminded. After 365 days, it is deleted, and they are told.

Planned#

• Security contacts per project, who can review and publish private fixes alongside owners and admins.
• GitHub private forks: preparing a fix in a GitHub repository security advisory's private fork, with its regression test, instead of keeping it in Coroid.
• Reports to maintainers: when a vulnerability is in a dependency's code, drafting a private report for its maintainers, which only a person sends.