Introduction to Software Supply Chain Security: What to Study and Which Tools to Use for Verification

Software supply chain security is not just about inspecting the code you write. It’s about managing the trust of every link in the chain from when code becomes a product and arrives in the operating environment, including external libraries, build servers, CI/CD workflows, container images, registries, and deployment policies.

Therefore, simply adopting a single vulnerability scanner is not enough. You need to list what has been introduced, prove who built it in what environment, prevent unauthorized artifacts from being deployed, and quickly trace the impact when issues arise. This article connects that flow with a study order and a small hands-on project.

Software supply chain where source and dependencies are securely deployed through build, signing, and registry verification

First, a Misconception to Correct: Supply Chain Security is Not Vulnerability Scanning

Finding already known vulnerable libraries like Log4Shell is important. However, if a legitimate library’s distribution account is compromised, a developer installs a malicious package with a similar name, or an artifact is altered during the build phase, it’s difficult to detect using only CVE lists.

NIST describes Cybersecurity Supply Chain Risk Management (C-SCRM) as activities to identify, assess, and mitigate risks throughout the entire lifecycle, from design, development, deployment, acquisition, operation, to disposal. Narrowing it down to software, the following five questions are key:

What went in? Do you know the direct and transitive dependencies and licenses?
Where did it come from? Can you trace the source, packages, base images, and suppliers?
How was it built? Can you prove the build process and inputs?
Has it been tampered with? Do you verify the artifact’s signature and digest before deployment?
Can it be found if there’s a problem? Can you quickly identify affected services and deployments?

Let’s Outline the Overall Flow First

The supply chain proceeds from Source → Dependencies → Build → Artifacts → Registry → Deployment. Each stage requires different evidence.


Stage	Key Risk	Evidence to Keep	Key Control

—	—	—	—
Source	Account compromise, unauthorized changes	Commit and review records	Branch protection, MFA, CODEOWNERS
Dependencies	Malicious packages, Dependency Confusion	Lockfile, SBOM	Version pinning, private registry priority
Build	CI privilege misuse, tampering during build	Build logs, Provenance	Isolated builds, least privilege, workflow pinning
Artifacts	Image replacement, tag reuse	Digest, Signature, Attestation	Cosign signing/verification
Deployment	Unauthorized image execution	Approval/policy logs	Admission Policy, Digest deployment
Operation	Late-disclosed vulnerabilities	Link deployment with SBOM	Rescan, VEX, impact analysis

An SBOM (Software Bill of Materials) is a list of components included in software. SPDX and CycloneDX are typical formats. Provenance is documentation that explains “what source and build process created this artifact.” The two are not interchangeable. If an SBOM is a list of ingredients, Provenance is closer to a manufacturing history.

What to Study and in What Order

Step 1: Dependency Graphs and Trust Boundaries

First, understand the difference between direct and transitive dependencies, package repository priorities, and the role of Lockfiles. The intersection of public repositories like npm, PyPI, and Maven with internal repositories is a critical trust boundary. Even if you pin a version, you might be pinning an already malicious version, so concluding “it’s safe because it’s pinned” is forbidden.

Step 2: SBOM and Vulnerability Information

Generate SBOMs from the source directory and the final container image, respectively, and compare the differences. Syft can identify components in directories, images, and archives and export them in SPDX or CycloneDX format. Grype, Trivy, and OSV-Scanner can be used to compare these components against known vulnerability information.

Scan results are not verdicts but rather investigation lists. You must check if they reach the execution path, are actually included in the deployed image, and if there are compensating controls. For exceptions, you should record the responsible person, reason, and expiration date.

Step 3: Build Integrity and SLSA

SLSA (Supply-chain Levels for Software Artifacts) is a specification for progressively increasing supply chain assurance. As of September 2026, the approved SLSA 1.2 Build Track divides assurance levels into Provenance existence, signed Provenance generated by a hosted build platform, and enhanced build environments.

Rather than declaring the highest level from the start, define “what level of evidence is needed to prevent which threats.” This is also why applications should not be allowed to arbitrarily generate attestations about themselves within CI, and why a trusted build control layer should generate Provenance.

Step 4: Signing and Verification

Sigstore’s Cosign is used for signing and verifying OCI images and other artifacts, as well as for attestation tasks. What’s important is not just the signing command, but the verification policy. Without checking trusted issuers, OIDC providers, repository, and workflow conditions at the deployment stage, even with a signature file, approval control will not be effective.

In operation, deployments should be based on image Digests rather than mutable tags, and execution should be denied if signature verification fails. For Kubernetes, policy engines like Kyverno or OPA Gatekeeper can be connected to the deployment gate.

Step 5: CI/CD and Response Procedures

Workflow tokens should start with default read permissions and grant write permissions only for necessary tasks. External CI actions should be pinned to reviewed commit SHAs rather than mutable tags, and short-lived credentials should be used where possible instead of long-term secret keys.

The final study topic is incident response. You should practice the process of finding which products and deployments are affected by a new CVE or malicious package using SBOMs, creating a patched build, verifying the new signature and Provenance, and then redeploying.

Choose Tools by Role


Purpose	Tool/Standard	Strengths	Caveats

—	—	—	—
SBOM Generation	Syft, Trivy	Listing components in directories/images	Need to verify completeness and generation time
SBOM Format	SPDX, CycloneDX	Interchangeable representation between organizations/tools	Little use if only created and not stored
Vulnerability Detection	Grype, Trivy, OSV-Scanner	Matching packages with known vulnerabilities	Executability/environmental context requires separate judgment
Repository Hygiene	OpenSSF Scorecard	Heuristic checks like branch protection, token permissions	Do not judge safety based on a single total score
Signing/Verification	Sigstore Cosign	OCI artifact signing and identity-based verification	Verification policy at deployment point is also needed
Build Attestation	SLSA, in-toto	Provenance and Attestation of build inputs, process, and artifacts	Distinguish between declaration and actual build platform assurance
Deployment Policy	Kyverno, OPA Gatekeeper	Blocking unsigned/policy-violating artifacts	Emergency exception procedures and audit logs required

It’s better not to try to fill the entire table with a single product. For example, even if Trivy supports multiple scans, it doesn’t automatically solve SBOM standards, build Provenance, and signature trust policies.

4-Week Hands-on Project: Protecting a Small Container from End to End

For a learning project, one API and one container image are sufficient. The goal is not to install many tools, but to add verifiable evidence and blocking points one by one.

Week 1: Establishing a Baseline

Draw the application’s source, package repository, CI, registry, and deployment environment on a single sheet.
Record direct and transitive dependencies and base images.
Check branch protection, review rules, CI token permissions, and whether external actions are pinned.
Completion criteria: Be able to explain which path arbitrary changes can take to reach the production image.

Week 2: SBOM and Vulnerability Gates

Generate SBOMs for the source and final image using Syft or Trivy, respectively.
Scan the results with Grype, Trivy, or OSV-Scanner.
Don’t just look at severity; record actual inclusion, reachability, patched versions, and exception expiration dates.
Completion criteria: Be able to find which images and services a specific package has been deployed to when given that package as input.

Week 3: Signing and Provenance

Identify images by Digest, not by tag.
Sign images created by CI with Cosign, and verify issuer conditions in a separate verification step.
Store SLSA Provenance or in-toto Attestation describing build inputs and builder.
Completion criteria: A locally arbitrarily created image with the same name should not pass verification.

Week 4: Deployment Blocking and Incident Training

Apply a policy to a test Kubernetes cluster that rejects unsigned images.
Deploy three types of images—a normal image, an unsigned image, and a signed but tampered image—and compare the results.
Assume a new vulnerable package is announced and time the process from impact inquiry to patching, re-signing, and redeploying.
Completion criteria: Blocking logs and approval exceptions remain in an auditable format.

Hands-on practice should be conducted in a separate test repository and cluster. Do not upload secrets or internal SBOMs to public registries, and always verify the behavior of automatic remediation commands first, as they can execute package installation scripts in untrusted projects.

Minimum Gates to Include in CI Pipeline

소스 검증
  → 의존성 설치와 테스트
  → 이미지 빌드
  → SBOM 생성
  → 취약점 정책 평가
  → 이미지 Digest 확정
  → 서명·Provenance 발행
  → 배포 전 신원·서명 검증
  → 승인된 Digest만 배포

If all scan failures are turned into build failures, exceptions can become rampant. Conversely, if only warnings accumulate, it’s not a gate. For example, an organization’s risk criteria should be translated into machine-determinable rules, such as “block critical vulnerabilities with confirmed exploitability, and manage others with time-bound exception tickets.”

Common Failure Patterns

Create an SBOM once and then stop. If not linked to deployments, it’s hard to trace impact later.
Only trust scanner scores. Package origin, build tampering, and account compromise require separate controls.
Trust image tags. Tags can change, so Digest and signature verification are necessary.
Grant broad permissions to CI. Build systems are powerful hubs in the supply chain, so least privilege and isolation are crucial.
Only sign but don’t verify. Without a policy enforcement point, signatures remain mere reference material.
Exceptions have no expiration date. Temporary allowances become permanent policies.

Realistic Starting Point

The first goal of supply chain security is not a “perfect product,” but rather a state where you can prove what sources and dependencies went through what builds and are currently deployed where. On top of that, vulnerability response, signature verification, and deployment blocking are added sequentially.

This week, choose one service, create SBOMs for its source and final image, and compare the differences. Next week, pin the Digest of the same image and attach signature verification. Finally, confirm whether unsigned images are actually rejected at the deployment stage. When these three steps are connected, supply chain security becomes a repeatable engineering procedure, not an abstract slogan.

Official References

Category: General IT/IT Security

Tags: supplychainsecurity, softwaresupplychain, SBOM, SLSA, Sigstore, Cosign, DevSecOps