In this issue, I'd like to propose a change to the recommendation w.r.t lockfiles.
Originally, the OSSF (e.g., via the Scorecard's Pinned-Dependency checks) encourages lockfiles, a.k.a. "hash dependency pinning".
The main drawback highlighted by @ljharb is dev lock files. A dev lockfile is one that is used by the maintainer of a project, call it P. P relies on a set of dependencies, PPs. All tests may be passing for the maintainers of P, yet some bugs are reported by consumers because of a drift in PP versions.
As a results, consumers have a poorer experience, since they hit bugs they need to fix in prod, etc. @ljharb describes it as ` it's [...] important than ensuring that maintainers are notified as early as possible about issues in their dep graph..
The main advantages of lockfiles are the following:
Since the benefit of lockfiles is prod and their absence is motivated by development practices, I'd like to suggest rephrasing the recommendation to the following
We recommend using a lock file in privileged environments, such as:
production environments
Other environments with access to sensitive data, such as secrets, PII, write/push permission to the repository, etc
The use of a lock file has the following benefits:
In an incidence response, it helps identify vulnerable packages that have been used, using the sha512
It reduces the chance of pulling in new-compromised packages published by an attacker.
In a non-privileged environment, developers may not use a lock file. This is useful if you want to exercise a wide range of dependency ranges, to anticipate breaking before your users do. If you run CI via GitHub Actions, a non-privileged environment is one of the following:
Pull_request trigger
Other triggers without secrets or permissions explicitly declared as read (default permission is write-all)
(Note: I will leave aside the
npm-shrinkwrap.jsonsince it's discussed separately in https://github.com/ossf/package-manager-best-practices/issues/10)In this issue, I'd like to propose a change to the recommendation w.r.t lockfiles. Originally, the OSSF (e.g., via the Scorecard's Pinned-Dependency checks) encourages lockfiles, a.k.a. "hash dependency pinning".
There has been feedback, e.g. by @ljharb in https://github.com/ossf/scorecard/issues/1826#issuecomment-1092202301 and https://github.com/ossf/package-manager-best-practices/issues/10#issue-1230235673 that lockfiles, in some scenarios, have disadvantages.
The main drawback highlighted by @ljharb is dev lock files. A dev lockfile is one that is used by the maintainer of a project, call it
P.Prelies on a set of dependencies,PPs. All tests may be passing for the maintainers ofP, yet some bugs are reported by consumers because of a drift inPPversions.As a results, consumers have a poorer experience, since they hit bugs they need to fix in prod, etc. @ljharb describes it as
` it's [...] important than ensuring that maintainers are notified as early as possible about issues in their dep graph..The main advantages of lockfiles are the following:
Since the benefit of lockfiles is prod and their absence is motivated by development practices, I'd like to suggest rephrasing the recommendation to the following We recommend using a lock file in privileged environments, such as: production environments Other environments with access to sensitive data, such as secrets, PII, write/push permission to the repository, etc
The use of a lock file has the following benefits: In an incidence response, it helps identify vulnerable packages that have been used, using the sha512 It reduces the chance of pulling in new-compromised packages published by an attacker.
In a non-privileged environment, developers may not use a lock file. This is useful if you want to exercise a wide range of dependency ranges, to anticipate breaking before your users do. If you run CI via GitHub Actions, a non-privileged environment is one of the following: Pull_request trigger Other triggers without secrets or permissions explicitly declared as read (default permission is write-all)