In one week a small SaaS team can commit lockfiles, install from them in CI, scan dependencies on every pull request, require review on the main branch, cut CI token permissions and write down its vendors. None needs new headcount, and together they answer most first questionnaire questions.
Quick wins at a glance
| Day | Task | Evidence you get |
|---|---|---|
| 1 | Commit lockfiles and install from them in CI | CI config and lockfile history |
| 2 | Turn on dependency scanning for every repository | Scan report with date |
| 3 | Require review and passing checks on the main branch | Branch protection export |
| 4 | Reduce CI token permissions | Workflow files |
| 5 | List vendors and what data they see | Dated vendor table |
Day 1: lockfiles and clean installs
A lockfile records the exact version of every package you install. For npm, the npm ci command is meant for automated environments such as continuous integration. Its documentation says the project must have a lockfile, and that if the dependencies in the lockfile do not match package.json, the command exits with an error rather than updating the lockfile. That is the behavior you want in CI: builds that fail on drift instead of quietly picking new versions.
Other ecosystems have equivalents. Check your package manager's documentation for a frozen or locked install mode and use it in your pipeline.
Day 2: scan dependencies everywhere
Turn on scanning for every repository, including the small ones nobody remembers. Forgotten repositories are where unpatched libraries live. Keep the first report even if it is long. A dated baseline lets you show progress later.
Day 3: protect the main branch
Require at least one reviewer and passing checks before merge, and stop direct pushes to main. Export the setting. Reviewers like to see that a single stolen account cannot ship code alone.
Day 4: shrink CI permissions
GitHub's hardening guidance says it is good security practice to set the default permission for the GITHUB_TOKEN to read access for repository contents, then raise it for individual jobs that need more. It also advises giving workflow credentials the least privileges they need. Make that change in your workflow files and in the repository settings, then run the pipeline to see what breaks and grant back only what is needed.
Day 5: write down your vendors
List each service that handles customer data or can change your code or infrastructure. Add the reason and the owner. A one page table beats a long policy no one reads.
What to leave for later
Do not try to build a full program in a week. Skip custom tooling and big rewrites. The goal is a defensible baseline you can describe truthfully.
Try it yourself
Open the pull request gate demo and watch how a check can block a merge until a finding is handled. Look at where the decision is recorded, since that record is evidence.
Click through it at your own pace, or open it full screen.
Safeguard offers dependency scanning, policies and gates for pull requests, and a free scan at https://gold.safeguard.sh/scan if you want a baseline today.
Quick check
Is one week realistic for a ten person team?
For these five tasks, yes. Each is a settings change or a short document rather than a project.
What if CI breaks after we tighten permissions?
Add back permissions per job, not globally. The breakage shows you which steps really needed write access.
Does this make us compliant with anything?
No. It produces a baseline and evidence. Do not describe it as a certification or a framework result.
Sources
Last reviewed: 19 October 2026.
