In week one, a small team should do five things: list what you depend on, turn on the alerts your code host already offers, make installs reproducible, protect the main branch, and name one owner. None of it needs budget. Together they give you visibility, a feed of known problems and a basic gate.
Why a plan beats a tool purchase
Supply chain security means knowing which third party code you ship, where it came from, and whether it can be trusted. A small team usually has no security hire, so the first week should produce habits and visibility, not a long backlog. If you try to fix everything on day one, you will stop on day three.
Pick one repository to start with, the one that ships to customers. You can repeat the steps for others later. For a longer view, see software supply chain security for startups.
The five days
| Day | Task | Output |
|---|---|---|
| 1 | Inventory dependencies | A list of direct and indirect packages for one repo |
| 2 | Turn on vulnerability alerts | Alerts flowing to one place a human reads |
| 3 | Lock installs | Lockfile committed, CI installs from it |
| 4 | Protect the main branch | Reviews and checks required before merge |
| 5 | Name an owner and a cadence | One person, one recurring 30 minute slot |
Day 1: inventory
You cannot protect what you cannot list. A dependency graph is a summary of the manifest and lock files in a repository, and GitHub's documentation notes it can show vulnerable dependencies and export a software bill of materials. If you do not use that platform, any scanner that reads your lockfile gives you the same starting list. Save the output. It is your baseline.
Day 2: alerts
Turn on dependency alerts in your code host. Send them to a single channel or inbox. Do not triage yet. The goal on day two is only that new advisories reach a person.
Day 3: reproducible installs
Commit your lockfile. In CI, use the install command that refuses to drift. For npm, the documentation for npm ci says it needs an existing lockfile, exits with an error if the lockfile and package.json disagree, and never writes to either file. Other package managers have equivalents. See npm ci versus npm install for supply chain safety.
Day 4: protect main
Branch protection can require status checks and reviews before merge. GitHub's documentation says a protection rule disables force pushes and deletion by default, and that its restrictions do not apply to administrators unless you change that setting. Check the admin setting, because a small team is mostly admins.
Day 5: owner and cadence
Name one person. Put a recurring 30 minute slot on their calendar. The owner does not fix everything, they make sure alerts get a decision. The next post in this series covers weeks two to four.
What done looks like
By Friday you can answer three questions: what do we depend on, who finds out when something is vulnerable, and what stops a bad change reaching main. Write the answers in a short page. That page is also useful the first time a customer asks about your security practices.
Safeguard offers SBOM generation and dependency scanning, reachability analysis and policy gates. You can try a free scan at https://gold.safeguard.sh/scan to get your day one inventory.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
How long does week one really take?
Plan on a few focused hours per day for one repository. Day one and day four take the longest if your repository is large or your branch rules are unclear.
Should we fix the alerts in week one?
No. Week one is about visibility and a gate. Triage and fixing belong in the following weeks, ordered by exploitation evidence and reachability.
Sources
- GitHub Docs, Dependency graph
- npm Docs, npm-ci
- GitHub Docs, About protected branches
- CISA, Software Bill of Materials (SBOM)
Last reviewed: 19 October 2026.
