Supply Chain Security: The Attack Vector Nobody Talks About Enough
Every organization talks about perimeter security, endpoint detection, and identity management. Far fewer talk seriously about the code they didn’t write — the libraries, build tools, CI integrations, and vendor packages that make up the majority of what runs in production. That is your software supply chain, and for most organizations it is the least defended surface they have.
What a Supply Chain Attack Actually Looks Like
Supply chain attacks don’t break down your front door. They get handed the keys.
The SolarWinds compromise (2020) is the canonical example. Attackers inserted malicious code into the Orion build process. The trojanized updates were signed by SolarWinds and distributed to ~18,000 customers, including U.S. federal agencies — bypassing every perimeter control those organizations had because the delivery mechanism was trusted.
The XZ Utils backdoor (2024) was different in method. A patient attacker spent two years building trust in an open-source project under a false identity, then inserted an obfuscated backdoor into a compression library shipped with most Linux distributions. It was caught by accident — a Microsoft engineer noticed unusual CPU usage. Without that, it would have shipped broadly.
Log4Shell (CVE-2021-44228) demonstrated a third vector: a critical vulnerability in Apache Log4j that propagated into thousands of products whose maintainers didn’t know they were using it — the dependency was transitive and the attack surface invisible.
All three entered through trusted channels, not around them.
The Dependency Graph Problem
A typical Node.js application has over 1,000 transitive dependencies. Most developers know their direct dependencies. Almost none know the full graph.
This isn’t JavaScript-specific. A minimal Python service or Go binary carries its entire dependency tree. If each package in a 1,000-node graph has even a 0.1% chance of being compromised or carrying a critical CVE, the probability that at least one has a problem approaches certainty.
SBOM: You Can’t Secure What You Can’t See
A Software Bill of Materials (SBOM) is a structured, machine-readable inventory of every component in a software artifact: libraries, packages, versions, licenses, and provenance data.
SBOMs have moved from best practice to requirement. U.S. Executive Order 14028 mandated them for software sold to federal agencies; the EU Cyber Resilience Act extends similar requirements. NTIA’s minimum elements framework defines what a valid SBOM must contain.
Operationally, an SBOM lets you answer “are we affected?” in minutes when a critical CVE drops — rather than days.
Tools: Syft, Grype, and Sigstore
Syft (Anchore) generates SBOMs from container images and package manifests in CycloneDX and SPDX formats. Running syft <image> produces a complete component inventory in seconds and integrates cleanly into CI.
Grype (Anchore) matches every component against CVE databases including the NVD and GitHub Advisory Database, outputting installed version, fixed version, severity, and CVE ID. It belongs in your pipeline as a pre-merge gate.
Sigstore and cosign address artifact integrity. Cosign signs and verifies container images and SBOMs against certificates from Sigstore’s free, transparent CA, logging every signature in Rekor — a public append-only transparency log. Supply chain attackers depend on the gap between “published artifact” and “what you’re actually running.” Sigstore closes it.
Verifying Upstream Open-Source Packages
Before taking a new dependency: Is the package actively maintained? Who are the maintainers, and do they have a track record? Does it request unusual permissions relative to what it claims to do?
For existing dependencies: subscribe to advisories via GitHub or osv.dev. Treat unusual version bumps in transitive dependencies without visible changelog activity as suspicious. The XZ Utils backdoor came with plausible-looking entries — automation catches a lot, but reading what critical dependencies actually do catches the rest.
How OpenArmor Monitors for Supply Chain Indicators at Runtime
Prevention is not sufficient. When compromise happens, detection speed determines blast radius.
OpenArmor provides runtime monitoring tuned to supply chain-specific indicators of compromise: a library spawning unexpected network connections (consistent with SolarWinds-style beacon behavior), a compression library executing shell commands (consistent with XZ Utils), or a logging library making outbound DNS requests to attacker-controlled domains (consistent with Log4Shell).
The approach is behavioral baselining at the process and library level. OpenArmor establishes what “normal” looks like for your application components — system calls, network destinations, file paths — and alerts on deviations. Detection logic is open and auditable; your team can inspect what is being monitored and tune baselines without filing vendor tickets.
Building a Supply Chain Security Program: Prioritized Steps
- Generate SBOMs for your production artifacts today. Use Syft. Store them. This baseline is the prerequisite for everything else.
- Run Grype against those SBOMs. Triage critical and high CVEs. Fix what you can; document what you can’t and why.
- Integrate Syft and Grype into CI as gates. New critical vulnerabilities should fail builds, not slip into production.
- Implement cosign signing for container images. Add verification at deployment — one-time setup, ongoing protection.
- Audit direct dependencies for hygiene signals. Abandoned maintainers and unusual permission requests are risks you can act on now.
- Deploy runtime behavioral monitoring. Your SBOM shows what’s installed; OpenArmor shows what it’s doing.
- Define your CVE response process. Who checks the SBOM when a critical advisory drops? What’s the SLA? Define this before you need it.
Supply chain security is a discipline — visibility, tooling, process, and monitoring layered together. Start with visibility. Build from there.
Questions about supply chain security or OpenArmor’s runtime monitoring capabilities? Reach out at techanv.com.