Going even further with this - it has always struck me that the ALWAYS should be just be a hash of the docker image such that it is essentially content addressed and can be verified on the receiver end. Is there any reason that this isn't a good idea?
Just say no to :latest
111–120 of 135 posts
Re: Just say no to :latest
#112The age old question is "How quickly do you update?" Too slow - Exposed to known vulnerabilities. Too fast - Susceptible to active supply chain attacks. There's tradeoffs, and there's no solution here. It's a hard problem.
Exactly this. The OP reads like a nice perfect world scenario but... 1) Just because there is a vulnerability in a package of library doesn't mean that you are susceptible to that vulnerability 2) If you don't update immediately when will you? Most companies can't afford people to understand all posted vulnerabilities to work out whether updating is better than not updating The truth is there are easier ways to reduc…
I really like Microsoft’s mirror of CRAN because it’s versioned by date- you can install everything as it was on a particular date, so that kind of reproducibility is easy. I wonder if this could be added to pypi
Re: Just say no to :latest
#113I somewhat agree. But it's not that simple in practice. For example, I pin every single version and the container fails a security scan because it's not using latest versions of everything. Or I pin to arbitrary versions that happened to be latest when pip/npm/terraform first created the precious word-of-god lock file, leaving future engineers afraid to upgrade those packages because "Chesterton's Fence". Pinning ver…
Needlessly upgrading all of your packages leaves you open to supply chain attacks. If one of those NPM packages got quietly compromised (and my lockfile likely has 4-to-5 digits worth of dependencies in it), you invested time in making what amounts to an unneeded change to expose yourself.
Ok, so let's say it's day one: how do you choose all of your initial pinned versions? How do you know they're safe? What if you luck-out in the supply chain attack lottery and pin malware?
Re: Just say no to :latest
#114Earlier quoted context omitted.
You need to have a CD system which takes equality pinned deps and bumps them when new versions come through and automatically runs the new versions through whatever your test/integration/production environments looks like. And you should have sufficient integration testing that you should have confidence that an automated process should be able to decide if the new version should get deployed to prod (being realistic…
Do people have automated tests to validate their SMSs are sent correctly (and received by a real phone)? Or that credit card payments are made correctly? These are things I use third party libraries for, and what I worry might break when I upgrade dependency versions.
Most payments vendors will have test CC numbers for integration testing. One of Paypal's test numbers is 5555555555554444, for example. https://developer.paypal.com/api/nvp-soap/payflow/integratio...
Re: Just say no to :latest
#115Earlier quoted context omitted.
Maven versions are not present in VCS if you use ranges. Wouldn't this cause issues like not know what Library version is being used in production and builds not being reproducible?
Not to mention that Maven doesn't have any mechanism for locking in transitive versions, because typically everyone uses hardcoded patch versions and never update them.
How do you mean? You can override versions of transitive dependencies.
Re: Just say no to :latest
#116Earlier quoted context omitted.
I've used Maven version ranges to great effect... ...only projects that actually observe semver. (Jackson, take a bow for doing so with your patch releases. I wouldn't use it for your 'minor' releases though.)
Maven versions are not present in VCS if you use ranges. Wouldn't this cause issues like not know what Library version is being used in production and builds not being reproducible?
That's true, but you can export resolved dependency versions at build time if necessary. I've rarely used version ranges because, well, semver rarely occurs, but for Jackson, allowing it for patch releases was a decision to ensure security updates were automatically picked up.
Re: Just say no to :latest
#117Earlier quoted context omitted.
You need to have a CD system which takes equality pinned deps and bumps them when new versions come through and automatically runs the new versions through whatever your test/integration/production environments looks like. And you should have sufficient integration testing that you should have confidence that an automated process should be able to decide if the new version should get deployed to prod (being realistic…
Do people have automated tests to validate their SMSs are sent correctly (and received by a real phone)? Or that credit card payments are made correctly? These are things I use third party libraries for, and what I worry might break when I upgrade dependency versions.
Depends, how big of a deal is it when they break?
Re: Just say no to :latest
#118Earlier quoted context omitted.
Needlessly upgrading all of your packages leaves you open to supply chain attacks. If one of those NPM packages got quietly compromised (and my lockfile likely has 4-to-5 digits worth of dependencies in it), you invested time in making what amounts to an unneeded change to expose yourself.
Ok, so let's say it's day one: how do you choose all of your initial pinned versions? How do you know they're safe? What if you luck-out in the supply chain attack lottery and pin malware?
Older packages are more likely to be vetted as non-problematic than newer packages. As time goes own, the vulnerabilities are disclosed. If you're upgrading to a package that's 1 day old, the community hasn't had the time to go through that process and disseminate the vulnerability. Your point is valid, but I think it's an increased risk since time is against you when you accept fresher, newer, unproven versions of your dependencies.
Re: Just say no to :latest
#119Earlier quoted context omitted.
No, #1 priority is always doing core business - the job that gets money in, satisfies users and keeps the company running. Everything else comes after - without core business, infosec is pointless and can't sustain itself. InfoSec is critically important, but it's important just like IT people, janitors and server maintainers - business breaks without them, but they aren't actually earning money and prioritizing them…
> they aren't actually earning money and prioritizing them over core business is the tail wagging the dog. Uhm, InfoSec helps prevent your company from hemorrhaging money and trust in the form of fines and lawsuits. That makes them a touch more important than you make them out to be. The bigger a companies customers are, the more important InfoSec becomes to your "core business", because the certifications and securi…
That's also your HR and accounting teams' jobs, but they don't tend to assert that they need to be treated as Big Damn Heroes for it.
Re: Just say no to :latest
#120I somewhat agree. But it's not that simple in practice. For example, I pin every single version and the container fails a security scan because it's not using latest versions of everything. Or I pin to arbitrary versions that happened to be latest when pip/npm/terraform first created the precious word-of-god lock file, leaving future engineers afraid to upgrade those packages because "Chesterton's Fence". Pinning ver…
Needlessly upgrading all of your packages leaves you open to supply chain attacks. If one of those NPM packages got quietly compromised (and my lockfile likely has 4-to-5 digits worth of dependencies in it), you invested time in making what amounts to an unneeded change to expose yourself.
Any bit of software can have a very nasty vulnerability (looking at you, log4j). Leaving your software pinned to old versions exposes you to existing undiscovered CVEs.
This is a pick your poison circumstance.