Security campaigns are now generally available to help address security debt at scale

[tuves]

Security campaigns with Copilot Autofix are now generally available. As part of GitHub Code Security, you can use security campaigns to prioritize and rapidly reduce your backlog of application security debt. Copilot Autofix generates contextual explanations and fixes for historical code scanning alerts in a security campaign, which help developers and security teams collaborate to fix vulnerabilities with speed and confidence.

Starting today, you can also access these new features to plan and manage security campaigns more effectively:

• Draft security campaigns: Security managers can now iterate on the scope of campaigns and save them as draft campaigns before making them available to developers. With draft campaigns, security managers can ensure that the highest priority alerts are included before the work goes live.
• Automated GitHub issues: Security managers can optionally create GitHub issues in repositories that have alerts included in the campaign. These issues are created and automatically updated as the campaign progresses and can be used by teams to track, manage, and discuss campaign-related work.
• Organization-level security campaign statistics: Security managers can now view aggregated statistics showing the progress across all currently-active and past campaigns.

Security campaigns are available for users of GitHub Code Security on GitHub Enterprise Cloud. For more information about security campaigns, see About security campaigns in the GitHub documentation.

To learn more, please check out our blog announcement.

🚀 Interested in learning more about the Code Security Community here at GitHub? Check out our latest community check-in: Behind the Firewall: Checking into the Code Security Community 🤖🪐.

🧠 Looking to up-level your own security knowledge? Take the GitHub Advanced Security certification. We even have a prep course on the community to help you study!

[ImPrithibi]

Thanks for sharing! This update from GitHub is a big step forward in making secure development more manageable at scale.

[vibha-bd]

Hello,

This is a great feature to track remediation for targeted vulnerabilities.

We would like to request for a few features, that would help us get more engagement:

• Export the information on all the alerts that are a part of the campaign. This information will help us provide data on what all repositories are a part of a particular campaign.
• Allow us to filter through severity of the alerts as well. As of today we only have group by with "none" and "repository" options. It would be great to identify what criticality of alerts are a part of the campaign when we create a campaign through a particular CVE and we have data from third party tools reporting different severities.
• Additional characters for "Short Description". It would be good to provide a few steps on remediation as well.

Thank You.

The feature is a great start for proactive tracking!

[jf205]

Hi @vibha-bd

Thanks for the feedback!

• Export the information on all the alerts that are a part of the campaign. This information will help us provide data on what all repositories are a part of a particular campaign.

Interesting! If you were able to export this data where would you show it? I'm asking because we are always considering how we can improve our in-product data to help you understand the impact of campaigns -- maybe there could a way to surface what we need in GitHub?

• Allow us to filter through severity of the alerts as well. As of today we only have group by with "none" and "repository" options. It would be great to identify what criticality of alerts are a part of the campaign when we create a campaign through a particular CVE and we have data from third party tools reporting different severities.

Ack -- we will add this to our feedback about the campaign creation experience!

• Additional characters for "Short Description". It would be good to provide a few steps on remediation as well.

We already support supplying a 'contact link' when creating a campaign. Perhaps you could add your remediation steps to a doc or GitHub issue and provide the link here?

[kgroombr]

Our teams like the new Security Campaigns feature added to github.

Is there any plan to add Dependabot and Secret scanning as well? These would be valuable for our teams.

[jf205]

Hi @kgroombr

We plan to add Dependabot and secret scanning alerts to security campaigns in the future, but we don't have a firm timeline yet.

[OpenSource-For-Freedom]

How can we better enforce exclusions for the GitHub Copilot LLM, similar to how we currently exclude content in the IDE?
Specifically, does the contexts exclusion mechanism—when applied at the enterprise level—also prevent Copilot from accessing those regions during code scanning or Autofix operations?

Based on GitHub’s documentation, it appears exclusions may currently apply only to the Visual Studio IDE. Can we confirm if this limitation applies across all environments?

[jf205]

Hi @OpenSource-For-Freedom

I'm not sure about this. I'll see if I can find out.

[jf205]

Following up: currently the exclusions do not apply to Copilot Autofix.

For my own understanding, could you explain a little more if/why you'd like exclusions to apply here? 🙏🏻

[OpenSource-For-Freedom]

Thanks for circling back—this really hits home from a DevSecOps angle.

My question "Does Copilot Autofix allow Context Exclusions for the Org/enterprise"

---

In our environments, especially in secure environments, we deal with a lot of sensitive stuff—things like environment secrets, cloud access keys, or custom logic meant to control where and how code runs (playbooks).

These aren't just lines of code; they're guardrails, and if they get exposed or altered, it can lead to serious security risks or system downtime... or worse.

---

For example in some CI pipelines we often need access to AWS or other cloud services and other instances using Keys:

# GitHub Actions – Secure deployment setup
env:
  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

Or worse, someone might hardcode a private key (not highly occurring, but it happens... and sometimes gets missed in a pull request):

I know this would be alerted, but the model would "Read" this. Would it also be stored?

# AWS EC2 Key
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAwz0...
-----END RSA PRIVATE KEY-----

Iaas:

in infra as code like TF, we sometimes "gate" deployment logic based on the environment:

resource "aws_instance" "secure_app" {
  ami           = "ami-0abc12345def67890"
  instance_type = "t3.micro"
  key_name      = "dev-key"
  tags = {
    Name        = "SecureAppInstance"
    Environment = "dev"
  }
}

Examples

# Kubernetes Secret (hardcoded – and happens)
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  username: ZGJfdXNlcg==   # base64 encoded 'db_user'
  password: c3VwZXJzZWNyZXQ=  # base64 encoded 'supersecret'

Examples:

# Kubernetes Net-Policy – strict IP allowlist for whitelisted bastion host
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-bastion-ingress
spec:
  podSelector:
    matchLabels:
      role: internal-app
  ingress:
    - from:
        - ipBlock:
            cidr: 203.0.113.7/32  # Bastion host "public IP"
  policyTypes:
    - Ingress

These types of configurations often include sensitive operational data that shouldn’t be modified, removed, or suggested by AI tooling without explicit developer intent. If Copilot or Autofix fails to respect context exclusions, it could accidentally expose keys, rewrite CIDR blocks, or remove critical access controls.

---

In my opinion 🙂

This kind of context-sensitive logic should never be reviewed by an automated system unless explicitly allowed. That’s why tools like Copilot need to respect context exclusions—not just in the IDE, but also in features like Autofix. Which is moving in a great direction!

Ignoring these boundaries opens the door to accidental changes in security-critical areas of code. That’s not just inconvenient—it’s dangerous 😱

Extending context exclusions to Autofix is a necessary step if we’re serious about building secure, reliable pipelines. It helps developers keep sensitive logic intact, reduces risk, and ensures we’re not breaking the trust chain from local dev all the way to production.

[jf205]

OK, thanks for providing more information.

someone might hardcode a private key (not highly occurring, but it happens... and sometimes gets missed in a pull request):

If this is a concern then i highly suggest that you look into adding secret scanning to your workflow -- specifically push protection can prevent secrets like this ever making it into a PR https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning.

In terms of modifying IaC configs, tools like code scanning and Copilot Code Review don't automatically suggest changes to the code unless it is being changed in a PR as intended by a developer.

Hopefully that addresses your concerns. If you have anything else then perhaps you can post another discussion so that we can keep this one focused on Security campaigns!

Thanks for engaging and we appreciated hearing your concerns/feedback!

[ngamboa01]

it would be great if the campaign alert was really visible, it can only be seen in security tab as far as i can tell. This defeats the purpose of trying to drive them to go check security - if they don't happen to go to the security tab they won't see it,

[jf205]

Hi @ngamboa01. Thanks for the feedback - we definitely want to make sure security campaigns are discoverable and engaging for developers!

Currently there are two ways we notify developers about the security campaigns that are happening in their repositories:

• All users with write access to the repo who are also subscribed to watch 'all activity' or 'security alerts' will be sent an email notification -- we are actually lifting some of these restrictions soon, so watch this space!
• Campaign creators can choose to create issues in all repos that are involved in a campaign, so anyone watching new issues will also be notified.

If you have any further feedback about how we can capture developers' attention then I'd be happy to hear it please!