# Software Supply Chain Foundations

> **Intro:** Supply chain security is the discipline of proving what entered the build, how it was transformed, what left the build, and what evidence exists for the release decision.

## Core building blocks

* trusted source control
* reviewed dependency strategy
* isolated runners
* artifact integrity
* release evidence
* signed outputs where appropriate
* SBOM generation and retention
* dependency and image vulnerability management

## What aged well from older DevSecOps material

Several older books were right about the fundamentals:

* software supply chain risk is a **real engineering problem**, not a compliance side quest;
* teams need an **inventory** of dependencies and build inputs;
* CI/CD is the right place to automate repetitive trust checks;
* smaller changes make supply-chain failures easier to detect and roll back.

What changed is the ecosystem around those ideas.

## Then versus now

| Topic                           | Older or legacy example                              | Current 2026-friendly direction                                                                                                   |
| ------------------------------- | ---------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| Open source dependency scanning | OWASP Dependency-Check, SourceClear, Nexus Lifecycle | Dependency-Check still works; also use Veracode SCA, Dependency-Track, OSV-aware tooling, or platform-native SCA depending estate |
| Container scanning              | Clair, OpenSCAP, registry-specific checks            | Trivy, Syft + Grype, registry-native scanning, SBOM-driven re-scan workflows                                                      |
| Artifact signing                | Docker Content Trust / Notary v1                     | Sigstore Cosign or Notation                                                                                                       |
| Dependency inventory            | ad hoc lockfiles only                                | CycloneDX or SPDX SBOMs stored with builds                                                                                        |
| Vulnerability review            | static report snapshots                              | continuously refreshed inventory with policy and exception workflow                                                               |

## Strategic rule

Do not ask only, “Does this dependency have CVEs?”

Also ask:

* why is it in the build?
* who approved it?
* what transitive packages came with it?
* do we have an SBOM for this release?
* do we know which services consume it?
* can we re-scan old releases when new advisories arrive?

## Practical snippet — legacy but still useful Java/Gradle or Maven scanning

```bash
dependency-check.sh \
  --project app-api \
  --scan . \
  --format HTML \
  --format JSON \
  --out reports/
```

Why it still matters:

* Dependency-Check is still a valid entry point for teams with Java-heavy estates;
* it remains useful for “known vulnerable component” hygiene;
* it is not enough by itself for broad 2026 supply-chain coverage.

## Practical snippet — SBOM-first modern pattern

```bash
syft dir:. -o cyclonedx-json > sbom.cdx.json
grype sbom:sbom.cdx.json --fail-on high
```

This pattern is strong because it separates:

* **inventory generation**;
* **vulnerability evaluation**;
* **future re-analysis** without rebuilding the artifact.

## Practical snippet — image scanning in CI

```yaml
image_scan:
  stage: scan
  image: aquasec/trivy:latest
  script:
    - trivy image --scanners vuln,misconfig,secret \
        --severity HIGH,CRITICAL \
        --exit-code 1 \
        "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
```

## Practical snippet — signing and verifying an OCI artifact

### Legacy pattern

```bash
export DOCKER_CONTENT_TRUST=1
docker trust sign registry.example.com/team/app:1.2.3
```

### Modern pattern

```bash
cosign sign --keyless registry.example.com/team/app:1.2.3
cosign verify registry.example.com/team/app:1.2.3
```

### Why both are shown

Teams still inherit DCT/Notary v1 workflows. For new work, prefer a signing path that aligns with the current OCI and Sigstore ecosystem.

## Practical policy ideas

Fail builds when one of these is true:

* a new dependency is introduced from an unapproved source;
* the image contains critical vulnerabilities above policy threshold;
* no SBOM was produced for a release artifact;
* a protected release artifact is unsigned or unverifiable;
* a reusable pipeline component changed without required review;
* a new third-party GitHub Action or CI component is introduced without pinning and review.

## Common mistakes

* treating SCA as a one-time report instead of a continuously re-evaluated inventory;
* signing artifacts but not verifying them in downstream environments;
* producing SBOMs and then never using them for triage or re-scan;
* trusting mutable tags as if they were release evidence;
* focusing only on app dependencies while ignoring build images, CI components, and registries.

## Related pages

* [🧭 DevSecOps Toolchain Practical Map — Legacy to Current](/devsecops-cicd-and-supply-chain/index/devsecops-toolchain-practical-map-legacy-vs-current.md)
* [SCA, SBOM, and Supply Chain Tooling — Legacy to Current](/devsecops-cicd-and-supply-chain/index-1/sca-sbom-and-supply-chain-tooling-legacy-vs-current.md)
* [Runner Isolation and Trust Boundaries](/devsecops-cicd-and-supply-chain/index-1/runner-isolation-and-trust-boundaries.md)
* [🛡️ Trusted Images, Harbor, and Signing](/cloud-kubernetes-and-infrastructure-security/index-1/trusted-images-harbor-and-signing.md)

\---*Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.*


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/devsecops-cicd-and-supply-chain/index-1/software-supply-chain-foundations.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.