Lock Dependency Versions

[ALRubinger]

All dependencies should be explicitly set; no version ranges. Locked versions reduce several security risks:

• They ensure that checking and deployment are all done with the same software, reducing deployment risks, simplifying debugging, and enabling reproducibility.
• They can help mitigate compromised dependencies from undermining the security of the project (in the case where you've evaluated the pinned dependency, you are confident it's not compromised, and a later version is released that is compromised).
• They are one way to counter dependency confusion (aka substitution) attacks, in which an application uses multiple feeds to acquire software packages (a "hybrid configuration"), and attackers fool the user into using a malicious package via a feed that was not expected for that package.

It comes with the tradeoff of inhibiting dependency updates for a vulnerability fix. To mitigate this we need to use automated tools that detect such VULNs and also notify about outdated dependencies.

Reference: https://github.com/ossf/scorecard/blob/main/docs/checks.md#pinned-dependencies

[ALRubinger]

@andresuribe87 May I add your comments in the Google Doc here? It was a good discussion about what versions we should lock (ie. Plugins, Test Deps, etc?) I'd like to reflect here as we port the work into GH Issues

[andresuribe87]

@ALRubinger of course! Got nothing to hide :)

[ALRubinger]

Thanks! From @andresuribe87:

We had a conversation with @leordev about this only applying to software dependencies, not to the toolchain used to build and distribute the software.

My response:

Yes, had the same convo - let's lock versions for the compile-time and runtime dependencies, not the build toolchain and test dependencies.

Even with this I have some reservations I'm not totally comfortable with. If the build and test dependencies are not version-locked, they may update over time. This means they can change, and therefore change the result of the build. That violates a basic principle of this work: that builds are reproducible over time. A source SHA must always result in the same checksum for the built artifact.

[ALRubinger]

Done for now, adding issue for automation to protect against this going forward: #142