Web Security / Advanced: assurance, supply chain, and recovery / Lesson 17

Dependency and build-chain security

Know what entered the artifact and protect the pipeline that produces and evaluates security evidence.

About 4 min readContent reviewed 2026-10-26

On this page

Lesson goals

Separate inventory, advisories, signatures, provenance, and behavior tests.
Review dependency and automation trust with least privilege.

Treat dependencies as executable trust decisions

A web application depends on runtime libraries, build tools, package scripts, container or platform inputs, and third-party browser resources. Direct and transitive dependencies can affect behavior even when the application source barely changes. Identify accepted sources, supported versions, update owners, and the actual artifact that includes them. A lockfile improves repeatability but does not prove the locked content is safe. Installation hooks and build plugins can execute with the pipeline’s authority. Review why each dependency exists and which privileges it receives instead of treating a familiar package name or download count as sufficient trust.

Keep component records bound to their declared coverage

The JSON is a fictional inventory excerpt, not a standards-complete SBOM and not a list of real vulnerable packages. It records coverage and review state explicitly. An actual inventory should identify the components and relationships included in the release, with enough provenance for investigation and update decisions. Missing build-time or transitive components must not disappear from the security model. A listed component still needs support, configuration, and advisory review. An inventory can explain what is present; it cannot prove that every included component is harmless or that the deployed bytes match the intended build.

json A fictional component-inventory excerpt

{
  "artifact": "synthetic-web-build",
  "coverage": "illustrative-direct-and-build-inputs",
  "components": [
    {"label": "lab-runtime-library", "originReview": "complete", "supportReview": "complete"},
    {"label": "lab-build-plugin", "originReview": "pending", "supportReview": "complete"}
  ],
  "notARealSBOM": true
}

No package is installed, scanned, or downloaded by this example. The labels are invented. A real SBOM uses its selected standard and must state actual coverage and artifact binding.

Interpret vulnerability and origin evidence separately

Advisories describe affected conditions that must be matched to the actual component and configuration. Severity and known exploitation inform prioritization but do not replace service context. A digest identifies expected bytes only when the reference is trustworthy. A signature or provenance document needs verified identity, artifact binding, and an approved policy; any signed-looking file is not automatic approval. None of these checks establishes correct authorization or safe output in the application. Keep supported updates and compatibility tests connected, and record bounded exceptions rather than permanently suppressing a finding to make the dashboard green.

Find declared review gaps without a scanner

The local program reviews supplied metadata and reports the build plugin whose origin is still pending. It does not analyze code, query an advisory database, verify signatures, or inspect installed packages. A dishonest input could mark everything complete, which is why real evidence needs a trusted source and accountable review. Keep pending work visible alongside release identity and the consequence of delay. Check whether changing the component also changes generated code or runtime assumptions. A metadata gate can help organize decisions but must not be mistaken for the actual verification it records.

python A complete offline dependency-review metadata check

components = [
    {"label": "lab-runtime-library", "originReview": "complete", "supportReview": "complete"},
    {"label": "lab-build-plugin", "originReview": "pending", "supportReview": "complete"},
]
review = [item["label"] for item in components
          if item["originReview"] != "complete" or item["supportReview"] != "complete"]
assert review == ["lab-build-plugin"]

Runs on two invented records only. The result identifies a planning gap, not a real vulnerability or malicious package. No package manager, build tool, scanner, registry, or network is invoked.

Protect validation and release capabilities

An untrusted contribution can modify tests, scripts, dependencies, and pipeline instructions. Separate its validation from privileged publication and protect trusted policy ownership. Use minimal credentials, approved identity, reviewed immutable inputs where applicable, and access-controlled artifacts. Mutable tags and cached outputs need a clear trust model rather than being promoted blindly. Do not expose release credentials to arbitrary candidate code merely because the job is named test. Verify the exact artifact with appropriate functional and security evidence. This course installs no dependencies and runs no CI, cloud, scanning, or publication action; it teaches the questions a defensive engineering review must answer.

Common errors and fixes

A lockfile is treated as proof of safe dependencies

Why it happens: Repeatability is confused with trust and vulnerability review.
How to fix it: Review source, support, advisories, behavior, and artifact identity.
Prevent it next time: Track evidence beyond version selection.

A signed artifact from an unexpected identity is accepted

Why it happens: Cryptographic appearance replaces the approved provenance policy.
How to fix it: Verify trusted identity and artifact binding under policy.
Prevent it next time: Define trust roots and expected builders explicitly.

Candidate tests receive publication credentials

Why it happens: Untrusted validation and privileged execution share authority.
How to fix it: Separate capabilities and review pipeline trust boundaries.
Prevent it next time: Use least privilege and protected policy ownership.

Check your understanding

1. A component inventory has every direct dependency. What may be missing?

Show worked solution

Transitive, build-time, generated, platform, or runtime-loaded components can still be outside its coverage. State scope and verify the actual release content and provenance rather than claiming complete supply-chain assurance from one list.

2. A tool reports no known dependency findings. Does that validate authorization?