Security vulnerabilities often require more discussion than what can be captured in the public details of a security advisory.

A security team may need to record internal investigation notes, discuss whether a vulnerability affects a particular application, coordinate remediation, or document why a specific action was taken. Putting that information into a public advisory can expose internal details that should not be shared with everyone.

GitHub provides security advisory workflows for managing vulnerabilities, and private comments give teams a way to discuss security issues without exposing those conversations publicly.

This is particularly useful for organizations where developers, security engineers, maintainers, and incident-response teams need to collaborate around the same vulnerability.

In this article, we will look at private comments in security advisories, why they matter, how teams can use them during vulnerability management, and the practices that make internal security discussions safer and easier to manage.

What Is a GitHub Security Advisory?

A security advisory is used to document a vulnerability affecting a project or package.

Depending on the advisory and repository configuration, security information can include:

  • Vulnerability description

  • Affected versions

  • Patched versions

  • Severity

  • CVE information

  • Vulnerability classification

  • References

  • Remediation information

For open-source projects, some advisory information may eventually be visible to the public.

That creates an important distinction between information intended for external consumers and information intended only for the internal security team.

Private comments address the second category.

Why Private Security Discussions Matter

Imagine that a security team discovers a vulnerability in a dependency used by several internal applications.

The team may need to discuss:

Does production use the vulnerable component?
Which applications are affected?
Who owns those applications?
Has the vulnerable code path been enabled?
Can we deploy the patched version immediately?
Does the vulnerability require additional mitigation?

These questions may contain internal architecture information.

For example:

The vulnerable library is used by our payment-processing service,
but only the batch-processing component currently calls the affected API.

That information could be useful to the security team but inappropriate for a public security advisory.

Private comments provide a place for this type of internal collaboration.

Public Information vs Private Information

A useful way to think about the difference is:

Information

Public Advisory

Private Discussion

Vulnerability summary

Yes, when appropriate

Yes

Affected versions

Yes

Yes

Patched version

Yes

Yes

Internal architecture

Usually no

Yes

Internal application names

Usually no

Yes

Incident-response notes

No

Yes

Internal remediation status

No

Yes

Security-team discussion

No

Yes

Deployment coordination

No

Yes

The exact visibility depends on the advisory and GitHub permissions, but the general principle is simple:

Public advisory content explains the vulnerability. Private discussion helps the team handle it.

A Typical Security Advisory Workflow

A security team might work through a vulnerability like this:

Vulnerability discovered
          |
          v
Security advisory created
          |
          v
Technical investigation
          |
          v
Affected applications identified
          |
          v
Private team discussion
          |
          v
Fix developed
          |
          v
Patch tested
          |
          v
Advisory updated
          |
          v
Vulnerability disclosed

Private comments are most useful during the investigation and remediation stages.

They give the team a place to coordinate without turning every internal detail into public advisory content.

Example: Coordinating a Dependency Fix

Suppose an application uses:

<ItemGroup>
    <PackageReference Include="Example.Security.Library"
                      Version="4.1.2" />
</ItemGroup>

A security advisory reports a vulnerability affecting the version.

The security team might privately document:

The Orders API and Billing Worker use version 4.1.2.
Orders API can be upgraded immediately.
Billing Worker requires compatibility testing before deployment.

The information helps the team coordinate the fix.

The public advisory, however, may only need to state:

Versions 4.0.x through 4.1.x are affected.
Upgrade to the patched version.

This keeps internal implementation details private while still providing useful information to consumers.

How Private Comments Improve Collaboration

Security issues often involve several teams.

For example:

Security Team
      |
      +---- Development Team
      |
      +---- Platform Team
      |
      +---- Release Team
      |
      +---- Product Owner

Without a central discussion, teams may exchange information through separate chat messages, emails, and documents.

That makes it difficult to reconstruct what happened later.

A private discussion associated with the advisory can provide useful context around:

  • Investigation

  • Decisions

  • Testing

  • Mitigation

  • Deployment

  • Ownership

  • Follow-up work

This can make the security process easier to audit.

What Should Go Into a Private Comment?

Private comments should contain information that helps the team resolve the security issue.

Good examples include:

Impact Assessment

We confirmed that the vulnerable API is used by the
report-generation service. The production deployment
is affected, while the internal admin tool is not.

Remediation Planning

The patched dependency has been tested in staging.
Production deployment is planned after the next release window.

Technical Investigation

The vulnerable code path is only reachable through the
legacy import endpoint. We are keeping the endpoint disabled
while the dependency upgrade is tested.

Ownership

The Platform team owns the affected deployment.
Application changes are being handled by the Payments team.

These comments provide useful context without unnecessarily exposing sensitive information.

What Should Not Go Into Private Comments?

Private does not mean that every kind of sensitive information should be placed there.

Avoid storing:

  • Passwords

  • API keys

  • Access tokens

  • Private encryption keys

  • Database credentials

  • Personal authentication information

  • Secrets copied from production systems

For example, this is a bad idea:

Production API key:
actual-secret-value

A security discussion is not a secret-management system.

If a credential has been exposed, rotate it and store the replacement in the appropriate secret-management system.

Private Comments and Incident Response

Private advisory discussions can also support incident response.

Suppose a vulnerability is discovered in a library used by a production application.

The security team may need to determine whether the vulnerability has already been exploited.

The investigation might involve:

Security advisory
       |
       +--> Dependency inventory
       |
       +--> Application logs
       |
       +--> Deployment history
       |
       +--> Access logs
       |
       +--> Runtime configuration
       |
       v
Impact assessment

The advisory discussion can record the investigation status.

For example:

Initial review completed.

Affected service: Customer API
Production usage: Confirmed
Known exploitation: No evidence found
Mitigation: Endpoint disabled
Fix: Dependency upgrade in testing
Owner: API team

This creates a useful operational record.

However, highly sensitive incident details should still be handled according to the organization's incident-response policy.

Private Comments Are Not a Replacement for Issue Tracking

Teams should avoid turning advisory comments into a complete project-management system.

For example, if a vulnerability requires:

  • Multiple code changes

  • Several deployment tasks

  • Multiple owners

  • A long remediation timeline

a dedicated issue or ticket may be more appropriate.

The advisory discussion can then contain the security-specific context and link the work to the appropriate internal tracking system.

This keeps responsibilities clear.

Common Mistakes

Putting Secrets in Comments

This is one of the biggest mistakes.

Never paste credentials into a security discussion.

Sharing Too Much Internal Architecture

Private comments are intended for authorized users, but access control should still follow the principle of least privilege.

Only include information that is relevant to the security investigation.

Using Comments for Every Task

A security advisory should remain focused on the vulnerability.

Large project-management discussions can make the security record difficult to understand.

Not Recording Decisions

Teams sometimes discuss an issue but fail to record the final decision.

A short summary such as:

Decision: Upgrade dependency to 5.4.2.
Reason: This version contains the required security fix
and passes compatibility tests.

can be valuable later.

Assuming Private Means Permanent

Security information may have retention and compliance requirements.

Teams should follow organizational policies for sensitive security records.

Best Practices for Private Security Discussions

Keep Comments Technical and Actionable

Avoid unnecessary conversation.

A good security comment should help answer:

  • What did we find?

  • What is affected?

  • What are we doing?

  • Who owns the work?

  • What remains?

Record Important Decisions

When the team reaches a decision, summarize it clearly.

For example:

Decision:
Upgrade Example.Security.Library from 4.1.2 to 4.2.0.

Reason:
The patched version resolves the affected vulnerability
without requiring application code changes.

Status:
Testing completed successfully.
Production deployment pending.

Separate Investigation From Remediation

First determine the impact.

Then determine how to fix it.

This avoids making assumptions before the technical investigation is complete.

Avoid Duplicating Secrets

Never copy sensitive credentials into advisory comments just because the discussion is private.

Use the organization's secret-management system.

Limit Access

Security discussions should be visible only to people who need the information.

Access should follow organizational security policies and GitHub permissions.

Advantages

Better Security Collaboration

Developers and security teams can discuss vulnerabilities in one place.

Reduced Public Exposure

Internal details do not need to become part of the public advisory.

Better Investigation History

Important findings and decisions can be recorded alongside the advisory.

Easier Handoffs

A developer joining the investigation later can understand what has already been checked.

Better Remediation Tracking

Teams can document the progress of the security fix without publishing internal operational details.

Disadvantages and Limitations

Comments Can Become Noisy

Too many messages can make an advisory difficult to follow.

Access Still Needs Management

Private information is useful only when access is correctly controlled.

Not a Secret Store

Private comments should never be used to store passwords or credentials.

Not a Complete Incident-Management System

Large security incidents may require dedicated incident-response and ticketing systems.

Poorly Written Notes Can Cause Confusion

Security comments should distinguish confirmed facts from assumptions and open questions.

Troubleshooting Security Advisory Collaboration

If your team is having trouble managing security discussions, start by checking the workflow rather than the tool.

Ask:

  1. Who owns the advisory?

  2. Who needs access to the private discussion?

  3. What information belongs in the advisory?

  4. What information belongs in an internal ticket?

  5. Where should credentials be stored?

  6. How are remediation decisions documented?

  7. How is the final fix verified?

  8. When should public advisory information be updated?

A clear workflow is often more important than the number of features available in the security platform.

Example Security Response Process

A practical process can look like this:

1. Vulnerability identified
        |
        v
2. Advisory created
        |
        v
3. Private impact assessment
        |
        v
4. Affected repositories identified
        |
        v
5. Owners assigned
        |
        v
6. Fix or mitigation selected
        |
        v
7. Patch tested
        |
        v
8. Production deployment
        |
        v
9. Advisory reviewed
        |
        v
10. Remediation closed

This process separates discovery from remediation and makes each stage easier to track.

Production Security Checklist

When using private security discussions, make sure:

  • The advisory has a clear owner.

  • Access is limited appropriately.

  • No passwords or API tokens are stored in comments.

  • Internal application details are shared only when necessary.

  • Technical findings are clearly documented.

  • Important decisions are summarized.

  • Remediation work has an owner.

  • External advisory information is reviewed separately.

  • Incident-response procedures are followed when required.

  • Security records are retained according to organizational policy.

Summary

Private comments for GitHub security advisories give development and security teams a useful place to discuss vulnerabilities without putting internal operational details into public advisory content.

The feature is most valuable during investigation and remediation. Teams can use private discussions to record impact assessments, coordinate fixes, assign ownership, document decisions, and track the progress of a security response.

At the same time, private comments should not become a replacement for a secret-management system, incident-response platform, or general project-management tool. Passwords, API keys, and other credentials should never be copied into security discussions.

The strongest security workflow separates information by purpose: public advisory details explain the vulnerability, private security discussions coordinate the response, and dedicated systems handle secrets, incidents, and long-running remediation work.