A 10 question dependency security quiz for new engineers

This quiz checks whether a new engineer can handle the everyday dependency decisions: lockfiles, version ranges, audits, install scripts and approvals. Use it as a conversation starter in week one, not an exam. Each answer links to the reasoning, so a wrong guess becomes a short lesson instead of a mark.

How to use it

Give the questions to the new hire a few days in. Review the answers together for fifteen minutes. Where they guess, point to your own team's rules, which may differ from the general answers here.

The questions

1. You cloned a Node project. Which command gives you exactly the lockfile's versions?
2. What does a caret in a version range permit?
3. Should package-lock.json be committed?
4. A pipeline fails on npm audit. What do you check first?
5. What can a package do at install time that surprises people?
6. Where should an npm auth token live on your laptop?
7. A package has ten million downloads. Does that prove it is safe?
8. A pull request adds one direct dependency and forty lockfile lines. Is that a problem?
9. You think a vulnerability alert is not exploitable. Who decides to dismiss it?
10. You suspect a package is malicious. What do you do?

The answers

1. npm ci. It requires an existing lockfile and errors if the lock and package.json disagree, per the npm CLI documentation.
2. Newer compatible versions. The caret is described as "compatible with" the version. It is a range, not a pin.
3. Yes. The npm docs say the file is intended to be committed so teammates, deployments and CI install the same dependencies.
4. Whether your change caused it. Run the audit on the main branch. The audit command exits non-zero when any vulnerability is found, unless an audit level sets a higher threshold.
5. Run scripts. npm documents lifecycle scripts such as preinstall, install and postinstall that run during installation.
6. In your user npmrc, scoped to the registry. Never in a committed file.
7. No. Popularity is not review. See our myths post.
8. Not by itself. Transitive packages are normal, but the reviewer should read what came along.
9. Your team's named owner, not the author alone, with a written reason.
10. Stop, do not install it again, and report it to your security contact and to the registry. For npm, the Report malware option is on the package page.

Scoring without shaming

If they got seven or more, move on. If fewer, schedule a pairing session on a real pull request. The goal is shared habits, not a score. Pair this with the onboarding template.

Where Safeguard fits

Safeguard can do the inventory and watching for you. Its SBOM and dependency scanning lists what a repository actually pulls in, reachability analysis helps separate reachable findings from noise, and policies can gate a pull request. You can try a free scan on a repository to see the output.

Quick check

Sources

• npm Docs: npm ci
• npm Docs: package-lock.json
• npm Docs: npm audit
• npm Docs: scripts
• npm Docs: Reporting malware

Last reviewed: 19 October 2026.