Dependency confusion

  • Release Candidate 6
    Guest:
    We are at a “proposed final” true release candidate with nothing known remaining to be changed or fixed. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
    /Steve.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in:

    This forum does not automatically send notices of new content. So if, for example, you would like to be notified by mail when Steve posts an update to his blog (or of any other specific activity anywhere else), you need to tell the system what to “Watch” for you. Please checkout the “Tips & Tricks” page for details about that... and other tips!

    /Steve.

LikesCookies

Brian Tillman
Sep 23, 2020
28
5
In SN 807, Steve talks about confusion in dependencies when building services. He said it's hard to guard against something like that. Wouldn't it help to have a manifest with hashes of each module in the build that could be checked to make sure there were no unexpected modules included due to confusion?
 
have a manifest with hashes of each module
Yes, I had had the same though as well. The upside would be as you have proposed, it would lock in a set of dependencies. The downside is that some software evolves frequently/rapidly, and it would prevent the automatic inclusion of updated (bug/security fixed) dependencies.
 
slow the evolution
Well it depends on whether that was a security fix your were expecting to pick up from a dependency. Many of us use dependencies without knowing the intricacies of their construction because there's not enough time in the world to understand everything when deadlines loom.
 
This situation is truly horrible. Building hybrid code from inside and outside your network disturbs me, it also strengthens the need to have code reviews and perhaps a method to flag internalised components in the repo as pull-from-internal.

Our lovely CIA triad is kicking in here with the I and A being strong. You want to ensure the integrity of the code you're pulling into an internal product and you want to ensure the version you have verified and validated (with scanning, testing) remains constant so that you don't break your application the next time you pull everything together from source.