Most early-stage teams do not have a software composition analysis process. They have a package.json with 200 dependencies, a CI pipeline that installs them without verification, and a Dependabot config that files pull requests that nobody merges. That is not supply-chain security. That is supply-chain exposure with a paperwork trail.
This guide covers what a realistic SCA baseline looks like for teams with fewer than 20 engineers — not the enterprise version with a dedicated appsec team, but the version a single engineering lead can implement in a week and actually sustain.
Why Supply-Chain Risk Is Higher Than Most Teams Think
The conventional risk model for dependencies looks like this: library has a known CVE, CVE gets published to NVD, we update the library, risk resolved. That model misses the most dangerous category of supply-chain attacks, which do not involve published CVEs at all.
The three threat vectors that have caused the most damage in the past three years:
- Typosquatting: publishing a package with a name similar to a popular package (e.g.,
colorvs.colors, orcross-envvariations). Developers mistype the package name or copy a tutorial that uses the malicious variant. - Dependency confusion: publishing a public package with the same name as an internal private package at a higher version number, exploiting how some package managers resolve version conflicts between public and private registries. The npm
ua-parser-jsincident in 2021 affected an estimated 8 million weekly downloads from a single compromised maintainer account. - Maintainer compromise: a legitimate package gets its maintainer account taken over, a malicious version is published. The package was trusted before the compromise; standard CVE tracking does not catch this until after the fact.
None of these vectors are blocked by a process that only scans for known CVEs. They require a different layer of defense.
The SCA Baseline: What You Need Running
A realistic baseline for a sub-20-engineer startup consists of four components. The order below reflects priority — start at the top, add layers as capacity allows.
1. Automated dependency vulnerability scanning in CI
Every build should run a dependency audit against at least one vulnerability database. For npm-based projects, npm audit is the floor; GitHub Dependabot alerts on known CVEs for free on any repository. For Python, pip-audit covers the PyPI Advisory Database and integrates cleanly into CI in under 30 minutes. For Go, govulncheck from the Go team is the current standard.
Configure your CI to fail builds on high-severity CVEs in production dependencies. Not dev dependencies, not test dependencies — production only. A consistent policy on this removes the ambiguity about whether a high-severity finding blocks the deploy.
2. Dependency lockfiles committed and verified
package-lock.json, yarn.lock, Pipfile.lock, go.sum — these files pin exact versions and, in most cases, include cryptographic hashes of package contents. Committing lockfiles to version control prevents version drift between developer environments and production. It also makes any unexpected version changes visible in code review.
If your CI installs dependencies without a lockfile, or if your lockfile is in .gitignore, fix this first. Highest value, lowest implementation cost.
3. Direct vs. transitive dependency audit
Most vulnerability scanning reports findings against your full dependency tree, but the remediation path differs between direct and transitive dependencies. A vulnerable transitive dependency (a dependency of a dependency) may require waiting for the middle-layer package to update before you can get a clean dependency tree — or using an override to pin the transitive version directly.
Quarterly, run a full audit specifically focused on which high-severity findings are in packages you directly depend on versus transitive dependencies. Direct dependency findings are your immediate responsibility. Transitive findings need a documented policy: either pin-and-monitor, or fork-and-patch if upstream is unresponsive.
4. New dependency review on every PR
The most underused supply-chain control available to small teams is simple manual review of any new dependency added in a pull request. Before merging a PR that adds import requests to a Python project for the first time, ask: does this package have active maintenance, a clear ownership story, and download numbers consistent with legitimate use?
GitHub's Dependency Review action can automate part of this — it surfaces newly added dependencies in PR reviews, including their license and any known vulnerabilities at time of addition. For new packages with under 1,000 weekly downloads, add a human review requirement.
SBOM: When You Need It, When You Don't
A Software Bill of Materials (SBOM) is a structured inventory of all components in your application, including version and provenance information. NTIA and CISA guidance now recommends SBOMs for software sold to federal agencies, and several large enterprises are beginning to require them from vendors.
If your customers are mid-market or enterprise — especially in financial services, healthcare, or federal contracting — you will likely face SBOM requirements within 12 to 18 months. Starting to generate one now is a low-cost way to stay ahead of that requirement. Tools like syft (open source from Anchore) can generate a CycloneDX or SPDX format SBOM from your container image or source tree in a single command.
If your customers are seed-stage startups or SMBs, SBOMs are not a current requirement and not worth prioritizing over the four baseline items above.
What Dependabot Does and Does Not Do
Dependabot is valuable and free. It is also widely misconfigured into uselessness. The most common failure mode is teams that have Dependabot enabled but configured to create PRs on all version bumps — including minor and patch — which floods the PR queue with 40 low-priority updates per week and trains developers to close Dependabot PRs without reading them.
The configuration that actually works: Dependabot security-only mode with open-pull-requests-limit: 10 and versioning-strategy: lockfile-only for non-security updates. This limits Dependabot to security-driven updates, keeps the PR queue manageable, and ensures that a Dependabot PR in your queue actually signals a known vulnerability rather than just a version increment.
Staffing Reality: Who Owns This?
At fewer than 20 engineers, you likely do not have a dedicated security engineer. Supply-chain security responsibility typically falls to the engineering lead, the engineer who most recently added a dependency, or whoever is on-call this week.
The model that works is rotating ownership. Assign a "security sprint reviewer" role that rotates on a two-week cycle. That person's responsibilities include reviewing all new dependencies added in that sprint, processing any critical CVEs flagged by CI, and checking the dependency age report (a script that lists any dependency not updated in over 18 months). Four engineers rotating means each person spends roughly two hours per month on this — sustainable.
The model that does not work: making supply-chain security a "when we have time" activity with no assigned owner. No owner means no accountability, which means Dependabot PRs accumulate and critical CVE notifications go unread. We have seen teams with three open critical-severity dependency vulnerabilities sitting unpatched for 90 days simply because no one knew whose job it was to fix them.
The Minimum You Need
Commit and verify lockfiles in every repository. Run npm audit or equivalent in CI with a hard failure policy on critical severities. Configure Dependabot in security-only mode. Assign rotating ownership of new dependency review and CVE triage.
That is achievable in under a week for a single engineer, maintainable with approximately two hours per person per month, and sufficient to address the most common dependency-related attack vectors. The more sophisticated controls — SBOM generation, SLSA compliance, build provenance verification — are worth adding when you reach Series A and start facing enterprise security questionnaires that ask specifically for them.
