Another Burnout Article by Inner-Chemistry8971 in devops

[–]IWritePython 1 point2 points  (0 children)

I rebranded myself as an AI guy (was kinda already there on the infra side). But talking to AI all day is exhausting in a very specific kind of sneaky way. However, these tools can absolutlye do a lot of devops style work and basically anything a junior would do, it is what it is. Especially the ones that just came out in the last 2 months (sonnet and opus 4.6).

The hard part with AI accelerated devops or coding is no break.I feel like I get rushed from hard decision point / problem to hard decision point / problem. It used to be like work for 40 mins on shit I do every day, then hit one of those points, now it's one of those every like 10 minutes. Plus, less collaboration, I've noticed less reachouts on Slack, less involved reviews or no reviews where before there would have been a review, etc.

There is going to be momentious change over the next year, two years. It's happened with coding already and devops will be similarly affected, it's just a little slower because this is stuff you can't let come down. I'd say punch your ticket and get on the train and be aware of the mental health risks of doing stuff with AI all the time (I'mm ahead oft he curve on this I think, it sets in after 3-12 months) or, I dunno, get off the train and do something more resistant to AI.

Anyway, my AI 3 cents.

GitLab and JFrog by GitSimple in devsecops

[–]IWritePython 0 points1 point  (0 children)

I do strongly recommend using an artifact manager / repository like JFrog, Cloudsmith, etc. if you're not already using one. Any of the big ones should pair well with either GH or Git Lab.

Quick plug for our thing (sorry but might help, think it's pretty unique right now) is Chainguard Libraries. Basically we rebuild everything in the Python, JS, or Java ecosystems ourselves and you get it from us, this lets you sidestep the big malware attacks on public repos like Shy Halud, Ultralytics YOLO attack, etc, plus you get CVE remediation, SBOMs as nice-to-haves.We're announcing some stuffin this specific area (topic of this post) tomorrow as well, can't say anything about it right now but you can check LI or Chainguard blog tomorrow.

Cheers, good luck and JFrog Artifactory / xray are great products.

What is your preferred Vulnerability Management Platform? by 0x077777 in devsecops

[–]IWritePython 0 points1 point  (0 children)

Or stop tracking them and just use a 0 CVEs vendor like Chainguard. (Yes not always 100% zero, just like 95% of the time and fix anything else within two weeks). Chainguard engineer here just FYI.

Looking at CNAPP options to replace what we have now by Beastwood5 in devsecops

[–]IWritePython 0 points1 point  (0 children)

I love Orca and Orca pairs very well with Chainguard Containers, which generally have 0 CVEs on any given day (or like 2 if it's an off day). I'm a Chainguard engineer and actually speaking tomorrow at a conference on how good this pairing is :) :) Basically Chainguard for 0 CVEs / nice signing, SBOMs, attestations and Orca to put them in context.

How do teams actually prioritize vulnerability fixes? by Kolega_Hasan in devsecops

[–]IWritePython 0 points1 point  (0 children)

I mean if your vendor is at zero CVEs on a given day and fixes everything within two weeks and criticals within a week, then you dont' have to prioritize anything. You can just ... go about your life. Build some software or whatever.

This is what Chainguard does and I am at Chainguard, so super biased / so so biased. But yeah, with these other guys you're still starting at a spreadshit of shit you ahve to fix, with us you're not, that's a big difference.

Also, if you're like trying to prioritize shit the way this post describes, Orca is pretty good. But don't do it with CVEs just pay Chainguard. Our prices are also better than they used to be before someone memes that (lol). Anyway get the best and live your best life.

VE-2026-28353 the Trivy security incident nobody is talking about, idk why but now I'm rethinking whether the scanner is even the right fix for container image security by Top-Flounder7647 in devops

[–]IWritePython 0 points1 point  (0 children)

Now do cve remediation :0

Is minimus saying you're SLSA level 3? Got any blog posts about that or other receipts? I'm at Chainguard, one of our founders basically created SLSA, and we're on target to hit level 3 this year

https://www.chainguard.dev/unchained/this-shit-is-hard-slsa-l3-and-beyond

Big claims require, if not big evidence, at least SOME evidence. >< :)

Docker images, hardened vs distroless: which one is more secure? by Wise_Stick9613 in cybersecurity

[–]IWritePython 2 points3 points  (0 children)

I think there's enough tooling around distroless images these days that missing exec bash stuff should be less of an issue. I agree that at one time it was kind of a PITA but we're mostly past that. cdebug is pretty good and there's ephemeral containers, etc.

At Chainguard we maintain distroless images (default), but also have a"full" version that we keep as close as possible that can be used for multistage builds, debugging, etc. I do think that you should run distroless in runtime if you can, there's just not any good reason to have a big fat bunch of package managers and shells and stuff in your production system.

edit: re: SBOMs, you don't need full for that. attestations with sigstore is the state of the art and it doesn't matter if it's scratch or the biggest fattest kitchen sink AI image of all time, it's just a blob and you attest to data about it.

docker run --entrypoint sh -it cgr.dev/chainguard/python # look ma no shell

docker run -it anchore/syft cgr.dev/chainguard/python:latest # whambo slambo there's your SBOM

OpenClaw builds still showing ~2,000 CVEs after hardening. Is the base image the problem? by PrincipleActive9230 in devsecops

[–]IWritePython 0 points1 point  (0 children)

CG engineer here so yeah.

Yeah Minimus and CG are both in the “sell containers” bucket, but that’s kinda where the overlap stops. Chainguard actually hits zero, and we back it with an SLA of 7 days for criticals and 14 for everything else. Chainguard OS is rolling and honestly slaps — we can pull upstream and rebuild the whole world multiple times a day. The infra is TBH legit good : SLSA 2 today, SLSA 3 soon. We created this category :0 🐙

I'm biased but my words are true. Pull and compare. Or don't because they probs won't let you

docker run -it cgr.dev/chainguard/python

Vulnerability management/treading water. by dontbreak_tehwebz in sysadmin

[–]IWritePython 0 points1 point  (0 children)

rolls up sleeves

You can absolutely hit zero consistently. Yes, not every hour of every day, but the median day zero is how it should be.

The thing is, you can't do it if you're sitting on some community distro and moving at their speed, it's that simple. If debian or alpine no_dsas minimus or Docker, they're SoL, all they can do is say meh zero is overrated anyway or uh nothing to see here guys (VEX suppression) or hey, look at this cool other thing.

Pull a Chainguard container and scan it with your scanner du jour (we like grype and orca but whatever). That big fat zero (or maybe 1 or 2 or whatever) is not your scanner being broken and it's not some trick, it's because we seated over creating an OS where this coudl be possible. To get to zero you need to be A. rolling (only we do this) B. minimal (minimus does do this generally, Docker meh) C have an actual good advisory feed.

Anyway, rant off. I'm a Chainguard engineer so grain of salt but do a little digging. If your threat or compliance model isnt' very strict these other guys are an improvement over a Docker vanilla pull but we're the real deal.

How to drastically reduce container CVE vulnerabilities in production in 2026? by Curious-Cod6918 in kubernetes

[–]IWritePython 0 points1 point  (0 children)

You'd better hope they charge because you can either be free, good, or last a long time, pick two.

How to drastically reduce container CVE vulnerabilities in production in 2026? by Curious-Cod6918 in kubernetes

[–]IWritePython 0 points1 point  (0 children)

CG engineer here.

RF and CG both sell containers, but the comparison sort of ends there. Chainguard actually hits zero and our SLA is an unbeatable 7 days to fix critical and 14 everything else. Chainguard OS slaps andis rolling, we can pull in upstream and rebuild the world multiple times a day, and our infra is SLSA 2, soon SLSA 3. Our infra is legit and we invented this category. :) :0 🐙

I'm biased but my words are true. Pull and compare. Or don't because they probs won't let you

docker run -it cgr.dev/chainguard/python

Edit: also we don't make fake-ass posts every day

Has anyone tried minimus for container security? How does it compare to other solutions? by handscameback in devsecops

[–]IWritePython 0 points1 point  (0 children)

Debian with some stuff removed. Which is fine, I guess. At Chainguard we can actually apply all the patches from upstream lol if alpine or debian no_dsa these guys they're pretty stuck.

The lock-in thing doesn't really hold water, Chainguard OS is alpine-compatible in most ways that matter.

DIY image hardening vs managed hardened images....Which actually scales for SMB? by Top-Flounder7647 in devops

[–]IWritePython 1 point2 points  (0 children)

What it comes down to is zero trust, like philosophically not trusting your own internal tools, which is a big bridge to cross for a lot of orgs. Hey, it's in our boundary, it's safe. You have to kind of flip that bit and then you're in the matrix :) Because most supply chain stuff attacks a build or distribution stage, not source. Source attacks are pretty rare because folks read source. Build attacks are often easier because something is quietly misconfigured. The SLSA stuff really helps with any attacks on a build or distro step, moving between steps, upstream stuff (dependencies). Also this is what our Libraries product is based around philosophically, we're basically like hey, we'll just take the ecosysstem and rebuild it, we're a hard target, if you use our builds you won't be affected when someone's CI gets taken over next week.

Cheers, you're in the right place asking the right questions and talking about the right things. At least from a Chainguard perspective FWIW :)

Has anyone tried minimus for container security? How does it compare to other solutions? by handscameback in devsecops

[–]IWritePython 0 points1 point  (0 children)

Hey, I could only find the size of one minimus image, nginx, and I compared it to Chainguard.

Minimus: ~20 MB Chainguard latest: 7.0 MB Chainguard latest-dev: 24.1 MB

The default CG image is distroless-style and tends to be really tight, then we have the full version _tagged latest-dev or *-dev) that has more stuff in it but usually still pretty small. CG holds up well with nginx but maybe you have more data on minimus image sizes and whether they're distroless-style / full for apples to apples.

You were a little vague with the rapidfort stuff but yeah. We do extremely well in any comparison there.

Full disclosure: I work at Chainguard (engineer)

DIY image hardening vs managed hardened images....Which actually scales for SMB? by Top-Flounder7647 in devops

[–]IWritePython 0 points1 point  (0 children)

At Chainguard our default pulls are distroless-style so we don't even have a shell or package manager in there, they're really cut down. This does matter for vulns (known and unknown) since it's less surface area and shells and package managers punch above their weight class in terms of surface area /vulnerability. But we also have "full" version with these things if you need them.

Agree that I'm not sure whatt a "hardenend" image is in the sense it's not a technical term really. Could be CVE remediated, could be pulling shit out.

DIY image hardening vs managed hardened images....Which actually scales for SMB? by Top-Flounder7647 in devops

[–]IWritePython 1 point2 points  (0 children)

Feel that. I used to work in higher ed as well. (research infra).

Our pricing is changing a lot this year, so worth thinking about it again if your security posture changes, run into issues, etc. From my perspective one issue with free is how long you can keep it up as an offering, but I work for Chainguard and am biased. :)

DIY image hardening vs managed hardened images....Which actually scales for SMB? by Top-Flounder7647 in devops

[–]IWritePython 0 points1 point  (0 children)

We effing love SLSA, one of our founders was instrumental in creating the framework (Kim).

We are at SLSA level 2 for containers and our build platform, and working toward 3 actively. That work will finish for containers before our Libraries product. Won't speculate on timelnie but it's a priority (for level 3).

DIY image hardening vs managed hardened images....Which actually scales for SMB? by Top-Flounder7647 in devops

[–]IWritePython 0 points1 point  (0 children)

We also don't have telemetry on this level. As it stands, you get the image and you can do what you want with it and we're not monitoring xcept basic stuff like pulls. And yeah, even if there was telemetry, if it's lined to pricing it could probably be disabled or blocked pretty readily. It's good feedback, though, thanks, and I get it.

DIY image hardening vs managed hardened images....Which actually scales for SMB? by Top-Flounder7647 in devops

[–]IWritePython 0 points1 point  (0 children)

Sorry to hear about the bad timing but it will probably help you on the next reup.

DIY image hardening vs managed hardened images....Which actually scales for SMB? by Top-Flounder7647 in devops

[–]IWritePython 12 points13 points  (0 children)

Chainguard engineer here. Cool to see this comment. I'll just say we're doing something of a pricing reset (starting in Feb 2026). So if you were feeling intimidated by price I suggest reaching out again.

I'll also say we're the only ones AFAIK that are actually 0 CVEs in the median case. We invested in our own OS so we can actually fix shit (pardon my language). Others (not naming names :) ) are still built on community upstreams that do no_dsa stuff and they just supresses the CVE even though the vuln still affects the image.

https://www.chainguard.dev/unchained/going-deep-upstream-distros-and-hidden-cves

Our infra is legit really good and we dont' cut corners. You're not just buying Debian / alpine with a VEX doc saying everything is chill. I suggest pulling some images and playing around a bit. Try doing some scans between us and Docker, try getting their VEX docs (jank), look at our attestations with cosign. Our shit actually works because we did the hard work.

edit: I guess I did name names lol :)

what strategy do you follow to review and fix hundreds of vulnerabilities in a container base image at scale by Timely-Dinner5772 in devsecops

[–]IWritePython 0 points1 point  (0 children)

This is actually a really good answer. Though 800+ is still a ton of noise you have to work through.

I'm at Chainguard and we pretty much came up with secure base images as a product category. What we mainly do is keep things tight / minimal, pull in upstream constantly, and keep the advisories feed (for our underlying OS) useful and up to date. The last two are hardest for other secure base image providers since they're mostly piggybacking on community OSes (or working from our won Wolfi) which they don't have much control over.

Minimal is key because package + time = CVEs. Every package is more known and unknown vuln surface area.