Adding images involves us creating a new package (APK) in our APK repo. This is done by creating a melange build config (https://github.com/chainguard-dev/melange). The melange config defines some basic tests. It's not comprehensive, but generally validates that the binary produced is functional.
When we build the OCI image, we validate it via some custom tests that we've written. We have identified the canonical image (i.e. DockerHub, GHCR, etc), and we confirm that our image has the same entrypoint, args, env that the canonical image has. Then we have some generated scenarios we run the OCI image through to make sure it functions the same as the canonical image runs.
For example, we have Postgres in the catalog today. When we rebuild, we have some tests that run with various configurations of PG_DATABASE/PG_PASSWORD, etc env vars. We run these with our image and with index.docker.io/library/postgres, and expect to see the same output with both.
> I've seen most auditors mandate 30 days for Critical, but you clearly want to move a lot quicker than that.
You seem to fundamentally not understand security. A proper security program should never be driven by an auditors expectations or even used as a reasonable guideline.
Don't track CVEs and SLAs in days. You need to have patches out before active exploitation in the wild begins, that is the only metric that matters. Go talk to Greynoise about how to get that data.
We’d love for this to be true... most images fill up with CVEs so fast in dependencies, we’re providing minimal images (much less surface area) and have the automation to rebuild the entire dependency graph at least daily, if not multiple times per day.
Hopefully everyone will run a "proper security program" someday!
It can be true for you if your correct your thinking on the problem.
CVEs are basically just bugs that are not triggered by normal operation. If you race to "fix" them all, you are going to drown (as you are discovering).
Focus on your solution for tracking actively exploited vulnerabilities and a prioritization system and you'll greatly simplify the problem while better serving your customers.
We work together on it. Assuming you have a build process and dockerfile (we all do), generally our team can get you listed in the catalog quickly.
It's not too much work since we built on an existing set of tools (melange & apko). I've actually found that putting a Dockerfile into ChatGPT generates a really good first iteration.
Interesting how they mentioned that cars don't use the full charge range of batteries but smartphones do.
There's really no reason a lithium battery should ever be charged to 4.2v.
I suspect almost any consumer would prefer the capacity/lifespan tradeoff at 4.1v, but we inexplicably decided it should be 4.2v, and now it's basically impossible to lower the voltage without 3x the complexity because all the cheap ultra simple linear chips are fixed at 4.2v.
So we have tons of gadgets out there, which do not need the extra 10% capacity, they run for months with typical use anyway, being charged at 4.2v.
If you get five years of life out of a $800 phone and it's battery you're probably pretty satisfied, probably even appreciate the extra battery time.
If you get five years of life out of a $50,000 car and it's battery you're going to be really pissed, and you won't care that you got ten extra miles of range for five years
Pretty sure my phone is the most expensive thing I've ever owned, so a few extra years of battery would still be nice.
Also, predictability over time is more important than absolute performance to me. Being unreachable is scary if you're always on call for remote support, and getting stuck somewhere without being able to call a Lyft could be really bad.
Pretty much anything will run on 4.1v that could run on 4.2, the problem is actually getting it to not charge to 4.2.
The easiest way to charge a lithium battery is with an integrated chip that doesn't have any kind of voltage settings. At the hobby level, it's basically always a TP4506, in commerical projects it's often that, but can sometimes be other chips.
Sometimes more expensive items even use more advanced ones that DO allow voltage settings, and still use 4.2v for some reason!
Exactly this. Art changes over time. The mediums that we use to express ourselves creatively evolves. The position that AI is the end of creative art isn't taking this evolution into account.
When video became an affordable medium, would people say "this is the end of art, live performances are art. Now the people will just watch the same recordings over and over?" Maybe, if the internet existed. But it's had the effect of creating and introducing new art forms.
AI generated content won't replace art. It will evolve it to a new creative.
> security teams is for when things does not go as expected.
That's an unexpected view. Security teams are experts in security and help application developers think of ways the product could be exploited. Security teams run pen tests and bug bounty programs. Security teams manage compliance.
Separation of duties is a critical part of building a secure system, and you can't have separation of duties properly if app developers do it all.
Don't think of a security team a punishment for when things didn't go as expected, but a good security team can help increase velocity and confidence and security all at the same time.
The outages this week have been rough. But outages can and will happen in any provider. I think the better goal is to find a way to use upstream providers in a more resilient way. When they are down, can you have fallbacks to another provider, or will that be too much engineering effort? Don't look for a provider that will be up 100% of the time, but figure out how to make sure your service isn't down when Cloudflare is down.
When we build the OCI image, we validate it via some custom tests that we've written. We have identified the canonical image (i.e. DockerHub, GHCR, etc), and we confirm that our image has the same entrypoint, args, env that the canonical image has. Then we have some generated scenarios we run the OCI image through to make sure it functions the same as the canonical image runs.
For example, we have Postgres in the catalog today. When we rebuild, we have some tests that run with various configurations of PG_DATABASE/PG_PASSWORD, etc env vars. We run these with our image and with index.docker.io/library/postgres, and expect to see the same output with both.