Ask every student to commit a lock file, run one dependency audit command, and paste the output into the submission. Grade the response to findings, not the absence of findings. That keeps the task small for staff and teaches the habit that matters.
Why bother in a course
Student projects are small, but they publish to public repositories, get deployed to free hosting and become portfolio pieces. Many are copied by later cohorts. A vulnerable dependency in a template spreads with the template.
Teaching staff also do not have time to review hundreds of dependency trees by hand. The workload has to sit with the student, with a simple rubric.
The checklist for students
- Use a lock file or pinned requirements file, and commit it.
- Run the audit command for your language and save the output.
- For each finding, write one of three responses: updated, not affected (with a reason), or accepted (with a reason).
- Remove packages you added but never used.
- Do not commit secrets, keys or real personal data. Use fake data for examples.
- If the project is deployed, say where and who can reach it.
Items four and five are cheap and prevent most embarrassing outcomes.
Tools staff can point to
For Python, pip-audit scans environments and requirements files, and exits with 0 when nothing is found and 1 otherwise, which suits an autograder. OSV-Scanner reads many lock file types, including package-lock.json, Cargo.lock, go.mod, poetry.lock and renv.lock, so one tool can cover a mixed course.
pip-audit -r requirements.txt
osv-scanner scan source -L package-lock.json
A grading rubric that stays small
| Item | Points idea |
|---|---|
| Lock file committed | Pass or fail |
| Audit output attached | Pass or fail |
| Each finding has a response | Graded on reasoning |
| Unused dependencies removed | Pass or fail |
Do not penalize a student for a finding that has no fix yet. Reward a clear note.
Gate the template, not every project
If a course provides starter code, scan the template once per term and fix it before release. That removes the same finding from every submission.
Common mistakes to head off
Students often run the audit once, on the day before the deadline, and then add three packages. Ask for the output to match the committed lock file, and have the autograder rerun it on the submitted commit.
Another frequent mistake is copying a dependency list from a tutorial. Those lists are often years old and pin versions with known problems. Tell students to generate their own list from what the project actually imports.
Finally, make clear that a finding in a development only tool, such as a test runner, matters less than one in a package the deployed program loads. A one line note saying which is which is a good answer.
Try it yourself
Open the pull request gate demo and watch how a check can block a change that adds a risky dependency. A course can use the same idea on a shared repository.
Click through it at your own pace, or open it full screen.
Safeguard's policies and gates can enforce this kind of check on pull requests. The free scan is a quick way to see results on one repository.
Quick check
Should students fix every finding?
No. They should respond to each one with a reason. Some findings do not apply to how the project uses the package.
Is this too much for an intro course?
Run it as a single lab. One command and a three line write up is enough for beginners.
Sources
Last reviewed: 19 October 2026.
