diff --git a/docs/specs/2026-09-08-sbom-per-package-design.md b/docs/specs/2026-09-08-sbom-per-package-design.md
index 3365ec6..95aae47 100644
--- a/docs/specs/2026-09-08-sbom-per-package-design.md
+++ b/docs/specs/2026-09-08-sbom-per-package-design.md
@@ -32,7 +32,7 @@ dependency to add** — it only needs to *invoke* `syft`, which is already avail
 
 The Phase 1 base scan lists every installed `.deb` as a flat `pkg:deb` component. That is
 correct and sufficient for 3rd-party Debian packages, but wrong for Delphix's own
-first-party packages: `masking`, `virtualization`, `delphix-sso-app`, `containerized-masking`,
+first-party packages: `masking`, `virtualization`, `delphix-sso-app`,
 `windows-connector`, `zfs`, `ptools`, `delphix-rust`, and `performance-diagnostics` all
 bundle third-party components
 across ecosystems (jars, npm, wheels, Rust crates) that `dpkg` cannot see — dpkg only knows
@@ -231,14 +231,13 @@ strictly "is it 1st-party" — see the `zfs` case), `SBOM_DEEP_SCAN="true"` is s
 | `masking` | Java/Gradle app bundling jars + npm frontend |
 | `virtualization` | Java/Gradle app bundling jars + npm frontend |
 | `delphix-sso-app` | Java/Gradle app |
-| `containerized-masking` | Java/Gradle app |
 | `windows-connector` | Java/Gradle app |
 | `zfs` | OpenZFS fork bundling Delphix's Rust object agent (crates invisible to dpkg) |
 | `ptools` | Rust |
 | `delphix-rust` | Rust |
 | `performance-diagnostics` | 1st-party Delphix package built from its own source |
 
-The remaining 31 packages (kernel packages, `misc-debs`, `syft`/`cyclonedx-cli` themselves,
+The remaining 32 packages (kernel packages, `misc-debs`, `syft`/`cyclonedx-cli` themselves,
 etc.) get `SBOM_DEEP_SCAN="false"` — plain 3rd-party forks or single-ecosystem tools already
 fully represented by the Phase 1 flat `pkg:deb` component. `delphix-go` is a judgment call:
 the top-level design's Tooling section separately calls out a possible Go override
@@ -246,6 +245,15 @@ the top-level design's Tooling section separately calls out a possible Go overri
 binary-build-info cataloger that may already cover it) — revisit under Phase 4's evaluation
 if gaps are found.
 
+`containerized-masking` was originally in the table above, on the strength of its content (it
+is the masking Java/Gradle app). It was reclassified to `SBOM_DEEP_SCAN="false"` under
+DLPX-99530: it builds no `.deb` — its only artifact is a `masking-kubernetes-<version>.zip` —
+so `generate_sbom()`, which scans `.deb`s and fails when an opted-in package produced none,
+failed every post-push build. It is also in no appliance image, so a per-`.deb` SBOM for it
+would have no image SBOM to be merged into; its third-party content is covered by the Mend
+scans of its container images (`MEND_SCAN_IMAGES`). Every other package left in the `"true"`
+table builds `.deb`s that ship in appliance images.
+
 ### 6. Provisioning syft/cyclonedx-cli — generic build tooling, not a package dependency
 
 `generate_sbom()` is a **default hook**: defined once in `lib/common.sh` and inherited
diff --git a/packages/containerized-masking/config.sh b/packages/containerized-masking/config.sh
index d1cff12..72670a3 100644
--- a/packages/containerized-masking/config.sh
+++ b/packages/containerized-masking/config.sh
@@ -40,7 +40,14 @@ DEFAULT_PACKAGE_GIT_URL="https://github.com/delphix/dms-core-gate.git"
 #
 PACKAGE_NEEDS_DOCKER="true"
 MEND_SCAN_APPLICABLE="true"
-SBOM_DEEP_SCAN="true"
+#
+# Not deep-scanned: generate_sbom() scans this package's .debs, and it builds
+# none -- its only artifact is the masking-kubernetes zip, so opting in fails
+# the build. It is in no appliance image either, so there would be no image
+# SBOM to merge one into. Its third-party content is covered by the Mend scans
+# of MEND_SCAN_IMAGES below.
+#
+SBOM_DEEP_SCAN="false"
 
 MEND_SCAN_IMAGES="'delphix-masking-proxy', 'delphix-masking-database', 'delphix-masking-app'"