Container image scanning vs software composition analysis: which to choose first
Most teams need both, and the order depends on which unknown is larger: the base image and its operating system packages, or the application's dependency tree. Start with image scanning if your images sit on an older or widely shared base, if one base image serves many services, or if your auditors ask about OS package vulnerabilities. NIST SP 800-190 treats the image as the unit of deployment. Its *Application Container Security Guide* describes images as effectively static archive files that carry every component needed to run the application, so an OS library missing a security update stays vulnerable until the fix goes upstream into the base image and the image is rebuilt and redeployed.
Lead with software composition analysis when the application's own libraries are the larger unknown: deep transitive dependencies, packages pulled in through language package managers, or license and provenance questions. OWASP's Component Analysis guidance lists the risks SCA should cover, including known vulnerabilities, end-of-life components, license conflicts, repository trust such as typosquatting, and inherited risk from transitive dependencies. SCA reads manifests and lock files, so it can report a library that an image scan never surfaces if that package sits outside the layers the scanner inspects. Confirm coverage by ecosystem with each vendor, because support for language package managers varies.
Combine the two when an auditor or customer asks for vulnerability management across both the image and the application. Run image scanning on every built image, include the configuration settings that NIST SP 800-190 says image tools should weigh alongside software vulnerabilities, and run SCA against lock files in the same pipeline. The NIST SSDF practice PW.4.4 asks teams to verify third-party components throughout their life cycles, and building automatic detection of known vulnerabilities into the toolchain is one way to meet it. Before you buy, ask each vendor which OS families, language ecosystems and registries it covers, and what evidence its reports export for an audit.
How the two approaches compare on scope, method and evidence
This table compares what container image scanning and software composition analysis inspect, when they run, what they output and who usually acts on it. Read it as a map of coverage: the two overlap on known vulnerabilities in packaged software, but only image scanning typically reaches the base OS layer and image configuration, while SCA reaches the application's declared and transitive dependencies and license risk.
| Dimension | Container image scanning | Software composition analysis (SCA) |
|---|---|---|
| Primary goal | Find vulnerabilities and risky settings in the built image as it will run, including the base OS layer | Identify risk from third-party and open-source components the application uses, across its lifecycle |
| Scope of inspection | OS packages, base image layers, language runtimes and packages baked into the image | Application manifests, lockfiles, transitive dependencies, and sometimes vendored or bundled code |
| Configuration settings | Per NIST SP 800-190, image tools should also check configuration settings, not only software vulnerabilities | Generally outside scope; confirm with your specific tool whether any configuration checks are offered |
| License risk | Confirm with your tool whether license identification is included and how it reads base image packages | OWASP component risks include license conflicts; confirm which license policies your SCA tool enforces |
| Repository trust and provenance | Confirm whether the tool verifies image signatures or provenance; do not assume it does | OWASP lists typosquatting, provenance and inherited risk; confirm how your tool detects them |
| Pipeline point | Typically after the image build and before registry push or deployment; re-scan registry images on a schedule | Typically at dependency resolution and pull request or build time, with monitoring of already-released builds |
| Output artifacts | Vulnerability findings tied to image digest, layer or package, and configuration findings for the image | Component inventory, vulnerability and license findings per dependency, often with a bill of materials export |
| Usual owner of the output | Platform or infrastructure team that builds and runs the images, with the security team setting policy | Application development team that owns the dependencies, with the security team reviewing exceptions |
| Fix path | Rebuild the image from an updated upstream base and redeploy; NIST SP 800-190 notes fixes are not patched in the field | Upgrade or replace the dependency, pin a patched version, or document an accepted risk |
What image scanning catches that SCA misses, and the reverse
Image scanning and SCA read different inputs. One inspects the built artifact, including the OS layer and configuration, while the other inspects the dependency manifest and lockfiles. The cards below show where each one stops, and the conditions under which those gaps matter for your auditors.
OS packages and base image layers
A scanner that reads the built image sees the operating system packages from the base layer, such as libc or OpenSSL, even though no application manifest lists them. SCA misses these entirely because it reads language dependency files, not the package database inside the image. NIST SP 800-190 notes that images are effectively static archives containing every component, so an outdated base layer must be fixed upstream and redeployed. Check which base image your team pulls, how often it is rebuilt, and whether your scanner reads OS package metadata.
Configuration issues inside the image
Image scanning should also weigh configuration settings, not just package versions, because NIST SP 800-190 says container image tools must consider both. A dependency scanner has no view of settings such as the user the process runs as, exposed ports or embedded credentials. This matters most when auditors test hardening baselines for production workloads. Ask the vendor whether configuration checks run on the image itself or only on the Kubernetes manifests that deploy it.
Application dependencies outside the scanner's view
SCA sees the libraries declared in a manifest or lockfile, and it reports known vulnerabilities for those versions. It misses code vendored into the repository, binaries copied in by hand, and components pulled in at build time without a lockfile. An image scanner sees the final files and may catch some of these, but not always with the right package identity. This gap matters when your application ships vendored code or unpinned build steps. Confirm how each tool identifies components it cannot match to a package manager.
Outdated and end-of-life components
OWASP's component analysis covers outdated and end-of-life components, which are a distinct risk from a known CVE. A component can be unmaintained with no published CVE yet, and neither tool flags that by default. Image scanners often report versions without support status, while SCA may show a release date only when the registry supplies it. This matters for any system that must show vendor support during an audit. Ask for end-of-life data sources and check whether the tool reports support windows.
License conflicts across both layers
License risk appears in the application's libraries and in the packages installed in the base image, and each tool sees a different slice. SCA is usually the stronger tool for license conflicts between declared dependencies, while image scanning may surface licenses for OS packages. This matters when a product is distributed to customers or when an open-source license imposes obligations on shipped binaries. Confirm which license data each tool reads and who signs off on exceptions.
Repository trust and typosquatting
OWASP lists repository trust, including typosquatting and provenance, as a component risk. Neither a standard vulnerability database lookup nor an image scan reliably flags a malicious package that carries no CVE. Provenance checks, such as verifying where a package and base image came from and whether they are pinned by digest, address this gap. This matters most for teams that pull dependencies from public registries without an internal mirror. Ask your tool vendor whether it checks package origin, not only known vulnerabilities.
Where image scanning and SCA overlap, and why duplicate findings are normal
A library baked into a container image can show up in both reports, and that is expected. An image scanner reads the packages it finds inside the image, including OS packages and language libraries copied in at build time. An SCA tool reads the application's declared dependencies, such as a lock file or manifest, and resolves them to components. When the same library appears in both views, the same CVE can be reported twice, often with different package identifiers (a distro package name in one tool, a package URL or ecosystem name in the other), different severity values because each tool may pull scores from different feeds, and different fixed versions because one follows the distro backport and the other follows upstream. Before anyone triages a duplicate, confirm which package identifier format each tool emits and which severity source it uses.
Deduplicate on the component and the image digest, not on the CVE alone. A CVE ID identifies a vulnerability, but it does not identify where the vulnerable code sits. Group findings by component name and version as normalized to a common identifier, then tie each group to the exact image digest being deployed, since a tag can move and a digest cannot. Keep the raw findings from both tools linked to the merged record so an auditor can trace each one back to its source. Ask your vendor or your own pipeline owner to document the normalization rules, because a quote or demo that shows one clean list may have hidden that step.
Record which tool is the system of record for each finding class. Decide in writing that, for example, the image scanner owns OS package findings and base image currency, while SCA owns findings on application dependencies declared in the source repository, and that a finding is closed only when the owning tool confirms it against a rebuilt image. NIST SP 800-190 says image fixes must be made upstream and redeployed rather than patched in the field, so the record should show the rebuilt digest that cleared the finding. This decision also supports NIST SSDF PW.4.4, which asks teams to verify third-party components throughout their life cycles and to build automatic detection of known vulnerabilities into the toolchain. Name the owning tool, the evidence that closes a finding, and the review owner in your procedure before the first audit request arrives.
What drives cost and effort for each approach
Container image scanning and software composition analysis both cost more over time than their license line suggests. The main drivers are how many images and services you run, how often base images are rebuilt, and how much triage and pipeline work sits around the tools. Ask every bidder to price these components separately so you can compare them on the same basis.
Tool licensing or hosting
Commercial scanners usually charge on a metric such as image count, repository count, developers or nodes, and open-source options carry hosting, storage and database costs instead. Confirm the licensing unit, whether it recurs annually, and whether vulnerability feeds or advanced policy features sit in a higher edition. Ask whether the same tool covers both image scanning and dependency analysis, because a split stack means two licenses and two sets of findings to reconcile.
Pipeline integration work
Wiring a scanner into build, registry and deployment steps is usually a one-time task, but it has to be redone when CI runners, registries or base build tooling change. Scanning every build also raises pipeline run time, so the written scope should state which stages gate a release and which only report. Ask who owns the pipeline templates after handover and how fail thresholds are versioned.
Triage of findings
This is the cost most often underestimated. A base image can carry many OS package findings that have no fix or no exposed path, and dependency scans can flag transitive packages that the application never loads. Recurring triage time depends on how the team records suppressions and exceptions with an owner and an expiry date. Ask the vendor or DeployOpen to define the triage workflow, the severity rules and who signs off on accepted risk.
Base image maintenance and rebuild cadence
NIST SP 800-190 notes that container images are static archives, so a fix for a component inside an image means rebuilding the image upstream and redeploying it. The recurring cost is the rebuild schedule, the ownership of the base image and the regression testing that follows each rebuild. Ask how often base images are refreshed, who approves a change to the base, and how redeployment reaches running workloads.
Registry and policy setup
Admission rules, registry signing, tag immutability and policies on which images may run are mostly one-time design work with recurring policy changes. Scanning configuration checks as well as software vulnerabilities, as NIST SP 800-190 recommends, adds rules to maintain. Ask what policy engine is included, which registries it supports, and whether policy exports as code so auditors can review it.
Number of images and services
Cost scales with the number of distinct images, services, languages and environments, not only with the number of applications. Many services built from one shared base multiply a single base-image finding across every consumer. Ask bidders to state their price drivers against your actual image count, the number of registries, and how many environments need separate scan results, and require the quote to name those counts.
Questions buyers ask before hiring help with container and dependency scanning
Do auditors ask for container image scanning, software composition analysis, or both?
It depends on the control mapping your framework uses, so confirm the exact control with your assessor before you scope anything. NIST SP 800-53 Rev. 5 control SA-11, Developer Testing and Evaluation, includes enhancements for static code analysis and dynamic analysis, and SSDF task PW.4.4 asks teams to verify that third-party and open-source components meet their requirements across their life cycles. Image scanning answers a different question: whether the packaged OS layer and runtime components in what you deploy carry known vulnerabilities. NIST SP 800-190 says image tools should weigh both software vulnerabilities and configuration settings. Ask your assessor which evidence they accept for each, such as dated scan output, a triage record, or a documented exception process. If you are an EU financial entity, check how DORA Article 25(1), which lists open source analyses, applies to your supervisor's expectations.
Can our own team run both tools, and what does that take?
Yes, a team with clear pipeline ownership can run both tools, but the work is ongoing rather than a one-time install. Plan for these recurring duties:
- Administering each scanner, its access controls and its vulnerability data updates
- Setting triage rules, including which severities block a build and who approves an exception, with an expiry date on each one
- Someone who can change base images and trigger rebuilds and redeployments
NIST SP 800-190 notes that traditional host tools often cannot see inside containers, so choose tools built for images. Confirm that each scanner covers your language ecosystems and OS families, because coverage varies by product.
How long does a first container and dependency scanning implementation take?
No fixed duration applies across environments, so treat any single number with caution. The main drivers are the number of images and pipelines in scope, the registry and CI platform you use, how many languages and base images you run, whether you already produce an SBOM, and how many existing findings must be triaged before the team agrees a policy. Ask for a phased plan with milestones: an inventory of images and repositories, integration into one pipeline, policy and triage design, then rollout to the remaining pipelines. DeployOpen's engagements are typically fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, so the written scope is what sets the timeline.
What ongoing effort follows once the rebuild cadence is set?
After the cadence is set, most of the effort is triage, rebuilds, tool maintenance and evidence. Expect recurring work in four areas: reviewing new findings on each scan, rebuilding and redeploying images when upstream fixes arrive, refreshing scanner data and policies, and keeping dated records that an assessor can sample. NIST SP 800-190 says fixes belong upstream in the image and must be redeployed. Effort rises with the number of images, the release frequency and the number of teams that ship them. Ongoing support, upgrades and continuous testing are available from DeployOpen as retainers, and the retainer scope should be written down with the same care as the initial engagement.
Does an SBOM replace container image scanning or software composition analysis?
No. An SBOM records what components are present, but it does not by itself decide whether a listed component is vulnerable, out of date or license-restricted. That judgment comes from analysis tools. Image scanning also covers the base OS layer, which a manifest-based SBOM may miss. Where possible, generate the SBOM from the built image so it reflects what you ship. An inventory without analysis covers only half the job. The SBOM vs software composition analysis comparison on this site covers formats and the duties each one supports.
Who fixes findings in base images we do not own?
The upstream image maintainer produces the fix, and your team owns the decision to adopt it, rebuild and redeploy. NIST SP 800-190 says fixes belong upstream in the image and must be redeployed. Practical steps include pinning base images by digest, tracking upstream release notes, setting a rebuild trigger for high-severity fixes, and recording any accepted risk with an owner and a review date. If the upstream image reaches end of life, OWASP's component guidance treats end-of-life components as a risk to plan around, so schedule a move to a maintained base. If a vendor supplies the image, write the rebuild responsibility and response expectations into the contract.
What should we ask for in a quote for this work?
Ask for a written scope that names the images, repositories, pipelines, registries and languages covered, plus the controls the evidence must support. DeployOpen does not publish a price list; a quote follows from the written scope. Ask the provider to separate:
- One-time work, such as integration, policy design and training
- Recurring work, such as a retainer, rebuild support and triage
- Licenses for scanning tools, and who buys them
- Client-side dependencies, such as access, environments and approvals
- Milestones and out-of-scope items, including audit reports, which auditors issue rather than the implementer
Also ask which deliverables you will own at the end, such as pipeline configuration, policy files and runbooks.
How to combine image scanning and SCA in one program
This sequence connects what a team builds to what it ships, so every vulnerability in a container has a known source, an owner and a recorded decision. It gives auditors one trail from the dependency list in source to the image running in production.
Inventory application and base images
The platform team lists every image in use, including the base image each one is built from, its tag or digest, and the repository it is built in. Each application team confirms which base image it inherits and who maintains that base. The output is an image register with an owner for every image and every base. An auditor would ask to see this register and check that each running image maps to a registered build.
Run SCA on declared dependencies in source
Application teams run software composition analysis against lock files and manifests in source control on every merge. The scan covers known vulnerabilities, outdated or end-of-life components, license conflicts, repository trust and transitive dependencies, which is the component risk set OWASP describes. The output is a dependency report per repository. This step is where NIST SSDF PW.4.4 is evidenced, since the check is built into the toolchain.
Scan built images on push and on schedule
After each image build, the pipeline scans the finished image, including its operating system packages and inherited base layers, and checks configuration settings as NIST SP 800-190 recommends. A scheduled scan of images already in the registry picks up newly published vulnerabilities in components that did not change. The output is an image scan record tied to the image digest. Confirm with your scanner vendor whether it scans registry images on a schedule and how it stores results.
Route findings to the owning team
Findings from source and image scans are assigned to the team that controls the fix. Application teams own findings in their own libraries, while findings in OS packages or the base layer go to the base image maintainer, who publishes a patched base for the consumers to rebuild on. The output is a ticket per finding with an owner and a link to the image digest. Auditors often ask how a base image vulnerability reached the right maintainer, so the routing rule should be written down.
Record rebuild fixes and accepted risks
Each finding closes in one of two ways: a rebuild that pulls a patched dependency or base image and redeploys, which NIST SP 800-190 requires because images cannot be patched in the field, or a documented acceptance with a stated reason, an owner and a review date. The output is a findings log that links each closed item to the rebuilt image digest or to the accepted-risk record. Ask your auditor which evidence format they expect for accepted risks before the first assessment.
What compliance frameworks ask for, and what they do not say
The supplied sources do not name image scanning or software composition analysis as a required tool. What they do require is outcome-level: NIST SSDF task PW.4.4 asks organizations to verify that acquired commercial, open-source and other third-party components meet their requirements throughout their life cycles, and gives automatic detection of known vulnerabilities in the toolchain as an example of how to do that. Read literally, that wording fits either an image scanner, an SCA tool, or both, so the choice of tool is yours to defend. Before you commit, confirm with your framework owner or assessor which evidence they accept for third-party component verification, and whether they expect coverage of the base OS layer, the application dependencies, or both.
NIST SP 800-190 is more specific about containers. It says container image vulnerability tools should take both software vulnerabilities and configuration settings into account, and it argues that traditional host-oriented tools often cannot see inside containers. That points to an image scan as the artifact an assessor can sample: a dated report for a named image digest, the scanner and vulnerability database version used, the findings, and the record of which were fixed by rebuilding and redeploying. An SCA report produces a different sample: a dependency manifest or lock file, the analysis run against it, and the triage decisions on each finding. DORA Article 25(1) lists open source analyses among the tests a financial entity may run, so SCA output is a natural fit there, but the article does not say which analysis or how often. Ask your competent authority or assessor to state the exact evidence they will sample, and keep both artifact types tied to the same build identifier so the trail holds together.
How DeployOpen scopes and delivers container and dependency security work
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and runs security testing on those systems. For container image scanning and software composition analysis, we agree the image inventory, the dependency sources and the evidence the client needs in writing before work starts.
How we scope
- Engagements are fixed-scope, with the image list, registries, pipelines and repositories agreed in writing before work starts.
- The written scope names which base images, application images and dependency manifests are in and which are out.
- Scope also records who receives findings, how severity is handled and what evidence the client needs for its own assessors.
How we build
- We configure image scanning and SCA tooling inside the client's own cloud accounts, data centers or air-gapped networks.
- Scanning is wired into build pipelines so that base OS layers, application images and declared dependencies are checked on each build.
- Image configuration settings are reviewed alongside software vulnerabilities, since both affect what a deployed container exposes.
How we hand over
- Deliverables include documented scan configurations, pipeline changes, the component inventory and a remediation procedure the client's team can run.
- Each finding is recorded with the image, layer or dependency it came from, so the owning team can fix it upstream and redeploy.
- Handover covers the evidence set agreed in scope, so the client can confirm controls to its auditors without relying on our word.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can cover rescanning after base image updates, tool version upgrades and periodic review of new findings.
- Any change to scope, such as adding registries or images, is agreed in writing before the work is performed.
