Why does scanning container images not replace SCA on manifests and lockfiles?

## Two inventories, not one Every vulnerability finding starts with an **inventory**: a list of components with versions, which is then matched against advisory data. The tool classes in this area differ far less in their matching step than in *what they were able to inventory in the first place*. That is the whole answer to this question, and it is where weak candidates go wrong — they treat "the scanner found nothing" as a statement about the artifact when it is really a statement about the scanner's input. ## What manifest and lockfile SCA reads This class reads your project's dependency declarations and, ideally, the **resolved** form of them: `package-lock.json`, `yarn.lock`, `poetry.lock`, `go.sum`, `Cargo.lock`, a resolved Maven or Gradle dependency tree. OSV-Scanner is a straightforward example — point it at a lockfile or a directory of them and it reports the packages it resolved, matched against the OSV database. Because it reads the resolution rather than the range, it gets exact versions for **transitive** dependencies, not just the ones you declared. It also knows **scope**: a lockfile records that a package is a development or test dependency, which is how you separate "vulnerable thing that ships" from "vulnerable thing that only ever ran on a build machine". What this class cannot see: anything not expressed in a manifest. The base image's OS packages. A library dropped into the image by a `curl` in the build. A binary you copied in. The manifest describes what your build *intended to resolve*, not what ended up in the artifact. ## What an image scan reads An image scanner works from the built artifact — the layers of an OCI image, or a filesystem. Its strongest signal is the **OS package database** that a distribution maintains inside the image (the dpkg, rpm or apk metadata), which gives it an exact list of installed system packages and versions. On top of that it looks for language-ecosystem artefacts it recognises on disk: jars, site-packages, `node_modules`, and so on. What this class sees that the manifest scan does not: the entire OS layer. A stock distro base can easily carry dozens of packages with open advisories that appear in no manifest anywhere in your repository, because you never declared them — the base image did. What it can miss: dependency **scope** (it has no idea a jar was a test dependency), packages shaded or relocated into a fat artefact, and anything whose on-disk form the analyser does not recognise. ## The two cases that make the point in an interview **A full distro base with a small app.** The image scan reports a long tail of OS-package findings; the manifest scan reports a handful of application libraries. Neither list is a superset of the other. If you only ran the manifest scan, you would report a service as clean while it ships a vulnerable system library. **A distroless or minimal base with a fat jar.** The image scan has almost no OS package database to read and comes back nearly empty. That result is often misread as "the artefact is clean". It is not — it means the base carried few OS packages. The application's own libraries, which are where most of the risk lives in that shape, are exactly what the manifest or SBOM-based inventory enumerates. ## Where the fourth class sits Update bots such as Renovate are a different animal again: they propose version changes based on what is declared in a manifest and what newer versions exist. They are a remediation channel, not an inventory or a detector, and they cover only ecosystems where they can read and rewrite a manifest. ## How to answer Say it as coverage, not as tool preference: manifest and lockfile SCA gives you the resolved application dependency graph with scope; image and filesystem scanning gives you the OS package surface and whatever else physically shipped. A real programme runs both, and the useful question is which inventory a given finding came from — because that tells you whether the fix is a dependency bump, a base-image rebuild, or neither.