{"meta":{"title":"Ausführen einer Sicherheitskampagne zum Beheben von Warnungen im großen Maßstab","intro":"Starten Sie eine fokussierte Sicherheitskampagne, um eine bestimmte Klasse von Sicherheitswarnungen wie websiteübergreifendes Skripting (XSS) in Ihrer Organisation zu beheben.","product":"Sicherheit und Codequalität","breadcrumbs":[{"href":"/de/code-security","title":"Sicherheit und Codequalität"},{"href":"/de/code-security/tutorials","title":"Anleitungen"},{"href":"/de/code-security/tutorials/secure-your-organization","title":"Sichern Sie Ihre Organisation"},{"href":"/de/code-security/tutorials/secure-your-organization/best-practice-fix-alerts-at-scale","title":"Beheben von Warnungen in Staffelung"}],"documentType":"article"},"body":"# Ausführen einer Sicherheitskampagne zum Beheben von Warnungen im großen Maßstab\n\nStarten Sie eine fokussierte Sicherheitskampagne, um eine bestimmte Klasse von Sicherheitswarnungen wie websiteübergreifendes Skripting (XSS) in Ihrer Organisation zu beheben.\n\n<!-- TRANSLATION_FALLBACK prop=markdown type=ParseError line=23 col=1 msg=\"tag {% ifversion security-campaigns-autofix %} not closed\" -->\n## Launching your first campaign\n\nIn this tutorial, you’ll plan and run your first organization-wide security campaign focused on XSS alerts. Along the way, you’ll learn how to select the right alerts, prepare developers for success, and structure a campaign that drives meaningful improvements in your security posture.\n\nImagine you’ve identified a recurring pattern of XSS vulnerabilities in several repositories. Rather than addressing alerts one by one, you decide to run a coordinated campaign that reduces risk while helping developers build confidence in secure coding.\n\n## 1. Define a focused goal\n\nWhen running a campaign at scale, it’s tempting to target all urgent alerts at once. If your developers already have a strong foundation in secure coding and available capacity, that may work.\n\nHowever, if your goal is to both reduce risk and improve secure coding practices, a focused campaign is often more effective. Choosing a single vulnerability type, such as cross-site scripting, allows developers to recognize patterns, apply learning across multiple fixes, and build momentum.\n\nFor this campaign, you decide to focus on XSS alerts across your organization, within the limits of how many alerts a single campaign can include.\n\n## 2. Select alerts for your campaign\n\nOn the security alerts page, start by filtering for cross-site scripting alerts. You can also use a predefined campaign template, such as **Cross-site scripting (CWE-79)**, to quickly define the scope. For information on filtering alerts, see [Filtering alerts in security overview](/en/code-security/how-tos/manage-security-alerts/remediate-alerts-at-scale/filtering-alerts-in-security-overview).\n\n> \\[!NOTE]\n> Security campaigns can include up to 1000 alerts. If your organization has more than 1000 XSS alerts, narrow your filters (for example, by repository, severity, or language) until the number of matching alerts is within this limit, or plan multiple campaigns to cover the remaining alerts.\n\nIf Copilot Autofix is available for your campaign, you can further refine the scope by using the `autofix:supported` filter. This allows developers to take advantage of AI-generated fix suggestions to remediate alerts more efficiently.\n\nBefore launching the campaign, you also prepare supporting educational materials. For example:\n\n* Create a repository with guidance on preventing XSS vulnerabilities.\n* Link to resources from the OWASP Foundation, such as [Cross Site Scripting (XSS)](https://owasp.org/www-community/attacks/xss/).\n* Provide examples of secure coding patterns and testing approaches.\n\nYou’ll include links to these resources in the campaign description so developers can reference them as they work through their assigned alerts.\n\n## 3. Assign campaign managers and define communication channels\n\nBefore launching the campaign, decide who will support developers throughout the remediation process.\n\nWhen you create a security campaign, you must assign one or more **campaign managers**. Campaign managers must be:\n\n* A user with the organization owner role or the security manager role, or\n* A member of a team with one of those roles\n\nChoose managers who can:\n\n* Answer questions about XSS vulnerabilities\n* Review pull requests for fixes\n* Help resolve edge cases or complex remediation scenarios\n\nBecause campaign managers are visible to developers participating in the campaign, this is also an opportunity to establish clear communication. When creating the campaign, include a contact link, such as a link to a GitHub Discussions thread or another communication channel, so developers know where to ask questions.\n\nBy setting expectations early and making support visible, you increase trust and improve remediation rates.\n\n## 4. Create and publish the campaign\n\nNow you’re ready to create the campaign.\n\nWhen defining the campaign:\n\n* Use your XSS filter or template to select the alerts.\n* Add a clear description explaining the goal of the campaign.\n* Include links to the educational resources you prepared earlier.\n* Set a realistic due date based on the number of alerts and expected remediation capacity.\n\nIf you’re unsure about the scope, create a **draft campaign** first. A draft allows you to review the alerts that will be included and collaborate internally before publishing.\n\n## 5. Enable issue tracking to increase visibility\n\nTo help developers track their work and provide visibility to managers, you can choose to automatically create an issue in each repository included in the campaign. This allows developers to manage their remediation work within their existing workflows and project boards.\n\nWhen you enable issue creation, the campaign’s \"Short description\", \"Contact link\", and due date are automatically included in the issue body. If you update the short description, contact link, or due date, those changes are reflected in the issues. Additionally, when the campaign reaches its due date or is closed, a comment is posted on each issue to notify developers. This integration helps maintain clear communication and keeps the campaign organized across multiple repositories.\n\n## 6. Support developers during remediation\n\nOnce the campaign is live, your role shifts from organizer to enabler. Developers will begin reviewing and fixing XSS alerts in their repositories. To help them move efficiently and confidently:\n\n* Ensure campaign managers are available to review pull requests and answer questions.\n* Encourage developers to use Copilot Chat to better understand why code is vulnerable and how to validate their fixes.\n* Where supported, encourage developers to review and test Copilot Autofix suggestions before merging changes.\n\nIf you prepared educational resources earlier, reference them in discussions and pull request reviews. Reinforcing shared guidance reduces repeated questions and helps build long-term secure coding habits.\n\nBy staying visible and responsive during the campaign, you reinforce that this is a collaborative effort, not just a compliance exercise.\n\n## 7. Set a realistic deadline\n\nYou set a due date when creating the campaign. As the campaign progresses, ensure that timeline remains achievable.\n\nWhen setting or adjusting the deadline, consider:\n\n* The number of alerts included in the campaign\n* The expected remediation capacity of developers (for example, how much time they can dedicate to fixing alerts alongside their regular work)\n* Any upcoming company deadlines or holidays that may impact availability\n\nUnless alert remediation is a dedicated initiative, most developers will be balancing this work alongside feature development. Setting a realistic timeline increases participation and prevents discouragement.\n\nIf needed, you can run multiple focused campaigns over time rather than attempting to address all alert types at once.\n\n## 8. Close the campaign and iterate\n\nAs the deadline approaches, monitor progress and collaborate on any remaining complex fixes.\n\nWhen the campaign is closed:\n\n* Repository issues are updated automatically.\n* Developers have resolved a focused set of vulnerabilities.\n* Your organization has reduced risk in a measurable way.\n\nMost importantly, developers have gained practical experience recognizing and fixing a specific class of vulnerability.\n\nFrom here, you can repeat the process with another targeted set of alerts, such as SQL injection, insecure deserialization, or exposed secrets, to steadily improve your organization’s security posture over time.\n\n## Next steps\n\nReady to launch your campaign? To create and manage your security campaign, see [Creating and managing security campaigns](/en/code-security/securing-your-organization/fixing-security-alerts-at-scale/creating-managing-security-campaigns)."}