Issue #115
Read about infrastructure and programming topics and news every week
Statehouse
This is a project I developed a few days ago.
Statehouse (statehouse.dev) is a self-hosted, strongly consistent state + memory engine built for AI agents and workflow systems, focused on making agent state durable, versioned, and replayable so you can debug, audit, and trust agent behaviour in production.
TiDB and the rise of the AI-native database
The article argues that in the AI era, data infrastructure—not models—becomes the real competitive advantage, because top-tier LLMs will commoditise while companies differentiate on how well they can store, retrieve, and reuse data for “agentic” workflows.
AI agents also change core database assumptions: instead of humans designing stable schemas and curated pipelines, agents operate continuously over individualised contexts, so data is kept indefinitely, schemas diverge, and “scale” becomes the number of databases/tenants. In agent-driven startups (the article cites Manus as an example), agents create and discard huge numbers of tiny, short-lived databases, producing bursty access patterns and massive metadata churn—with most instances used once.
Conventional databases struggle mainly due to metadata management and economics at a scale of millions of tenants. TiDB’s proposed solution is evolving into a virtualised, highly multi-tenant layer where logical databases are isolated yet share the underlying infrastructure, enabled by its distributed design and separation of compute and storage. The authors also argue SQL will remain the key interface for agents, and that pricing must shift from per-instance to usage-based aggregate consumption. The end vision is “invisible,” with ephemeral databases that agents provision and tear down automatically—so the winning strategy is to store everything and make it usable at machine speed.
https://thenewstack.io/tidb-and-the-rise-of-the-ai-native-database/
The hunt for truly zero-CVE container images
Vendors promising “zero-CVE” container images are hitting a hard reality: if you build on a traditional distro release pipeline (e.g., Debian/Alpine), your security posture inherits the cadence and triage choices of that pipeline. The piece argues CVE counts are useful for visibility, but they’re an imperfect proxy for real risk—and can be distorted by how scanners and VEX documents suppress findings.
It contrasts two approaches. Chainguard rebuilds images directly from source whenever upstream changes occur (Factory 2.0 / DriftlessAF), producing reproducible builds, SBOMs, and signatures, aiming to keep images continuously at or near zero CVEs. Docker Hardened Images (DHI) focus on reducing the attack surface, non-root defaults, SBOMs, and provenance, but remain tied to the upstream timelines of Debian and Alpine.
Chainguard’s critique is that DHI’s VEX metadata often mirrors Debian’s “no-DSA” triage flag (meaning Debian doesn’t issue an immediate security advisory/out-of-cycle rebuild). The article argues that this can conflate “not prioritised for immediate patching” with “not affected,” leading scanners to hide CVEs even when the underlying packages remain vulnerable. It cites examples (two glibc issues and an ncurses bug) where upstream fixes exist but haven’t landed in Debian yet, while VEX can mark images “not affected,” effectively suppressing alerts.
The broader takeaway is a tradeoff: cherry-picking fixes ahead of distros can turn a vendor into a de facto fork maintainer, but leaning too heavily on VEX suppression risks undermining transparency and the promise of machine-readable exploitability data. Finally, it steps back: CVEs are environment-agnostic and sometimes noisy (even invalid), so “zero CVEs” shouldn’t be treated as “secure.” The recommended posture is contextual risk triage and threat modelling, using CVEs as input rather than as the foundation of AppSec.
https://thenewstack.io/chainguard-and-the-hunt-for-truly-zero-cve-container-images/
The Realities of AppSec Risk Management using CVE and CVSS
Codific’s post argues that building AppSec risk management around CVE counts and CVSS scores is fundamentally shaky because both signals contain significant noise and lack deployment context.
CVE quality is uneven: The CVE ecosystem has incentive misalignments—researchers are motivated to publish many CVEs, vendor CNAs may be reluctant to disclose, and “CNA Last Resort” groups often lack deep product context, so validation can be weak. The post cites research suggesting that up to ~⅓ of CVEs in studied datasets were unconfirmed or disputed, plus issues like duplicates and a dispute process that’s so difficult that maintainers often patch rather than fight.
CVSS is inconsistent and often misused: it compresses an ordinal vector into a single 0–10 number using heuristics, which makes it easy to communicate but also easy to misuse in “mathy” risk formulas. Studies cited show large scoring inconsistency (including cases where the same evaluator changes scores months later). Most importantly, CVSS measures impact, not likelihood, so it is not a risk score by itself.
Recommended posture: Treat CVEs as signals, not truth; pay attention to who issued them. Use CVSS as one input, but add contextual triage (asset criticality, exposure, compensating controls) and incorporate likelihood-oriented inputs (e.g., exploit intelligence/probability signals). The foundation should be threat modelling + structured triage, not dashboards alone.
https://codific.com/appsec-risk-with-cve-and-cvss/
My LinkedIn: https://www.linkedin.com/in/riccardotacconi/