Repository: envoyproxy/gateway

Issue:
Address false positive EG vulnerabilities issue
*Description*:
>Describe the issue.

Fixed CVEs in Envoy Gateway show up as false positives in scanners like trivy because Envoy Gateway does not release off main, but off a release branch.

We have ignored these by explicitly mentioning these in the ignore file https://github.com/envoyproxy/gateway/pull/5665

But this also impacts downstream projects like Envoy AI Gateway.

The current suggestion is to do a dummy release off main to deal with this

More in https://envoyproxy.slack.com/archives/C07Q4N24VAA/p1760544227030199?thread_ts=1760449368.848089&cid=C07Q4N24VAA

[optional *Relevant Links*:]
>Any extra documentation required to understand the issue.


Hints from issue comments:
@arkodg: hey @shahar-h can you help with this ?

cc @zirain @nacx: Probably not a dummy release but more a "marker tag" (and assume tag != release), so that the Go tooling finds a relatively recent tag in `main` that can be used for the dependency version naming in go.mod. Something like, for example, create a `v1.6.0-release-prep` when the 1.6.0 branch is created, and have CI specifically not trigger the release process on those tags, could be a pattern that could fix the issue, as there will always be a relatively recent tag in main.@zirain: we can named it as `v1.6.0-alpha.0`@shahar-h: > we can named it as `v1.6.0-alpha.0`

SGTM - we can auto create the tag(if doesn't exist) in CI. It can be calculated based on latest release tag in VERSION file.@mathetake: alpha feels confusing since which is more prominent between rc and alpha if you look at it. I would suggest rc.0 but not strong opinion@zirain: > alpha feels confusing since which is more prominent between rc and alpha if you look at it. I would suggest rc.0 but not strong opinion

rc is used in the past from the release-* branch, that's why I proposal alpha.@arkodg: thoughts on `vX.Y.Z-rc.0` off main as the first step in release process https://gateway.envoyproxy.io/contributions/releasing/ ?@mathetake: +100@shahar-h:  Wouldn't it be confusing with real "rc" releases(`vX.Y.Z-rc.1`, `vX.Y.Z-rc.2`)? What about `vX.Y.Z-dev`?
@arkodg: `0` in `rc.0` makes it hopefully not a true release candidate (proxy is still linked to `main` making it unstable/non deterministic)
whatever we use here, we need to make sure its lexicographically before vX.Y.Z-rc.1 https://semver.org/#spec-item-11@mathetake: ping just in case to ensure we do this in v1.6 release process.@zhaohuabing: +1 on vX.Y.Z-rc.0@shahar-h: +1 on vX.Y.Z-rc.0@arkodg: thanks folks, hey @shahar-h can you help update the above release note doc to perform this action as the first step
cc @rudrakhp ( release manager for v1.6)@shahar-h: I was thinking about the suggested approach and found a potential issue with it.
Tagging main as `vX.Y.Z-rc.0` before cutting `release/vX.Y` can cause confusion — if a CVE is later found in that release, scanners may still associate it with main, since both share the same version range.

For example, suppose a CVE is found affecting versions < `v1.6.2`. A patch release `v1.6.3` fixes the issue, but `v1.6.0-rc.0` on main is still vulnerable. Consumers relying on main would have to wait until the `v1.7` release to get a version without the vulnerability.

Instead, after branching `release/vX.Y`, we could tag main as `vX.(Y+1).0-rc.0`. This clearly signals that main represents the next development cycle and prevents false CVE associations with the released series.@mathetake: how about: simply cut `vX.NEXTVERSION.0.dev-YYYY-MM-DD` tag from the main branch whenever CVE discovered and fixed? It can be done adhoc and no need to be tied with any release?@shahar-h: > how about: simply cut `vX.NEXTVERSION.0.dev-YYYY-MM-DD` tag from the main branch whenever CVE discovered and fixed? It can be done adhoc and no need to be tied with any release?

No need for that since go will generate a `vX.Y.Z-rc.0.0.<timestamp>-<commit>` pseudo version for each commit after the commit tagged with `vX.Y.Z-rc.0`.

BTW we can automatically create a `vX.Y+1.Z-rc.0` tag from main if it doesn't exist, based on VERSION file content.@mathetake: cool sounds good then can we just cut v1.6.0-rc.0 right now so that we can be sure it resolves the underlying issue? @arkodg @arkodg: sg @shahar-h can you add that into the release notes doc
@shahar-h: > sg [@shahar-h](https://github.com/shahar-h) can you add that into the release notes doc

Sure, please assign me.@rudrakhp: @mathetake fyi [v1.6.0-rc.0](https://github.com/envoyproxy/gateway/releases/tag/v1.6.0-rc.0) is now available@mathetake: TY!

Solution patch:
diff --git a/.github/workflows/release.yaml b/.github/workflows/release.yaml
index 920d40998..65462eecc 100644
--- a/.github/workflows/release.yaml
+++ b/.github/workflows/release.yaml
@@ -8,6 +8,10 @@ on:
     # Sequence of patterns matched against refs/tags
     tags:
       - "v*.*.*"
+      # Exclude rc.0 tags — they’re not real release candidates but markers for main
+      # See: https://github.com/envoyproxy/gateway/issues/7248
+      - "!v*.*.*-rc.0"
+
 
 jobs:
   # For push event, we run benchmark test here because we need to
diff --git a/.trivyignore b/.trivyignore
index a86df8d48..a600ac8c7 100644
--- a/.trivyignore
+++ b/.trivyignore
@@ -1,3 +1,4 @@
 # Following vulnerabilities are false positives because EG does not release from main branch
+# TODO remove this file once v1.6.0-rc.0 tag is available
 CVE-2025-24030
 CVE-2025-25294
diff --git a/site/content/en/contributions/RELEASING.md b/site/content/en/contributions/RELEASING.md
index 1abf37c07..e82b9db86 100644
--- a/site/content/en/contributions/RELEASING.md
+++ b/site/content/en/contributions/RELEASING.md
@@ -42,46 +42,53 @@ export GITHUB_REMOTE=origin
 3. Sign, commit, and push your changes to your fork.
 4. Submit a [Pull Request][] to merge the changes into the `main` branch. 
 5. Do not proceed until your PR has merged and the [Build and Test][] has successfully completed.
-6. Create a new release branch from `main`. The release branch should be named
+6. **Create a new marker tag on `main` for the next minor version.**  
+   This tag serves as a **non-release marker** to indicate the start of the next development cycle.  
+   It is **not a real release candidate** (see [#7248](https://github.com/envoyproxy/gateway/issues/7248) for details).
+   ```shell
+   git tag "v${MAJOR_VERSION}.$((MINOR_VERSION + 1)).0-rc.0"
+   git push origin "v${MAJOR_VERSION}.$((MINOR_VERSION + 1)).0-rc.0"
+   ```
+7. Create a new release branch from `main`. The release branch should be named
    `release/v${MAJOR_VERSION}.${MINOR_VERSION}`, e.g. `release/v0.3`.
 
    ```shell
    git checkout -b release/v${MAJOR_VERSION}.${MINOR_VERSION}
    ```
 
-7. Push the branch to the Envoy Gateway repo.
+8. Push the branch to the Envoy Gateway repo.
 
     ```shell
     git push ${GITHUB_REMOTE} release/v${MAJOR_VERSION}.${MINOR_VERSION}
     ```
 
-8. Create a topic branch for updating the [Envoy proxy image][] and [Envoy Ratelimit image][] to the tag supported by the release.
+9. Create a topic branch for updating the [Envoy proxy image][] and [Envoy Ratelimit image][] to the tag supported by the release.
  Please note that the tags should be updated in both the source code and the Helm chart. Reference [PR #5872][]
    for additional details on updating the image tag.
-9. Sign, commit, and push your changes to your fork.
-10. Submit a [Pull Request][] to merge the changes into the `release/v${MAJOR_VERSION}.${MINOR_VERSION}` branch. 
-11. Do not proceed until your PR has merged into the release branch and the [Build and Test][] has completed for your PR.
-12. Ensure your release branch is up-to-date and tag the head of your release branch with the release candidate number.
+10. Sign, commit, and push your changes to your fork.
+11. Submit a [Pull Request][] to merge the changes into the `release/v${MAJOR_VERSION}.${MINOR_VERSION}` branch. 
+12. Do not proceed until your PR has merged into the release branch and the [Build and Test][] has completed for your PR.
+13. Ensure your release branch is up-to-date and tag the head of your release branch with the release candidate number.
 
     ```shell
     git tag -a v${MAJOR_VERSION}.${MINOR_VERSION}.0-rc.${RELEASE_CANDIDATE_NUMBER} -m 'Envoy Gateway v${MAJOR_VERSION}.${MINOR_VERSION}.0-rc.${RELEASE_CANDIDATE_NUMBER} Release Candidate'
     ```
 
-13. Push the tag to the Envoy Gateway repository.
+14. Push the tag to the Envoy Gateway repository.
 
     ```shell
     git push ${GITHUB_REMOTE} v${MAJOR_VERSION}.${MINOR_VERSION}.0-rc.${RELEASE_CANDIDATE_NUMBER}
     ```
 
-14. This will trigger the [release GitHub action][] that generates the release, release artifacts, etc.
-15. Confirm that the [release workflow][] completed successfully.
-16. Confirm that the Envoy Gateway [image][] with the correct release tag was published to Docker Hub.
-17. Confirm that the [release][] was created.
-18. Note that the [Quickstart][] references are __not__ updated for release candidates. However, test
+15. This will trigger the [release GitHub action][] that generates the release, release artifacts, etc.
+16. Confirm that the [release workflow][] completed successfully.
+17. Confirm that the Envoy Gateway [image][] with the correct release tag was published to Docker Hub.
+18. Confirm that the [release][] was created.
+19. Note that the [Quickstart][] references are __not__ updated for release candidates. However, test
     the quickstart steps using the release candidate by manually updating the links.
-19. [Generate][] the GitHub changelog.
-20. Ensure you check the "This is a pre-release" checkbox when editing the GitHub release.
-21. If you find any bugs in this process, please create an issue.
+20. [Generate][] the GitHub changelog.
+21. Ensure you check the "This is a pre-release" checkbox when editing the GitHub release.
+22. If you find any bugs in this process, please create an issue.
 
 ## Minor Release
 



Test patch:
diff --git a/site/content/en/latest/tasks/traffic/response-override.md b/site/content/en/latest/tasks/traffic/response-override.md
index ea8121bfe..474dba590 100644
--- a/site/content/en/latest/tasks/traffic/response-override.md
+++ b/site/content/en/latest/tasks/traffic/response-override.md
@@ -9,6 +9,10 @@ Response Override allows you to override the response from the backend with a cu
 Follow the steps from the [Quickstart](../../quickstart) to install Envoy Gateway and the example manifest.
 Before proceeding, you should be able to query the example backend using HTTP.
 
+## Prerequisites
+
+{{< boilerplate prerequisites >}}
+
 ## Testing Response Override
 
 {{< tabpane text=true >}}
diff --git a/test/e2e/e2e_test.go b/test/e2e/e2e_test.go
index 8a335262e..0f4d4f076 100644
--- a/test/e2e/e2e_test.go
+++ b/test/e2e/e2e_test.go
@@ -62,15 +62,6 @@ func TestE2E(t *testing.T) {
 		)
 	}
 
-	// TODO: make these tests work in GatewayNamespaceMode
-	if tests.IsGatewayNamespaceMode() {
-		skipTests = append(skipTests,
-			tests.HTTPWasmTest.ShortName,
-			tests.OCIWasmTest.ShortName,
-			tests.ZoneAwareRoutingTest.ShortName,
-		)
-	}
-
 	if tests.XDSNameSchemeV2() {
 		skipTests = append(skipTests,
 			tests.EnvoyPatchPolicyTest.ShortName,
diff --git a/test/e2e/tests/backend_dualstack.go b/test/e2e/tests/backend_dualstack.go
index 4ef87fe50..1c175ff52 100644
--- a/test/e2e/tests/backend_dualstack.go
+++ b/test/e2e/tests/backend_dualstack.go
@@ -4,7 +4,6 @@
 // the root of the repo.
 
 //go:build e2e
-// +build e2e
 
 package tests
 
diff --git a/test/e2e/tests/envoy_patch_policy.go b/test/e2e/tests/envoy_patch_policy.go
index 85b8592e7..1d8affb1b 100644
--- a/test/e2e/tests/envoy_patch_policy.go
+++ b/test/e2e/tests/envoy_patch_policy.go
@@ -47,7 +47,7 @@ func testEnvoyPatchPolicy(t *testing.T, suite *suite.ConformanceTestSuite) {
 		Namespace: ns,
 	}
 
-	// Send a request to an valid path and expect a successful response
+	// Send a request to a valid path and expect a successful response
 	http.MakeRequestAndExpectEventuallyConsistentResponse(t, suite.RoundTripper, suite.TimeoutConfig, gwAddr, OkResp)
 
 	customResp := http.ExpectedResponse{