Best practices for fixing security alerts at scale

Elements of a successful security campaign

Successful security campaigns to fix alerts at scale have many features in common, including:

• Selecting a related group of security alerts for remediation.
• Making sure that the manager for the campaign is available for collaboration, reviews, and questions about fixes.
• Providing access to educational information about the type of alerts included in the campaign.
• Making GitHub Copilot Chat available for developers to use to learn about the vulnerabilities highlighted by the security alerts in the campaign.
• Defining a realistic deadline for campaign, bearing in mind the number of alerts you aim to fix.
• Publicizing the collaboration to developer teams and identifying the best way to engage them for your organization.

For information about the developer experience, see "Fixing alerts in a security campaign."

Selecting security alerts for remediation

Your first thought may be to identify all the most urgent alerts and create a security campaign to fix them. If your developers already have a good understanding of secure coding and are keen to remediate potential vulnerabilities, this could be a successful approach for your company. However, if you need to build up knowledge of secure coding and common vulnerabilities, you will benefit from a more stategic approach.

For example, if you have many alerts for cross-site scripting vulnerabilities, you could:

• Create educational content for developers in a repository using resources from the OWASP Foundation, see Cross Site Scripting (XSS).
• Create a campaign to remediate all alerts for this vulnerability, including a link to the educational content in the campaign description.
• Hold a training session or other event to highlight this opportunity to gain confidence in secure coding while fixing real bugs.
• Make sure that the security team member assigned to manage the campaign is available to review the pull requests created to fix the campaign alerts, collaborating as needed.

Campaign filter templates

When you select alerts to include in a security campaign, you can use any of the filters on the security alerts page to define a subset of alerts. Alternatively, you can choose a campaign template to use one of the pre-defined filters for common needs, for example: "Cross-site scripting (CWE-79)."

Limitations on security campaigns

The following limitations are intended to encourage you to take a balanced and measured approach to remediating alerts in your code. An iterative approach, addressing a few targeted sets of alerts at a time, is likely to lead to a sustainable and long-term change in security posture.

• A maximum of 10 active security campaigns at a time (no limits on closed campaigns).
• Each campaign can contain up to 1000 alerts spread across up to 100 repositories.

If you choose to create a campaign that exceeds these limits, alerts will be omitted to bring the campaign into line with the limits. Alerts in repositories with recent pushes are prioritized for inclusion in the campaign.

Defining the role of the campaign manager

When you create a security campaign, you must select a "Campaign manager." The campaign manager must have either the organization owner or security manager role.

The name of the campaign manager is visible to developers when they take part in the campaign. If you want to increase the remediation rate for alerts and scale the knowledge of the security team, this is a key opportunity to build collaborative relationships with developers. Ideally, a campaign manager is available to answer questions, collaborate on difficult fixes, and review pull requests for fixes over the whole course of the campaign.

Combining security training with a security campaign

If your security team already provides training for developers on secure coding, creating a campaign with alerts chosen to allow developers to use the skills from the training session is a great way to reinforce their learning. Even if you don't have a formal training program, it makes sense to provide information on the types of security vulnerabilities included in the campaign, examples of how to fix them, and how to test the fixes. This will simplify the role of the campaign manager as they will be able to direct developers to these resources for answers to basic questions.

The OWASP Foundation provides many resources for learning about the most common vulnerabilities and MITRE Corporation maintain a detailed list of common weaknesses, see About the OWASP Foundation and About CWE.

Providing AI support for learning about security vulnerabilities

GitHub Copilot Autofix is automatically triggered to suggest a resolution for each security alert. However, developers will often want more information about why the original code is insecure and how to test that the fix is correct and doesn't break other components.

GitHub Copilot is an important tool for developers who have questions about secure coding, how to fix security alerts, and test their fix. Check that all developers in your organization have access to Copilot in both their IDE and GitHub, see "組織のメンバーに Copilot へのアクセスを付与する."

Considerations in starting a security campaign and defining a deadline

As with any other project, it's important to define realistic timescales to avoid discouraging developers from participating in the security campaign. Unless your company is fixing security alerts as part of a larger campaign to reduce technical debt, most developers will not have time allocated to fixing alerts. You need to estimate remediation rates based on the time developers can find between scheduled tasks. It's also always worth checking on key company deadlines that developers may be working towards and checking national holidays.

Next steps

• "Creating and tracking security campaigns"