diff --git a/.github/workflows/nightly-trivy-scan.yml b/.github/workflows/nightly-trivy-scan.yml
index e979b7be6..f4b2d9694 100644
--- a/.github/workflows/nightly-trivy-scan.yml
+++ b/.github/workflows/nightly-trivy-scan.yml
@@ -11,9 +11,9 @@ jobs:
       fail-fast: false
       matrix:
         # maintain the versions of Velero those need security scan
-        versions: [main, release-1.10-dev, release-1.9-dev]
+        versions: [main]
         # list of images that need scan
-        images: [velero, velero-restore-helper, velero-restic-restore-helper]
+        images: [velero, velero-restore-helper]
     permissions:
       security-events: write  # for github/codeql-action/upload-sarif to upload SARIF results
 
diff --git a/site/content/docs/main/enable-api-group-versions-feature.md b/site/content/docs/main/enable-api-group-versions-feature.md
index 5c40b3e71..20ae9bf66 100644
--- a/site/content/docs/main/enable-api-group-versions-feature.md
+++ b/site/content/docs/main/enable-api-group-versions-feature.md
@@ -17,7 +17,7 @@ For the most up-to-date information on Kubernetes API version compatibility, you
 
 ## How the Enable API Group Versions Feature Works
 
-When the Enable API Group Versions feature is enabled on the source cluster, Velero will not only back up Kubernetes preferred API group versions, but it will also back up all supported versions on the cluster. As an example, consider the resource `horizontalpodautoscalers` which falls under the `autoscaling` group. Without the feature flag enabled, only the preferred API group version for autoscaling, `v1` will be backed up. With the feature enabled, the remaining supported versions, `v2beta1` and `v2beta2` will also be backed up. Once the versions are stored in the backup tarball file, they will be available to be restored on the destination cluster.
+When the Enable API Group Versions feature is enabled on the source cluster, Velero will not only back up Kubernetes preferred API group versions, but it will also back up all supported versions on the cluster. As an example, consider the resource `horizontalpodautoscalers` which falls under the `autoscaling` group. Without the feature flag enabled, only the preferred API group version for autoscaling, `v2` will be backed up. With the feature enabled, the remaining supported versions, `v1` will also be backed up. Once the versions are stored in the backup tarball file, they will be available to be restored on the destination cluster.
 
 When the Enable API Group Versions feature is enabled on the destination cluster, Velero restore will choose the version to restore based on an API group version priority order.