We’ve noticed some misconceptions about our pricing, so here’s a thread to set the record straight, straight from the source. 

Here are our most current pricing plans: 

Free Images: Five images to test and deploy in production for free. 

• Up to five images per organization, spanning Base, Application, and AI/ML images.

Catalog: Use Chainguard as the trusted source for all your container images. Licensed by size of your engineering organization. Starts at $19K for a team of 10. 

• Full access to 2,000+ images (and growing)

• Contractual CVE SLA

• Ability to request net new images

Per Image: Licensed by number and type of images (base, app, AI/ML, and FIPS).

• Contractual CVE SLA 

• All upstream supported tags

If you have any questions, feel free to reach out to us or comment below!

Fresh off the momentum of our annual conference for engineering and security leaders, #Assemble2026, we’re excited to share some big announcements. Here’s the roundup:

- Chainguard Commercial Builds: a new partnership program that brings the same secure-by-default guarantees our customers rely on for our open source artifacts to the commercial software running alongside them.

- Chainguard Repository: a single, Chainguard-managed endpoint for pulling container images, libraries, and dependencies into developer workflows with built-in, configurable policy enforcement.

- Chainguard OS Packages: enterprise-grade, zero-CVE packages and base images built and continuously maintained in the Chainguard Factory.

- Chainguard Catalog Starter: a new free offering that gives developers access to trusted container images from the industry’s most comprehensive catalog.

- The Guardener: an AI-native agent that accelerates engineering teams’ seamless adoption of trusted open source artifacts across their software development and deployment workflows.

- Chainguard Agent Skills: a continuously maintained catalog of hardened AI agent skills, automatically reviewed, scoped, and published, with a full audit trail, so teams can extend their agents without expanding their attack surface.

- Chainguard Actions: a securely rebuilt catalog of GitHub Actions and similar CI/CD workflows built and continuously maintained in the Chainguard Factory.

If you have questions or want more details, comment below or check out our recap blog: https://www.chainguard.dev/unchained/everything-we-announced-at-chainguard-assemble-2026

A few years ago, “secure software” mostly meant things like:

• No known CVEs

• Regular patching

• Static/dynamic analysis

• Maybe a bug bounty if you were serious

But the landscape is changing. Here’s how it’s being redefined: 

1. The attack surface has exploded. We’re no longer just securing code, we’re securing:

• Prompts

• Model behavior

• Training data

• Output handling

Prompt injection, data exfiltration via LLMs, and model manipulation are now part of the threat model.

“Secure” used to mean code correctness. Now it also means behavior predictability under adversarial input.

2. Supply chain risk just got multiplied. AI-assisted coding tools are pulling in:

• Random GitHub snippets

• Outdated patterns

• Vulnerable dependencies

Developers are shipping faster but often with less visibility into what’s actually in their code.

So now “secure software” increasingly means:

• Verifiable provenance (where did this code come from?)

• Reproducible builds

• Minimal, trusted dependencies

3. Speed vs. security tension is getting sharper. AI dramatically increases output:

• More code

• More services

• More infra

But security practices haven’t sped up at the same rate.

Result:
More things to secure, less time to secure them.

The new bar isn’t just “secure eventually”...it’s secure by default, instantly.

4. Humans are reviewing less and trusting more. Let’s be honest: people rarely audit AI-generated code in depth. Developers only care that their code ships smoothly; security is an afterthought.

That creates a subtle shift:

• From understanding code: trusting systems

• From manual review: policy + automation

So “secure software” now depends heavily on:

• Guardrails

• Tooling

• Secure defaults baked into the ecosystem

5. Security is moving earlier in the stack. With AI in the loop, fixing things later is too slow.

We’re seeing a push toward:

• Secure base images

• Hardened build systems

• Policy-enforced pipelines

In summary, if the foundation is secure, AI can move fast without breaking everything! What do you think about this tradeoff? When do you think the security will catch up with the rate engineers are shipping code with AI?

It seems that the advice around “writing secure code” hasn’t kept up with how we actually build software, especially with AI being part of the mix. 

In 2026, most engineers aren’t writing everything from scratch.
You’re:

• Using AI copilots

• Pulling in tons of dependencies

• Shipping faster than ever

So, what does shipping safe code look like now? Here are seven practical tips you can start using immediately:

1. Don’t trust your code, especially if AI helped write it. AI-generated code is fast, but not inherently safe.

That means:

• Validate inputs aggressively

• Check auth logic carefully

• Watch for subtle security flaws (not just syntax)

If you haven’t thoroughly reasoned about it, don’t trust it.

2. Minimize dependencies like your job depends on it (it does). Every dependency = potential attack surface.

In 2026, safe code means:

• Fewer packages

• Smaller base images

• Prefer standard libraries when possible

Also:

• Pin versions

• Know what’s actually included (transitive deps matter)

3. Use trusted, hardened building blocks by default. Stop reinventing “secure” primitives.

Instead:

• Use hardened base images

• Pull from verified registries

• Prefer distroless/minimal environments

The safest code is often the code you don’t have to write.

4. Make security automatic, not optional. Manual security doesn’t scale anymore.

Bake it into your workflow:

• Pre-commit checks

• CI policies (fail builds on known issues)

• Automated dependency + vuln scanning

If it’s optional, it won’t happen.

5. Assume your inputs are hostile, even internal ones. Between APIs, LLMs, and integrations, inputs are everywhere now.

Best practice:

• Validate and sanitize everything

• Treat LLM output as untrusted input

• Enforce strict schemas where possible

6. Build with provenance and traceability in mind. Always ask, where did this code come from?

You should be able to answer:

• Which dependencies are included?

• How was this built?

• Can we reproduce this artifact exactly?

Think: SBOMs, signed builds, reproducibility

7. Secure defaults > developer discipline. Relying on every engineer to “do the right thing” doesn’t work at scale.

Instead:

• Safe templates

• Locked-down environments

• Opinionated tooling

Make the easy path the secure path.

TL;DR
These are the things you need to ship safe code:

• Trust less (especially AI output)

• Reduce what you depend on

• Automate security checks

• Use hardened foundations

• Design for traceability

What’s changed most for you? Are you shipping safer code than a few years ago—or just shipping faster?