No, you do not have to choose. Pin exact versions in a lock file so a result can be reproduced, and also rebuild and retest on a schedule so the live environment gets security updates. Keep the old pinned environment as an archive, not as the thing you run every day.
Where the conflict comes from
Reproducibility says: change nothing. Security says: keep updating. Both are right about different things.
The solution is to separate three jobs that often get blurred together.
| Job | What it needs |
|---|---|
| Reproduce a published result | The exact versions used, preserved |
| Run today's work | Current, supported, patched versions |
| Know what is exposed | An inventory you can scan at any time |
What a lock file gives you
The renv documentation describes its lock file as a JSON record of the R version and the exact package versions needed to recreate a project. renv snapshot updates it and renv restore reinstalls the same versions elsewhere. Python has equivalents: a fully pinned requirements file, and the OSV-Scanner documentation recommends scanning a resolved lock file when one exists, or a fully pinned list generated with pip freeze.
The same renv article is honest about the limit: it does not install R itself or manage the operating system, system libraries and compilers, and it suggests Docker for those. So full reproducibility needs the container too.
A workable routine
- At publication: snapshot the environment, build a container image, and archive both with the paper or dataset.
- During active work: keep a separate working environment and update it each term.
- At each update: run a vulnerability audit on the lock file, update, rerun the tests, compare outputs to the archived result.
- If outputs differ: investigate. A difference caused by an update is itself information about how fragile the analysis is.
Handling the archived environment
An archived environment holds known vulnerabilities by design. Treat it accordingly:
- Run it offline or with no network access.
- Do not leave it installed on shared login nodes.
- Do not expose it as a service.
- Record its scan results at archive time so readers know what it contains.
When an update changes the numbers
Sometimes a library update changes numerical output slightly. Decide in advance what counts as a meaningful change, record it in the analysis notes, and keep both results. Do not skip the security update just because outputs moved in the last decimal place, but do not hide the change either.
Where Safeguard fits
Safeguard can scan lock files and manifests and keep rechecking them, so an archived list stays useful as new advisories appear. Its fix pull requests are off by default, and in a research setting you would likely keep every category on manual review so a person confirms results still match.
Try it yourself
Open the fix available demo and see how a known fix is surfaced next to the finding. Imagine the comparison step you would add before accepting it.
Click through it at your own pace, or open it full screen.
Quick check
Is pinning a security risk?
Pinning is not the risk. Never revisiting the pin is. Pin for repeatability and schedule reviews.
Do I need a container for reproducibility?
Often yes. A lock file covers packages, not the operating system or system libraries.
Sources
Last reviewed: 19 October 2026.
