diff --git a/docs/dyn/ondemandscanning_v1.projects.locations.scans.html b/docs/dyn/ondemandscanning_v1.projects.locations.scans.html
index 46a4c663293..9905917dd36 100644
--- a/docs/dyn/ondemandscanning_v1.projects.locations.scans.html
+++ b/docs/dyn/ondemandscanning_v1.projects.locations.scans.html
@@ -100,7 +100,19 @@ <h3>Method Details</h3>
   &quot;packages&quot;: [ # The packages to analyze.
     {
       &quot;architecture&quot;: &quot;A String&quot;, # The architecture of the package.
-      &quot;binaryVersion&quot;: { # The binary package. This is significant when the source is different than the binary itself. Historically if they&#x27;ve differed, we&#x27;ve stored the name of the source and its version in the package/version fields, but we should also store the binary package info, as that&#x27;s what&#x27;s actually installed. See b/175908657#comment15.
+      &quot;binarySourceInfo&quot;: [ # A bundle containing the binary and source information.
+        {
+          &quot;binaryVersion&quot;: { # The binary package. This is significant when the source is different than the binary itself. Historically if they&#x27;ve differed, we&#x27;ve stored the name of the source and its version in the package/version fields, but we should also store the binary package info, as that&#x27;s what&#x27;s actually installed. See b/175908657#comment15.
+            &quot;name&quot;: &quot;A String&quot;,
+            &quot;version&quot;: &quot;A String&quot;,
+          },
+          &quot;sourceVersion&quot;: { # The source package. Similar to the above, this is significant when the source is different than the binary itself. Since the top-level package/version fields are based on an if/else, we need a separate field for both binary and source if we want to know definitively where the data is coming from.
+            &quot;name&quot;: &quot;A String&quot;,
+            &quot;version&quot;: &quot;A String&quot;,
+          },
+        },
+      ],
+      &quot;binaryVersion&quot;: { # DEPRECATED
         &quot;name&quot;: &quot;A String&quot;,
         &quot;version&quot;: &quot;A String&quot;,
       },
@@ -128,7 +140,7 @@ <h3>Method Details</h3>
       &quot;patchedCve&quot;: [ # CVEs that this package is no longer vulnerable to go/drydock-dd-custom-binary-scanning
         &quot;A String&quot;,
       ],
-      &quot;sourceVersion&quot;: { # The source package. Similar to the above, this is significant when the source is different than the binary itself. Since the top-level package/version fields are based on an if/else, we need a separate field for both binary and source if we want to know definitively where the data is coming from.
+      &quot;sourceVersion&quot;: { # DEPRECATED
         &quot;name&quot;: &quot;A String&quot;,
         &quot;version&quot;: &quot;A String&quot;,
       },
diff --git a/docs/dyn/ondemandscanning_v1beta1.projects.locations.scans.html b/docs/dyn/ondemandscanning_v1beta1.projects.locations.scans.html
index f7b281bf62d..406d98547aa 100644
--- a/docs/dyn/ondemandscanning_v1beta1.projects.locations.scans.html
+++ b/docs/dyn/ondemandscanning_v1beta1.projects.locations.scans.html
@@ -99,7 +99,19 @@ <h3>Method Details</h3>
   &quot;packages&quot;: [ # The packages to analyze.
     {
       &quot;architecture&quot;: &quot;A String&quot;, # The architecture of the package.
-      &quot;binaryVersion&quot;: { # The binary package. This is significant when the source is different than the binary itself. Historically if they&#x27;ve differed, we&#x27;ve stored the name of the source and its version in the package/version fields, but we should also store the binary package info, as that&#x27;s what&#x27;s actually installed. See b/175908657#comment15.
+      &quot;binarySourceInfo&quot;: [ # A bundle containing the binary and source information.
+        {
+          &quot;binaryVersion&quot;: { # The binary package. This is significant when the source is different than the binary itself. Historically if they&#x27;ve differed, we&#x27;ve stored the name of the source and its version in the package/version fields, but we should also store the binary package info, as that&#x27;s what&#x27;s actually installed. See b/175908657#comment15.
+            &quot;name&quot;: &quot;A String&quot;,
+            &quot;version&quot;: &quot;A String&quot;,
+          },
+          &quot;sourceVersion&quot;: { # The source package. Similar to the above, this is significant when the source is different than the binary itself. Since the top-level package/version fields are based on an if/else, we need a separate field for both binary and source if we want to know definitively where the data is coming from.
+            &quot;name&quot;: &quot;A String&quot;,
+            &quot;version&quot;: &quot;A String&quot;,
+          },
+        },
+      ],
+      &quot;binaryVersion&quot;: { # DEPRECATED
         &quot;name&quot;: &quot;A String&quot;,
         &quot;version&quot;: &quot;A String&quot;,
       },
@@ -127,7 +139,7 @@ <h3>Method Details</h3>
       &quot;patchedCve&quot;: [ # CVEs that this package is no longer vulnerable to go/drydock-dd-custom-binary-scanning
         &quot;A String&quot;,
       ],
-      &quot;sourceVersion&quot;: { # The source package. Similar to the above, this is significant when the source is different than the binary itself. Since the top-level package/version fields are based on an if/else, we need a separate field for both binary and source if we want to know definitively where the data is coming from.
+      &quot;sourceVersion&quot;: { # DEPRECATED
         &quot;name&quot;: &quot;A String&quot;,
         &quot;version&quot;: &quot;A String&quot;,
       },
diff --git a/googleapiclient/discovery_cache/documents/ondemandscanning.v1.json b/googleapiclient/discovery_cache/documents/ondemandscanning.v1.json
index c5acd690238..b798b3f66ad 100644
--- a/googleapiclient/discovery_cache/documents/ondemandscanning.v1.json
+++ b/googleapiclient/discovery_cache/documents/ondemandscanning.v1.json
@@ -339,7 +339,7 @@
       }
     }
   },
-  "revision": "20230517",
+  "revision": "20230522",
   "rootUrl": "https://ondemandscanning.googleapis.com/",
   "schemas": {
     "AliasContext": {
@@ -506,6 +506,20 @@
       },
       "type": "object"
     },
+    "BinarySourceInfo": {
+      "id": "BinarySourceInfo",
+      "properties": {
+        "binaryVersion": {
+          "$ref": "PackageVersion",
+          "description": "The binary package. This is significant when the source is different than the binary itself. Historically if they've differed, we've stored the name of the source and its version in the package/version fields, but we should also store the binary package info, as that's what's actually installed. See b/175908657#comment15."
+        },
+        "sourceVersion": {
+          "$ref": "PackageVersion",
+          "description": "The source package. Similar to the above, this is significant when the source is different than the binary itself. Since the top-level package/version fields are based on an if/else, we need a separate field for both binary and source if we want to know definitively where the data is coming from."
+        }
+      },
+      "type": "object"
+    },
     "BuildOccurrence": {
       "description": "Details of a build occurrence.",
       "id": "BuildOccurrence",
@@ -1750,9 +1764,16 @@
           "description": "The architecture of the package.",
           "type": "string"
         },
+        "binarySourceInfo": {
+          "description": "A bundle containing the binary and source information.",
+          "items": {
+            "$ref": "BinarySourceInfo"
+          },
+          "type": "array"
+        },
         "binaryVersion": {
           "$ref": "PackageVersion",
-          "description": "The binary package. This is significant when the source is different than the binary itself. Historically if they've differed, we've stored the name of the source and its version in the package/version fields, but we should also store the binary package info, as that's what's actually installed. See b/175908657#comment15."
+          "description": "DEPRECATED"
         },
         "cpeUri": {
           "description": "The cpe_uri in [cpe format] (https://cpe.mitre.org/specification/) in which the vulnerability may manifest. Examples include distro or storage location for vulnerable jar.",
@@ -1823,7 +1844,7 @@
         },
         "sourceVersion": {
           "$ref": "PackageVersion",
-          "description": "The source package. Similar to the above, this is significant when the source is different than the binary itself. Since the top-level package/version fields are based on an if/else, we need a separate field for both binary and source if we want to know definitively where the data is coming from."
+          "description": "DEPRECATED"
         },
         "unused": {
           "type": "string"
diff --git a/googleapiclient/discovery_cache/documents/ondemandscanning.v1beta1.json b/googleapiclient/discovery_cache/documents/ondemandscanning.v1beta1.json
index 2254ea6ab0f..f28d7e79a87 100644
--- a/googleapiclient/discovery_cache/documents/ondemandscanning.v1beta1.json
+++ b/googleapiclient/discovery_cache/documents/ondemandscanning.v1beta1.json
@@ -339,7 +339,7 @@
       }
     }
   },
-  "revision": "20230517",
+  "revision": "20230522",
   "rootUrl": "https://ondemandscanning.googleapis.com/",
   "schemas": {
     "AliasContext": {
@@ -502,6 +502,20 @@
       },
       "type": "object"
     },
+    "BinarySourceInfo": {
+      "id": "BinarySourceInfo",
+      "properties": {
+        "binaryVersion": {
+          "$ref": "PackageVersion",
+          "description": "The binary package. This is significant when the source is different than the binary itself. Historically if they've differed, we've stored the name of the source and its version in the package/version fields, but we should also store the binary package info, as that's what's actually installed. See b/175908657#comment15."
+        },
+        "sourceVersion": {
+          "$ref": "PackageVersion",
+          "description": "The source package. Similar to the above, this is significant when the source is different than the binary itself. Since the top-level package/version fields are based on an if/else, we need a separate field for both binary and source if we want to know definitively where the data is coming from."
+        }
+      },
+      "type": "object"
+    },
     "BuildOccurrence": {
       "description": "Details of a build occurrence.",
       "id": "BuildOccurrence",
@@ -1746,9 +1760,16 @@
           "description": "The architecture of the package.",
           "type": "string"
         },
+        "binarySourceInfo": {
+          "description": "A bundle containing the binary and source information.",
+          "items": {
+            "$ref": "BinarySourceInfo"
+          },
+          "type": "array"
+        },
         "binaryVersion": {
           "$ref": "PackageVersion",
-          "description": "The binary package. This is significant when the source is different than the binary itself. Historically if they've differed, we've stored the name of the source and its version in the package/version fields, but we should also store the binary package info, as that's what's actually installed. See b/175908657#comment15."
+          "description": "DEPRECATED"
         },
         "cpeUri": {
           "description": "The cpe_uri in [cpe format] (https://cpe.mitre.org/specification/) in which the vulnerability may manifest. Examples include distro or storage location for vulnerable jar.",
@@ -1819,7 +1840,7 @@
         },
         "sourceVersion": {
           "$ref": "PackageVersion",
-          "description": "The source package. Similar to the above, this is significant when the source is different than the binary itself. Since the top-level package/version fields are based on an if/else, we need a separate field for both binary and source if we want to know definitively where the data is coming from."
+          "description": "DEPRECATED"
         },
         "unused": {
           "type": "string"