What is the difference between manifest analysis, lockfile analysis, static analysis, and dynamic analysis in SCA?

Manifest analysis identifies declared dependencies, while lockfile analysis pins the exact versions actually installed. Static analysis inspects source code without running it to see how dependency functions are used. Dynamic analysis observes the application at runtime to capture real execution paths. Each method provides a different level of confidence about whether a vulnerability is reachable in practice.

How the four SCA analysis modes differ

These four modes answer different questions about dependency risk. Manifest analysis tells you what a project says it depends on. Lockfile analysis tells you what was actually resolved and pinned at install time. Static analysis looks at source to understand how dependency code is referenced. dynamic analysis looks at execution to see what really runs and whether vulnerable paths are reached.

The practical difference is confidence. Manifest and lockfile methods focus on the dependency set, while static and dynamic methods focus on reachability. That means a vulnerability may exist in the graph but still never execute in the application, or it may be present in a dependency but not installed because the lockfile excluded it.

What each method is good at, and where it misleads

Manifest analysis is broad but approximate. It is useful early in the pipeline because it is fast and tells you the intended dependency surface, but it can overstate exposure when transitive dependencies or version resolution change what actually lands in the build. Lockfile analysis is narrower but more exact, because it captures the resolved package versions and usually gives better reproducibility for audit and remediation decisions.

Static analysis adds code-level context. It can show whether a vulnerable function, class, or package path is actually imported or called, which helps separate theoretical exposure from likely reachability. Its limitation is that it may miss runtime-only behaviour such as feature flags, reflection, environment-driven code paths, or data-dependent branches.

Dynamic analysis is the closest to observed reality because it evaluates the application while it is running. That makes it valuable for confirming real execution paths, but it is bounded by test coverage, runtime configuration, and the specific inputs exercised during analysis. A clean dynamic result does not prove safety, it only shows that the vulnerable path was not observed under the tested conditions.

Risk and Threat Considerations

In SCA, the main risk is treating any single analysis mode as complete. Manifest-only review can overreport exposure, lockfile-only review can miss code that is conditionally loaded, and static or dynamic checks can give false comfort if the relevant path is not exercised. The practical threat is wasted remediation effort on non-reachable issues, alongside missed reachability when a dependency is present but only exploitable in a specific execution path.

Failure mechanism: Gaps emerge when dependency resolution, source usage, and runtime behaviour are evaluated in isolation. An attacker only needs one reachable vulnerable path, so incomplete coverage can leave an exploitable package in place even when one analysis layer appears clean.

Impact: Teams may patch the wrong packages first, understate exploitable exposure, or miss a vulnerable dependency that is only activated under production conditions. That weakens prioritisation and can leave real attack surface unaddressed.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS 6 — Access Control Management	Prioritise software dependency access paths and reduce exposure from reachable vulnerable packages.
Recommendation — Restrict and review dependency access paths to limit the blast radius of exposed package risks.
NIST CSF 2.0	GV.RM — Risk Management Strategy	SCA analysis mode choice is a risk-prioritisation decision about reachable exposure and confidence.
Recommendation — Use risk-based prioritisation to rank SCA findings by reachability and exploitation likelihood.
OWASP Non-Human Identity Top 10	NHI-04 — Credential Lifecycle	Dependency findings can involve secrets and tokens in code or runtime, which affect exposure.
	NHI-06 — Secret Sprawl	Manifest, lockfile and code analysis all help surface hardcoded or misplaced secrets.
Recommendation — Rotate or remove exposed secrets embedded in dependencies or build artifacts. Scan dependency manifests and code paths for secrets that should not be stored in source.

Practitioner Guidance

What to prioritise: Use the four modes as a sequence, not as substitutes. Start with manifest and lockfile analysis to establish the dependency inventory, then use static and dynamic methods to decide which findings are likely reachable in practice.

What to verify: For any high-severity dependency finding, verify whether the vulnerable code path is imported, invoked, or actually observed at runtime before you assign remediation urgency. If you cannot show reachability, treat the issue as lower confidence, not automatically lower risk.

Common mistake: Teams often assume a locked dependency tree equals low risk, or that a runtime test proves an issue is absent. Neither is sufficient on its own. The best outcome is a layered view that distinguishes declared dependencies, resolved dependencies, code usage, and observed execution.

Practitioner takeaway: The most useful SCA result is not the largest finding set, it is the smallest defensible set of reachable exposure that remains after you combine inventory, resolution, code usage, and runtime evidence.