Third-party dependency integrity, build-pipeline trust, and artifact provenance — defects ingested from outside the first-party codebase.
The ingested-artifact layer: defects originate from code and configuration AuditBuffet didn't write but runs.
In scope. Known-vulnerable dependency versions (CVE-bearing), abandoned / unmaintained packages, typosquat and dependency-confusion risk, unpinned versions and missing lockfiles, unverified build artifacts, compromised or over-permissioned CI/CD workflows, secrets leakage through build pipelines, SBOM coverage, artifact signing (Sigstore / cosign), source tampering detection, vendored-code provenance.
Not in scope. First-party cryptographic choices — that's cryptography-and-secrets. Deployment configuration of a built artifact — that's operational-readiness. Runtime attacks against a dependency's endpoints — that's access-control or injection-and-input-trust depending on the vector.
Distinct because. The defect sits in artifacts and pipelines rather than first-party application code. A package.json committing a vulnerable lodash version is supply-chain; a src/utils/lodash-wrapper.ts that calls it unsafely is code-quality or security-family. Separated out from operational-readiness because the supply-chain surface is large enough at projected scale (SLSA levels, SBOM mandates, AI-generated package hallucinations) to merit its own lens.
Conceptual sub-structure. Vulnerable deps, CI/CD integrity, artifact provenance, lockfile discipline.