What do SolarWinds, Log4Shell, and MOVEit have in common? Each one turned a trusted third-party component into a doorway for attackers. That’s the uncomfortable truth about modern software: the code you write is often a small fraction of the code you ship. If a supplier’s library, build tool, or update pipeline is compromised, your own defenses may never get a vote.
Supply chain security is the discipline of managing that risk. It covers everything from the open-source packages pulled into a build to the vendors who host your payroll data. The good news? You don’t need a six-figure program to start. You need a map, a few prioritized checks, and the discipline to keep going. Here’s a grounded, practical path for the first 90 days.
What supply chain security actually covers
Before buying tools, get the scope straight. Supply chain security means protecting the people, processes, and technology involved in producing and delivering your products and services. In practice, it splits into two related tracks:
| Track | What it protects | Typical first move |
|---|---|---|
| Software supply chain | Code, dependencies, build pipelines, containers | Generate an SBOM and scan dependencies |
| Third-party and vendor risk | SaaS tools, contractors, hardware, logistics | Build a vendor inventory and tier by criticality |
Most organizations need both, but they rarely need both on day one. Software supply chain risk tends to be the fastest to reduce because so much of it is visible in code repositories and package manifests. Vendor risk moves slower because it depends on contracts and questionnaires.
Why this matters now, not next year
The regulatory and threat landscape has shifted fast. In the United States, Executive Order 14028, signed in May 2021, pushed federal agencies toward requiring a Software Bill of Materials (SBOM) from software suppliers, and NIST published its minimum SBOM elements that July. The full details live on NIST’s EO 14028 resource page. In Europe, the Cyber Resilience Act entered into force in December 2024, with main obligations applying from December 2027, per the official text on EUR-Lex.
Meanwhile, the incident record keeps piling up. Log4Shell (CVE-2021-44228), disclosed in December 2021, is the classic example: a single logging library, buried deep in countless applications, forced emergency patching across entire industries. The lesson wasn’t “patch faster.” It was “know what you’re running.”
Step 1: Build an inventory before you buy anything
You cannot secure what you cannot see. The single most common mistake is buying a scanning platform before anyone knows which repositories, cloud accounts, and vendors even exist.
Start with a simple spreadsheet or wiki page and answer three questions:
- What software do we build and run? List repositories, container images, and production services.
- What third parties touch it? Cloud providers, CI/CD services, package registries, contractors, and SaaS tools with production access.
- Who owns each item? A name, not a team. Unowned assets are where incidents hide.
This inventory is unglamorous. It is also the foundation for everything else. Teams that skip it end up with a scanner full of alerts and no idea which ones matter.
Step 2: Generate your first SBOM
An SBOM is a machine-readable list of the components inside your software, like an ingredient label. The two dominant formats are SPDX, which became an ISO standard (ISO/IEC 5962:2021), and CycloneDX, maintained by OWASP. Either works; pick one and stay consistent.
Practical guidance from people who have done this:
- Start with one product, not the whole portfolio. Pick a service with an active team and a real user base.
- Automate generation in CI. Most modern build tools and package managers can emit an SBOM as a build artifact. Manual SBOMs rot within weeks.
- Store SBOMs next to releases. When the next Log4Shell hits, you want to query “which versions shipped this library?” in minutes, not days.
CISA’s SBOM resources at cisa.gov/sbom are a sensible orientation for what a usable SBOM should contain. Don’t chase perfection. A partial, automated SBOM beats a beautiful, stale one.
Step 3: Scan dependencies and triage ruthlessly
Once you can see components, you can scan them for known vulnerabilities. Every major ecosystem has free or low-cost options, and most code hosting platforms now include dependency alerts.
The trap here is volume. A first scan on a mature codebase often returns hundreds of findings, and teams burn out trying to fix all of them. A better approach:
- Fix critical and high findings with known exploits first. A vulnerability with a public exploit and an internet-facing path is a different animal from a theoretical issue in a dev-only tool.
- Track reachability where you can. Many scanners now indicate whether vulnerable code is actually called. That signal cuts noise dramatically.
- Set a service-level target and publish it. For example: critical findings patched within 15 days, high within 30. Consistency matters more than the exact number.
For teams also tightening the human side of the operation, the same discipline applies to physical and digital access. If your security program is maturing broadly, guides like this roundup of home security systems show how layered defenses work in practice, and the same “layers, not a single wall” logic applies to software pipelines.
Step 4: Harden the build pipeline itself
Attackers have learned that compromising the build is more efficient than compromising the product. Protecting the pipeline means a handful of concrete controls:
- Require multi-factor authentication and short-lived credentials for CI/CD systems. Long-lived deploy keys are a gift to attackers.
- Pin dependency versions and use lockfiles. Floating version ranges invite surprise updates, including malicious ones.
- Watch for dependency confusion and typosquatting. Register your internal package names on public registries, and review new dependencies before merging them.
- Sign artifacts and verify provenance. Frameworks like SLSA define increasing levels of build integrity, and OpenSSF maintains tools such as Scorecard that rate open-source projects on security hygiene.
None of this requires a big budget. It requires a build system that treats “who built this and from what” as a first-class question.
Step 5: Assess vendors by risk tier, not by checklist
Vendor risk programs fail when every supplier gets the same 200-question assessment. Tier your vendors instead:
| Tier | Examples | Review depth |
|---|---|---|
| Critical | Production infrastructure, identity providers, payment processors | Full security review, contractual security terms, annual reassessment |
| Important | Internal SaaS with sensitive data | Standard questionnaire, SOC 2 or ISO 27001 evidence |
| Low | Marketing tools, no sensitive data | Lightweight self-attestation |
Two practical tips. First, ask for evidence, not assurances: a current audit report beats a confident email. Second, write security requirements into contracts, including breach notification timelines and the right to audit. That’s where promises become enforceable.
If your organization is also evaluating consumer-facing security products for staff or executives, the same “verify claims, check certifications” mindset pays off. Reviews such as this comparison of the best internet security software in Australia illustrate how buyers separate marketing claims from verifiable features.
Step 6: Adopt a reference framework so you’re not reinventing it
NIST’s Secure Software Development Framework (SP 800-218, version 1.1, published February 2022) is the most widely referenced baseline for secure development practices, and it’s available at the NIST CSRC site. It organizes practices into four groups: prepare the organization, protect the software, produce well-secured software, and respond to vulnerabilities.
You don’t need to implement all of it at once. Map your current practices to the framework, note the gaps, and close them in priority order. The framework also gives you a shared language when customers or auditors ask, “How do you manage supply chain risk?”
Step 7: Prepare for the day something breaks
Supply chain incidents move fast, and the first hours are chaotic. Write a short playbook now:
- Who declares an incident? Name a role, not a committee.
- How do you query your SBOMs? Test the query before you need it.
- What’s the patching path for a critical dependency? Know how to ship an emergency release.
- Who talks to customers and regulators? Pre-draft the notification template.
Run one tabletop exercise. Even a 90-minute session exposes assumptions that would otherwise surface mid-crisis.
Common mistakes that stall progress
Having watched many teams start this journey, a few patterns repeat:
- Tool-first thinking. Buying a platform before defining scope produces expensive dashboards nobody reads.
- Boiling the ocean. Attempting full coverage across every repository in month one guarantees burnout.
- SBOMs as a compliance checkbox. Generating an SBOM you never query is theater, not security.
- Ignoring the human supply chain. Contractors with production access are part of your attack surface, and so is the device an engineer uses to check dashboards at midnight. Practical controls like smart locks for home offices are a small but real example of extending security hygiene beyond the office.
- No owner. Programs without a named owner quietly die after the kickoff meeting.
A realistic 90-day plan
Here’s a sequence that fits alongside normal delivery work:
- Days 1–15: Build the inventory of repositories, services, and critical vendors. Assign owners.
- Days 16–30: Turn on dependency scanning for the top five repositories. Triage critical findings.
- Days 31–45: Generate SBOMs automatically in CI for one product. Store them with releases.
- Days 46–60: Harden CI/CD credentials and enable artifact signing where feasible.
- Days 61–75: Tier vendors and send questionnaires to the critical tier only.
- Days 76–90: Run a tabletop exercise, publish your patching SLAs, and set next quarter’s goals.
Notice what’s absent: no giant platform purchase, no 40-page policy. Those can come later, informed by real data.
Conclusion
Supply chain security isn’t a product you install; it’s a habit of knowing what you depend on and verifying it continuously. Start with visibility, automate what you can, tier your vendors, and rehearse the bad day before it arrives. The organizations that handled Log4Shell best weren’t the ones with the biggest budgets. They were the ones who could answer “where is this library?” before lunch.
Frequently asked questions
What is an SBOM and do I legally need one?
An SBOM is a machine-readable inventory of the components in your software, typically in SPDX or CycloneDX format. Whether you legally need one depends on your market: US federal suppliers face SBOM-related requirements stemming from Executive Order 14028, and the EU Cyber Resilience Act introduces obligations for products with digital elements from December 2027. Even without a mandate, an SBOM is the fastest way to answer “are we affected?” during an incident.
How much does a supply chain security program cost to start?
Far less than most people expect. Dependency scanning, SBOM generation, and artifact signing all have mature open-source options, and many code hosting platforms include basic scanning for free. The real cost is engineering time: roughly a few hours per week for one owner during the first quarter. Budget for a paid platform only once you’ve outgrown manual triage.
Should we start with software dependencies or vendor risk?
Start with software dependencies if you build or ship software, because the data is already at hand and fixes are within your control. Start with vendor risk if you’re primarily a buyer of technology. Most organizations eventually need both, but trying to launch both programs simultaneously in the first quarter usually means neither gets real attention.
What’s the difference between SPDX and CycloneDX?
Both are open SBOM formats with broad tool support. SPDX predates CycloneDX, is standardized as ISO/IEC 5962:2021, and has strong roots in license compliance. CycloneDX, maintained by OWASP, was designed with security use cases in mind and covers additional areas such as vulnerability and service inventories. Either format satisfies most regulatory expectations; consistency across your portfolio matters more than the choice itself.
How do we handle a vulnerability like Log4Shell quickly?
Preparation beats improvisation. Maintain SBOMs you can query by component and version, keep an emergency patching runbook with named roles, and pre-draft customer communication templates. During the incident, prioritize systems that are internet-facing and running exploitable code, and don’t wait for a perfect fix before applying mitigations such as blocking rules or disabling features.
Do small teams really need this, or is it enterprise overhead?
Small teams arguably benefit most, because a single compromised dependency can take down the whole product with no one to absorb the blast radius. A lightweight version works fine: dependency alerts switched on, lockfiles enforced, MFA on your build systems, and a one-page incident plan. That’s a few hours of setup, not a program. Scale up only when your customer base or regulators demand it.
