169: library version pinning

[deedayal]

added new technique to close issue per @netfl0

[netfl0]

• This needs reference.

[ikiril01]

@deedayal thanks for the contribution! A few thoughts:

• Minor syntax stuff, but the class name should not include underscores and therefore should be LibraryVersionPinning
• Are there any references that you can add which support the use of this as a countermeasure?
• Related to the above question, I found the following on Python dependencies: https://docs.google.com/document/d/1x_VrNtXCup75qA3glDd2fQOB2TakldwjKZ6pXaAjAfg/edit?tab=t.0. It says that there are negative security aspects to library pinning, as it means that an application could be running older versions of a library when there are newer versions available that may have fixed vulnerabilities: Second, pinning dependencies means that versions will stagnate to some extent, that users will have to persist in the use of outdated distributions even after updated versions that address, for example, security vulnerabilities are released. If a project pins dependencies, then it must be prepared to issue a new release every time there is an important release of anything the project depends on directly or indirectly, all the way down the dependency chain.

[netfl0]

OBE and forthcoming source code hardening taxonomy.