Guides

SBOM, Dependency Risk and Secret Leaks

By Ravindra Bagale, Cyber Security trainer · LinkedIn · Published: 29 September 2026 · Last updated: 30 September 2026

Software supply-chain security for defenders means knowing what you ship (SBOM), watching dependency risk (known CVEs, abandoned packages, typosquats), and stopping secret leaks (API keys in git, tokens in CI logs). SolarWinds and Log4Shell taught the industry that “our code is fine” is not enough when the library underneath is not.

Code + deps → SBOM → CVE scan → secret scan → sign/attest → deploy
No inventory = cannot patch Log4Shell-class events quickly
Leaked key = assume abuse until revoked

What do I need before this guide?

• Vulnerability management — CVE / KEV.
• Optional: OWASP Top 10 (integrity / supply-chain themes).
• A toy git repo you own for practising scanners.

What is an SBOM and why care?

1. SBOM — Software Bill of Materials: machine-readable list of components and versions in an artifact.
2. SCA — Software Composition Analysis: tools that match those components to known vulnerabilities and licences.
3. Pinning — lockfiles (package-lock.json, Pipfile.lock, go.sum) so builds are reproducible.
4. Provenance / signing — prove which pipeline built the binary (advanced but growing baseline).
5. Secret scanning — stop credentials from becoming public “dependencies” of your breach.

Educational warning: only scan and instrument repositories and images you own or are authorised to assess. No attacking package registries or other tenants.

Real incident: Log4Shell (2021) + SolarWinds (2020)

Two public lessons dominate beginner supply-chain talks:

1. Log4Shell (CVE-2021-44228) — a library many teams did not realise they shipped became an internet fire drill; organisations with poor inventories took longest to answer “are we affected?”
2. SolarWinds (2020) — a trusted update channel was weaponised; customers learned that vendor integrity and detection of odd software behaviour both matter.

Takeaways (vertical):

1. What happened — dependency CVE at planetary scale; separate trusted-update compromise case.
2. What went wrong (theme) — incomplete inventories; over-trust in upstream without verification layers.
3. Care-take — SBOM + SCA so KEV/CVE questions get answers in hours.
4. Care-take — vendor risk questionnaires are weak without technical controls (hash verify, least privilege for update agents).
5. Care-take — CI secrets need the same rotation discipline as production keys.
6. Bonus parallel — malicious typosquat packages regularly target popular language ecosystems — defend with careful install habits and allow-lists where possible.

Lockfiles, pins and “just install latest”

1. Lockfiles record the exact tree you tested — commit them.
2. “Latest” floating tags make yesterday’s green build mysteriously red (or quietly vulnerable).
3. Renovate / Dependabot-style PRs are good when humans still review major bumps.
4. For critical crypto / auth libraries, read changelogs before merging.
5. Delete unused dependencies — every unused package is free attack surface and noise.

Red Team vs Blue Team (awareness only)

Red Team — what attackers try

• Compromise upstream libraries or build systems (high-level).
• Publish typosquat names near popular packages.
• Hunt public git history for still-valid cloud keys.

Blue Team — defend, detect, respond

• SBOM per artifact; continuous SCA.
• Protected branches; signed commits optional but useful.
• Mandatory secret scan; ephemeral CI OIDC to cloud.
• Runtime detection for odd child processes from admin tools (link to Sysmon / EDR guides).
• Patch SLAs for transitive dependencies — not only “our” code.

How do I build the pipeline step by step?

Step 1 — Inventory what you already ship

1. List apps, languages, container base images.
2. Ensure lockfiles are committed.
3. Generate a first SBOM in lab (syft, cdxgen, or ecosystem tooling — pick one documented path).

Step 2 — Scan dependencies

1. Add SCA to PR checks (GitHub Dependabot / OSV-Scanner / commercial — org choice).
2. Fail on fixable criticals for internet-facing apps.
3. Track transitive deps — Log4Shell hid in nested trees.

Step 3 — Secret scanning

1. Pre-commit hook on developer laptops for your org standard tool.
2. Server-side scan on push; block on high confidence secrets.
3. Educate: .env never committed; use secret managers.
4. Rotate any key that ever touched a public PR — do not argue “it was only 2 minutes”.

Step 4 — Harden installs and builds

1. Prefer official registries; be suspicious of brand-new packages with almost no downloads.
2. Pin base images by digest for production Dockerfiles when practical.
3. Separate build roles from deploy roles (IAM least privilege).
4. Keep package-manager cache hygiene on CI runners.

Step 5 — Respond when something explodes

1. Query SBOM / SCA for the CVE ID across all services.
2. Patch, rebuild, redeploy; verify versions.
3. If a secret leaked: revoke → invalidate sessions → review cloud audit logs.
4. Write the timeline; add a control so the same class cannot recur silently.

Step 6 — Talk to leadership in plain English

1. “We can answer affected-or-not for critical CVEs within X hours.”
2. “Secrets found public last quarter: N; median revoke time: Y.”
3. Avoid fear slides without owners and dates.

Care-take — supply chain without theatre

1. One SBOM format per org; store next to the artifact.
2. Exception register for unscannable legacy with expiry.
3. Vendors: ask for their SBOM / vulnerability disclosure process.
4. Open-source maintainers you rely on: track security advisories.
5. Container registries: block :latest in prod manifests.
6. Tabletop SolarWinds question: “how do we validate an update before wide deploy?”
7. Keep a printed / wiki revoke checklist for the top five secret types you use (cloud, package registry, chatbot API, DB, webhook).

How do I fix common supply-chain mistakes?

Ghabru naka 😅 — these are the usual ones: