docs/security/ai-generated-security-bugs-faq.md - codesearch/chromium/src - Git at Google

 # AI-generated security bugs FAQ
 Chrome Security Team, April 2026

 AI models are getting increasingly good at finding and exploiting security
 vulnerabilities, and it is vital that we find and fix these bugs sooner than
 attackers can. As such, all Chrome engineering teams are and will be seeing an
 influx of security bugs generated by AI models, both externally submitted (via
 our Vulnerability Rewards Program) as well as internally generated.

 In this document, we respond to frequently asked questions regarding this
 situation.

 Googlers can also refer to the [internal
 version](http://go/chrome-ai-generated-security-bugs-faq) of this FAQ.

 ---

 ## What is the current guidance for remediating security bugs?

 For now, please prioritize remediating:

 * S0 security bugs within 1 week
 * S1 security bugs within 4 weeks

 For more information, please see [go/chrome-slo](http://go/chrome-slo).

 ---

 ## What if I disagree with the severity of my security bug?

 Not all AI-generated security bugs have had their severity confirmed by a member
 of the Chrome Security team. As such, if you have familiarized yourself with
 [Severity Guidelines for Security
 Issues](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/severity-guidelines.md)
 and you believe the severity of your bug is incorrect, please change it to what
 you believe is correct and add a justification comment along with the change.

 ---

 ## Why are some of these reports invalid? How do I get fewer invalid reports?

 You can improve the AI tools' ability to understand your code and discourage it
 from filing invalid bugs.

 Adding a `SECURITY.md` file to your directory that describes your security
 boundaries will be read by the tools and will cause bugs to be filtered out
 based on this. You can refer to examples in the [code
 base](https://source.chromium.org/search?q=f:SECURITY.md&ss=chromium), or even
 get Gemini to help you write one if you explain your security boundaries to it.
 This is documented in
 [security-for-agents](https://chromium.googlesource.com/chromium/src/+/main/docs/security/security-for-agents.md#further-reading),
 and can help weed out attacks you don't consider possible. The Chrome Security
 team can also help if you have any questions about security boundaries.

 Closing invalid bugs is also helpful. We periodically use bugs marked as Working
 as Intended or Not Reproducible as training and evaluation cases for improving
 AI based tooling.

 ---

 ## Why don't the bug reports have a Proof Of Concept (POC)?

 This is actively being worked on – most issues now have POCs attached as a
 follow-up step to the initial report, but you still might see some without a
 full POC.

 Regardless of the POC being there or not, we ask you to initially treat this as
 a full security issue.

 ---

 ## How should we handle bugs behind disabled feature flags?

 Bugs behind disabled feature flags are only launch-blocking. Please add the bug
 to the [Security_Impact-None](https://b.corp.google.com/hotlists/5433277)
 hotlist (hotlistid: 5433277) to disable SLO tracking, or leave a comment if you
 do not have access. Note that features available via an active Origin Trial are
  considered shipped.

 ---

 ## My bug seems like a duplicate, should I close it?

 If you happen to be aware of or have access to existing duplicates, feel free to
 mark AI-generated security bugs as duplicates, or mark other bugs as duplicates
 of them.

 However, don't worry about searching widely for duplicates – unless you have
 security bug access, which is restricted to members of the Chrome Security team,
 existing duplicate bugs filed in other components or areas may not be visible to
 you.

 ---

 ## What if I can't fix the bug because the root cause is in an external dependency?

 If a vulnerability requires an external third party to fix their code, and we
 can't patch around the vulnerability as a temporary fix, mark the bug with the
 [Status_ExternalDependency](https://b.corp.google.com/hotlists/5438152) hotlist
 (hotlistid: 5438152), or leave a comment if you do not have access.

 ---

 ## Do AI-generated security bugs have special requirements around being made public?

 No, we should treat these in the same way and with the same care as
 human-reported vulnerabilities. They will be made public 14 weeks after being
 fixed. It is OK to make a bug public if it's determined that it's not a
 vulnerability (i.e., the report describes a functional bug instead).

 ---

 ## How should I think about fixing vulnerabilities vs the underlying functional bugs that may lead to vulnerabilities?

 For certain types of vulnerabilities, e.g., memory-safety issues, it may be
 desirable to quickly mitigate the security issue without solving all related
 functional issues. For example, if a bug describes hitting a DCHECK (which could
 be triggered by a compromised renderer), a security mitigation fix would be to
 convert that to a CHECK.

 See [go/security-mitigation-explainer](http://go/security-mitigation-explainer)
 for some possible security mitigation fixes. If you land a security mitigation
 fix, you can close a bug. A follow-up bug to fix the underlying logic issue
 could then be filed, but will be lower-priority than addressing other open S0s
 and S1s.

 ---

 ## Can Chrome Security help answer a question about a bug assigned to me?

 We're here to help, but please do not assign the bug to a Chrome Security team
 member or security@chromium.org. Instead, reach out over chat to one of the
 [current shepherds](http://go/current-security-shepherds) or email
 security@chromium.org directly.
	# AI-generated security bugs FAQ
	Chrome Security Team, April 2026

	AI models are getting increasingly good at finding and exploiting security
	vulnerabilities, and it is vital that we find and fix these bugs sooner than
	attackers can. As such, all Chrome engineering teams are and will be seeing an
	influx of security bugs generated by AI models, both externally submitted (via
	our Vulnerability Rewards Program) as well as internally generated.

	In this document, we respond to frequently asked questions regarding this
	situation.

	Googlers can also refer to the [internal
	version](http://go/chrome-ai-generated-security-bugs-faq) of this FAQ.

	---

	## What is the current guidance for remediating security bugs?

	For now, please prioritize remediating:

	* S0 security bugs within 1 week
	* S1 security bugs within 4 weeks

	For more information, please see [go/chrome-slo](http://go/chrome-slo).

	---

	## What if I disagree with the severity of my security bug?

	Not all AI-generated security bugs have had their severity confirmed by a member
	of the Chrome Security team. As such, if you have familiarized yourself with
	[Severity Guidelines for Security
	Issues](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/severity-guidelines.md)
	and you believe the severity of your bug is incorrect, please change it to what
	you believe is correct and add a justification comment along with the change.

	---

	## Why are some of these reports invalid? How do I get fewer invalid reports?

	You can improve the AI tools' ability to understand your code and discourage it
	from filing invalid bugs.

	Adding a `SECURITY.md` file to your directory that describes your security
	boundaries will be read by the tools and will cause bugs to be filtered out
	based on this. You can refer to examples in the [code
	base](https://source.chromium.org/search?q=f:SECURITY.md&ss=chromium), or even
	get Gemini to help you write one if you explain your security boundaries to it.
	This is documented in
	[security-for-agents](https://chromium.googlesource.com/chromium/src/+/main/docs/security/security-for-agents.md#further-reading),
	and can help weed out attacks you don't consider possible. The Chrome Security
	team can also help if you have any questions about security boundaries.

	Closing invalid bugs is also helpful. We periodically use bugs marked as Working
	as Intended or Not Reproducible as training and evaluation cases for improving
	AI based tooling.

	---

	## Why don't the bug reports have a Proof Of Concept (POC)?

	This is actively being worked on – most issues now have POCs attached as a
	follow-up step to the initial report, but you still might see some without a
	full POC.

	Regardless of the POC being there or not, we ask you to initially treat this as
	a full security issue.

	---

	## How should we handle bugs behind disabled feature flags?

	Bugs behind disabled feature flags are only launch-blocking. Please add the bug
	to the [Security_Impact-None](https://b.corp.google.com/hotlists/5433277)
	hotlist (hotlistid: 5433277) to disable SLO tracking, or leave a comment if you
	do not have access. Note that features available via an active Origin Trial are
	considered shipped.

	---

	## My bug seems like a duplicate, should I close it?

	If you happen to be aware of or have access to existing duplicates, feel free to
	mark AI-generated security bugs as duplicates, or mark other bugs as duplicates
	of them.

	However, don't worry about searching widely for duplicates – unless you have
	security bug access, which is restricted to members of the Chrome Security team,
	existing duplicate bugs filed in other components or areas may not be visible to
	you.

	---

	## What if I can't fix the bug because the root cause is in an external dependency?

	If a vulnerability requires an external third party to fix their code, and we
	can't patch around the vulnerability as a temporary fix, mark the bug with the
	[Status_ExternalDependency](https://b.corp.google.com/hotlists/5438152) hotlist
	(hotlistid: 5438152), or leave a comment if you do not have access.

	---

	## Do AI-generated security bugs have special requirements around being made public?

	No, we should treat these in the same way and with the same care as
	human-reported vulnerabilities. They will be made public 14 weeks after being
	fixed. It is OK to make a bug public if it's determined that it's not a
	vulnerability (i.e., the report describes a functional bug instead).

	---

	## How should I think about fixing vulnerabilities vs the underlying functional bugs that may lead to vulnerabilities?

	For certain types of vulnerabilities, e.g., memory-safety issues, it may be
	desirable to quickly mitigate the security issue without solving all related
	functional issues. For example, if a bug describes hitting a DCHECK (which could
	be triggered by a compromised renderer), a security mitigation fix would be to
	convert that to a CHECK.

	See [go/security-mitigation-explainer](http://go/security-mitigation-explainer)
	for some possible security mitigation fixes. If you land a security mitigation
	fix, you can close a bug. A follow-up bug to fix the underlying logic issue
	could then be filed, but will be lower-priority than addressing other open S0s
	and S1s.

	---

	## Can Chrome Security help answer a question about a bug assigned to me?

	We're here to help, but please do not assign the bug to a Chrome Security team
	member or security@chromium.org. Instead, reach out over chat to one of the
	[current shepherds](http://go/current-security-shepherds) or email
	security@chromium.org directly.