DEV Community: Sonia Bobrik

Your Scoring System Is Also a Training Set for the People You Score

Sonia Bobrik — Thu, 10 Sep 2026 01:11:30 +0000

Every system that assigns a number to human output eventually teaches people how to produce that number. This is not cynicism about human nature, it is a measurable property of deployed software, and the finance industry has been running the longest and best-documented version of the experiment. The story of how executives quietly rewrote their vocabulary once algorithms started grading earnings calls is worth reading as an engineering postmortem rather than a market curiosity, because the failure mode it describes — a model that works beautifully until its subjects learn the rules — shows up in code review bots, abuse classifiers, fraud scores, and LLM evaluation harnesses with the exact same shape. If you ship anything that scores text, you are already inside this loop. The only question is whether you have instrumented it.

The Dictionary That Stopped Working Once It Was Public

The origin story is a measurement bug. Early attempts to score financial documents borrowed general-purpose psychology word lists, which counted words like liability, cost, and tax as negative. In a bank's annual report those are neutral bookkeeping vocabulary, so the scores were noise dressed up as signal. In 2011, Tim Loughran and Bill McDonald published a domain-specific negative word list that fixed the mislabeling, and the corrected tone measure predicted future earnings and stock returns. A working signal, cleanly validated.

Then the list was published. Within a few years, companies whose filings attracted heavy automated download traffic began stripping out precisely the tokens on that list. Not negative language in general. The specific vocabulary the dominant scorer penalized.

There is a rule in here that every engineer should internalize: a published rubric is a published exploit. The moment you document your linting heuristics, your spam features, your ranking factors, or your code-review checklist, you have handed the measured population a spec. They will build to it, usually without any intent to deceive, because building to the spec is what conscientious people do when a spec exists and consequences attach to it.

Bigger Models Raise the Price of Gaming, They Do Not End It

The standard response is to swap the lexicon for something that reads meaning instead of counting tokens. That works, for a while. When the BERT architecture was released in 2018, contextual embeddings made simple word substitution insufficient, because the model could tell the difference between a hedge and a synonym. The finance research found a second, measurable behavioral shift right after that release. Sophistication moved the equilibrium. It did not remove it.

The useful mental model is a cost curve, not immunity. Every upgrade to your scorer raises the effort required to satisfy it without genuinely changing the underlying thing you care about. Sometimes that effort is so high that gaming and honest improvement converge, which is the ideal outcome. Often it just filters out the unsophisticated and rewards whoever can afford better tooling.

Machines Are Now a Large Share of Your Readers

This is no longer a finance-only phenomenon, because the audience composition of the open web has changed. Cloudflare's breakdown of who is actually crawling websites found GPTBot's share of crawler traffic climbing from 2.2% to 7.7% in a single year, a 305% jump in raw requests, while several traditional indexers stayed flat. Your API docs, your changelogs, your error messages, and your incident write-ups are being parsed by systems that will summarize them for humans who never load your page.

That changes what "writing for your users" means. Documentation that is technically accurate but structurally hostile to parsing gets summarized badly. Documentation optimized purely for extraction gets thin and repetitive. Both failure modes are real, and the second one is the earnings-call trap arriving in your repo.

Six Practices That Keep a Scorer Honest

Score residuals, not levels. What predicts anything is deviation from what the subject's circumstances already explain. Levels are easy to shift; residuals are expensive to fake.
Keep a private holdout rubric. Publish the criteria that describe genuine quality, retain a scoring variant nobody outside the team has seen, and use divergence between the two as your alarm.
Monitor feature distributions, not just accuracy. Accuracy on stale labels stays flat while the input distribution rots underneath it. Track the mean and variance of every feature your model weights heavily.
Instrument the unscripted channel. In earnings calls, prepared remarks got sanitized while the analyst Q&A stayed comparatively honest. Every system has an equivalent: freeform commit messages, on-call chatter, support transcripts.
Treat each scorer release as an intervention. Version the model, timestamp the deploy, and check for behavioral breaks afterward. You are not just observing a population, you are perturbing it.
Budget for relabeling from day one. A scoring model has a half-life. Pretending otherwise means you will discover the decay through a business incident instead of a dashboard.

Instrument the Exposure Split

The single sharpest technique from the finance literature is a natural experiment: compare subjects heavily exposed to machine scrutiny against subjects barely exposed at all. If both cohorts drift together, that is real change in the world. If only the exposed cohort drifts, and it drifts specifically on the features your scorer rewards, you are watching adaptation.

That translates into maybe forty lines of production code:

def adaptation_signal(df, feature_cols, exposure_col, period_col):
    """Divergence in feature TRENDS between high- and low-exposure cohorts.
    Large positive values = the scored population is moving on the
    exact dimensions your model rewards. That's the alarm."""
    hi_cut = df[exposure_col].quantile(0.75)
    lo_cut = df[exposure_col].quantile(0.25)
    high = df[df[exposure_col] >= hi_cut]
    low  = df[df[exposure_col] <= lo_cut]

    signals = {}
    for f in feature_cols:
        h_trend = high.groupby(period_col)[f].mean().diff().mean()
        l_trend = low.groupby(period_col)[f].mean().diff().mean()
        signals[f] = h_trend - l_trend
    return dict(sorted(signals.items(), key=lambda kv: -abs(kv[1])))

Run it weekly against whatever your system scores. Alert on the top features by absolute divergence. It will not tell you why the gap opened, but it will tell you where to look, which is more than most teams have.

The Cost That Never Reaches the Dashboard

There is a second-order effect worth naming, because it is the part that damages products rather than models. Text optimized against a parser is text drained of information. When every quarterly update, every postmortem, and every release note is written in the same carefully neutral register, the artifacts get longer, smoother, and less useful to the humans they were originally written for. The information does not vanish. It migrates into residuals, tone, timing, and the things people say when they forget the transcript exists — signals that only well-equipped observers can extract. Everyone else reads polished prose and learns nothing.

That is the real bill. Not a degraded AUC on some internal benchmark, but an organization that has slowly optimized its own writing into noise while its dashboards report improvement.

Build Like Your Scorer Will Be Read

Assume your criteria will leak. Assume the population you measure is intelligent, motivated, and reading carefully. Design so that the cheapest path to a high score is the path you actually wanted, keep a private check on the gap between measured and genuine quality, and set a review date for every model the moment you deploy it. The teams that get burned are not the ones whose metrics get gamed. Every metric gets gamed. They are the ones who never built the instrument that would have shown it happening.

Your Vulnerability Gate Is Quietly Failing Open

Sonia Bobrik — Thu, 10 Sep 2026 01:11:06 +0000

Somewhere in your repository there is a line of configuration nobody has read in two years — a --severity HIGH,CRITICAL flag, a Dependabot threshold, a policy file that blocks a merge when a transitive dependency crosses CVSS 7.0. That line encodes an assumption about the outside world that stopped being reliably true in April 2026, and the backstory matters before you touch it: the shared naming system your entire toolchain gates on came within hours of going dark, as this reconstruction of how the world nearly lost its only shared catalog of software flaws documents in uncomfortable detail, and while the identifiers themselves survived the funding scare, the free enrichment layer that made those identifiers machine-actionable did not survive intact. The CVE ID is still there. The severity score bolted onto it increasingly is not.

The Number You Gate On Has an Owner

Almost every developer-facing scanner — Trivy, Grype, npm audit, Snyk's free tier, your registry's built-in checker — resolves a CVE ID into a severity by asking someone else. Historically that someone was the National Vulnerability Database, which took the raw record a CVE Numbering Authority published and added the parts machines need: a CVSS vector, a CWE classification, and CPE strings describing which product versions are actually affected.

That arrangement broke under arithmetic. NIST spelled it out plainly when it announced the new prioritisation model: CVE submissions grew 263% between 2020 and 2025, and the analysis capacity behind the database never grew to match. The fix was triage rather than expansion. Every unenriched record published before March 1, 2026 was moved into a status called Not Scheduled — roughly 29,000 of them by most counts — and going forward only vulnerabilities that intersect a narrow set of criteria get full treatment. NIST published the new criteria in its own operations notice, and the shape of them is worth internalising: known exploitation, software the US federal government runs, and critical software as defined by Executive Order 14028. Independent estimates put the share of incoming CVEs that will clear that bar at somewhere between 15% and 20%.

The volume side of the equation is not slowing down either. The CVE program published 48,185 records in 2025, up 20.6% on the 40,009 published in 2024, with 484 numbering authorities feeding the pipeline as of January 2026 and first-quarter 2026 submissions running roughly a third ahead of the year before. FIRST forecast another record year. Whatever your scanner does with an unenriched record, it is going to be doing it a lot.

Fail Open, Fail Closed, or Fail Silently

Here is the concrete failure mode. A CVE lands with no NVD-supplied CVSS vector. Your scanner asks for a severity and gets nothing back. What happens next depends entirely on implementation details you almost certainly never audited.

Some tools fall back to a severity supplied by the CNA at publication time, which is often present and often disagrees with what NVD would have assigned. Some fall back to an ecosystem source like the GitHub Advisory Database, which curates its own severities and covers open-source packages well but hardware and enterprise appliances poorly. Some simply emit UNKNOWN. And a gate configured as "block if severity is HIGH or CRITICAL" treats UNKNOWN as not high — which means the build goes green and the merge lands. That is failing open, and it is failing open silently, which is the worst variant because nothing in your logs looks wrong.

The inverse configuration is not better. Teams that flip to "block on anything unresolved" discover their pipeline red-lining on hundreds of records with no context attached, and within about two sprints somebody adds a blanket ignore rule that never gets removed. Alert fatigue is not a personality flaw; it is the predictable output of a gate that cannot distinguish signal from absence of data.

Rewire Around Exploitation, Not Around Severity

The useful correction is not finding a replacement severity feed. It is admitting that a static base score was always a weak proxy for "should this block my release," and replacing it with signals that answer the question directly.

Make known exploitation a hard gate. CISA's Known Exploited Vulnerabilities catalog lists flaws with confirmed in-the-wild abuse, ships as CSV and JSON, and was reaffirmed as the anchor for federal patching timelines under Binding Operational Directive 26-04 in June 2026. It is small, it is free, and a hit on it justifies waking someone up.
Add EPSS as a soft gate. The Exploit Prediction Scoring System publishes daily probabilities that a given CVE will be exploited in the next 30 days. FIRST's own analysis puts the share of published vulnerabilities ever exploited at roughly 2–7%, so an EPSS threshold cuts triage volume by an order of magnitude without discarding much real risk.
Treat missing severity as its own state. UNKNOWN is not zero and it is not critical. Route it to a review queue with a service-level target rather than letting a boolean comparison decide.
Prefer package-level data for package-level problems. OSV records express affected version ranges per ecosystem, which is the question a lockfile actually poses. CPE strings were designed for enterprise asset inventories and map onto package.json badly.
Record which source produced each verdict. When a build fails, the log should say whether the score came from a CNA, from NVD, from an ecosystem advisory, or from a fallback default. Without that, you cannot debug the gate at all.

Fragmentation Is Now Your Problem Too

The redundancy built after the 2025 scare is genuine progress and it also generates work. ENISA's European Union Vulnerability Database went live in May 2025 and assigns its own EUVD identifiers on top of CVE IDs, built on CSAF and driven partly by Cyber Resilience Act obligations. CIRCL's Global CVE system opened to the public in January 2026 with a federated model where numbering authorities issue identifiers without waiting on central approval. CISA's Vulnrichment effort distributes enrichment across authorised data publishers. GitHub keeps its GHSA namespace.

None of these replace CVE. All of them mean the same defect can now appear in four catalogs, at four different times, carrying four different severity judgements and four different claims about which versions are affected. If your tooling ingests more than one source — and increasingly it will, whether or not you chose that — you need a canonical identifier map and an explicit precedence rule for conflicts. Otherwise you get duplicate findings, contradictory dashboards, and engineers who learn to distrust the scanner entirely.

What Actually Changed

For twenty-five years, vulnerability triage was something a developer could outsource to a public good. A free service turned an identifier into a decision, and CI configs were written on the quiet assumption that the service would always be there and always be complete. Both halves of that assumption are now formally retired — not by a catastrophe, but by a published policy change from the organisation that maintained it, arrived at honestly because the volume made anything else impossible.

The catalog survived. The convenience did not. Prioritisation has moved from an external dependency back into your codebase, where it now belongs. Open the policy file, check what it does when the score is missing, and fix that first.

Your Delivery Pipeline Has a Cash Conversion Cycle, and Nobody Is Instrumenting It

Sonia Bobrik — Thu, 10 Sep 2026 01:10:41 +0000

Every engineering team I've talked to can recite how long their test suite takes. Almost none can tell me how long a finished change sits untouched before a human looks at it. That asymmetry is expensive, and the finance world already built the vocabulary we're missing: an argument about the real price of waiting in modern business frames delay as a balance-sheet exposure rather than a scheduling annoyance, and that reframe transfers almost perfectly to software delivery. Cash trapped in receivables and code trapped in review queues are the same category of problem. Both look harmless on any single day. Both quietly determine what your organization can survive.

The Metric You Almost Certainly Don't Have

There's a number from lean manufacturing called flow efficiency: the percentage of total elapsed time that anyone was actually working on the thing. Touch time divided by wall-clock time.

Run it on your last ten pull requests. A typical result looks like this: the author spent 40 minutes writing the change, the reviewer spent 12 minutes reading it, CI burned 9 minutes of compute. That's about an hour of real work. The PR was open for three and a half days.

Flow efficiency: roughly 1.5%.

I have never seen a team guess this number correctly before measuring it. Engineers consistently estimate 40–60%. Reality in most organizations lands somewhere between 5% and 15%, and anything above 25% is genuinely unusual. The reason the intuition fails is that we experience our own work as continuous — from the inside, you were busy the whole time. But you were busy on other tickets while this one sat in a queue. The work item's experience of the week was almost entirely waiting.

This matters because we optimize what we can see. Build time is visible, gets dashboards, gets a dedicated performance sprint. Queue time is invisible, distributed across calendars, and owned by nobody. So teams spend six weeks shaving four minutes off a build that contributes 2% of lead time, while a two-day review wait contributing 60% goes unexamined.

Little's Law Does Not Care About Your Roadmap

The math here is uncooperative in a useful way. Little's Law says:

Cycle Time = Work in Progress ÷ Throughput

Read that again with hiring in mind. If throughput is roughly fixed in the short term — and it is, because onboarding takes months — then the only lever that moves cycle time this quarter is reducing WIP. Not working harder. Not "prioritizing better." Carrying fewer things simultaneously.

Queueing theory makes it worse, or better, depending on temperament. Kingman's formula tells us wait time scales with ρ / (1 − ρ), where ρ is utilization. Plug in numbers:

At 50% utilization, the wait factor is 1. At 80%, it's 4. At 90%, it's 9. At 95%, it's 19.

That's not linear degradation, it's a wall. A team booked to 95% capacity doesn't deliver 15% more than a team at 80% — it delivers dramatically slower because every arriving item queues behind a system with no slack to absorb variance. Every manager who has ever proudly reported "the team is fully utilized" has announced a latency problem in the language of an achievement.

This is the single most counterintuitive thing in delivery performance, and it's why "just add more parallel work" reliably makes things slower.

Speed Is a Financial Signal, Not a Vanity Metric

The pushback is predictable: shipping fast is an engineering preference, not a business outcome. The research disagrees, and it's been disagreeing for a decade. Google's DevOps Research and Assessment program has spent years correlating delivery behavior with organizational results, and their work on the metrics that actually predict delivery performance found that change lead time and deployment frequency track with commercial and operational outcomes — not just developer happiness. The gap between elite and low performers isn't a rounding error; low performers measure lead time in months while elite teams measure it in hours.

The mechanism is straightforward once you stop thinking about it as speed and start thinking about it as exposure. Long lead times mean large batches. Large batches mean risky deploys. Risky deploys mean more process, which means longer lead times. The loop tightens on itself. Meanwhile every unreleased feature is capital you've already spent that hasn't returned anything, and every hour a bug sits unfixed is reputational damage accruing interest.

A team with a two-hour lead time can respond to a security disclosure, a competitor launch, or a broken checkout flow on the same day. A team with a six-week lead time cannot, regardless of how talented its engineers are. The talent is real; it's just stuck in a queue.

Latency Reshapes Human Behavior Before It Reshapes Metrics

Jakob Nielsen's classic thresholds on how long users tolerate a system's response identify three limits: 0.1 seconds feels instantaneous, 1 second preserves an uninterrupted train of thought, and 10 seconds is roughly the ceiling on sustained attention before people go do something else.

Scale those up by four orders of magnitude and you have a startlingly good model of engineering organizations. Ten minutes to CI feedback and developers stay in the change. Ten hours and they've moved on, so returning requires rebuilding context that was free ten hours ago. Ten days and the original author has genuinely forgotten the reasoning, which means the review is now archaeology.

Long feedback loops don't just delay work. They change what people build. When merging is slow, engineers batch changes to amortize the pain, which produces larger diffs, which get worse reviews, which produce more defects. When environments are scarce, people test less and hope more. The latency creates the behavior, and then we blame the behavior.

Where the Waiting Actually Hides

Before optimizing anything, find the queue. In practice it's almost always one of these:

Review latency — time from "PR opened" to "first human comment," usually the single largest block in the whole cycle
Environment scarcity — one shared staging box, booked out days ahead, functioning as a de facto global lock on the org
Approval ritual — change boards and sign-offs that add days of calendar time and, per the DORA research, no measurable stability benefit
Cross-team handoffs — every boundary crossing introduces a fresh queue with its own priorities and its own idea of urgency
Flake-driven re-runs — a 7% flake rate on a 20-minute pipeline turns "merge it" into a lottery with a multi-hour expected wait

The Experiment Worth Running This Week

Don't buy a platform. Pull timestamps from your git host: commit authored, PR opened, first review, approval, merge, deploy. Compute the gaps. Plot the distribution rather than the mean, because the mean will lie to you and the p85 is where the pain lives.

Then resist the urge to fix the biggest technical number. Fix the biggest waiting number. Usually that means a review SLA measured in hours, a WIP limit that people actually respect, or ephemeral environments that end the staging queue permanently.

Speed isn't about typing faster or heroics. It's about deleting the periods when nothing is happening — and once you can see those periods, they turn out to be most of the calendar.

What Over-Promising Really Costs an Engineering Team

Sonia Bobrik — Thu, 10 Sep 2026 01:10:05 +0000

Every engineering organization runs two systems in parallel: the software it ships and the story it tells about that software. When those two drift apart, the gap never stays in the marketing department. It lands in your sprint, your on-call rotation and your backlog. A blunt financial autopsy of the credibility tax now quietly bankrupting the loudest technology companies of 2026 makes that case from the balance-sheet side, and the engineering side of the same ledger is older, better instrumented and far more uncomfortable: any claim you cannot demonstrate on demand becomes work somebody performs later, under pressure, usually at 3 a.m.

Adoption Stopped Meaning Belief

For most of software history, usage and trust moved together. You adopted a database, learned its failure modes, and grew more confident as familiarity accumulated. That relationship has broken. Stack Overflow's survey data shows more than 84% of developers using or planning to use AI tooling while only 29% say they trust the accuracy of what comes out, an eleven-point collapse in a single year. Stack Overflow's own examination of why the developer trust gap keeps widening frames the anomaly precisely: people are using a tool constantly and believing it less each month.

That divergence is the credibility tax rendered as a chart. Developers did not abandon the tools, because the tools genuinely help. They simply moved the cost somewhere the vendor's dashboard cannot see, into review time, extra tests, defensive scaffolding and the private habit of reading every generated line twice. The most cited frustration in that same survey was output that is almost right but not quite, which is exactly the failure shape that maximizes verification cost while minimizing the chance you throw the tool away.

The Tax Has a Metric, and It Is Stability

If you want to know whether your organization is paying, stop asking how people feel and look at your change failure rate. Google Cloud's DORA program surveyed roughly five thousand technology professionals and found something the industry has been slow to internalize: AI adoption now correlates with higher throughput while still correlating with worse delivery stability. Speed improved. Safety did not follow it.

The report's central metaphor is worth stealing for internal arguments. AI is an amplifier. It does not manufacture engineering excellence; it multiplies whatever discipline already exists. A team with fast feedback loops, loosely coupled services and real test coverage converts generated code into shipped value. A team with a 2007 monolith, flaky integration suites and review-as-formality converts the same generated code into incidents. Both teams announce the same productivity number at the all-hands. Only one of them will still believe it in six months.

The Perception Gap Is Not a Character Flaw

The most useful study on this remains METR's randomized trial, where sixteen experienced open-source maintainers worked 246 real issues from their own repositories. Allowed to use AI, they completed tasks 19% slower. Asked afterward, they reported feeling roughly 20% faster. A thirty-nine point gap between the clock and the feeling, among expert engineers, on codebases they knew intimately.

Then something more instructive happened. In early 2026 METR published a revision, explaining that developers who benefit most from AI tended to decline participation in no-AI conditions, that the selection effect undermined the original estimate, and that newer measurements point toward modest speedup. They downgraded their own headline finding in public.

That is what credibility looks like as an engineering practice rather than a virtue. The organizations that survive a hype cycle are not the ones that were right early; they are the ones whose corrections arrive faster than their critics. Every retraction you publish yourself costs a fraction of what the same retraction costs when a customer discovers it in production.

Turn Every Public Claim Into an Executable Assertion

The practical fix is unglamorous and works: treat marketing claims as untested code and refuse to ship them without coverage. Keep a claims ledger, a single file in the repository that every public promise must pass through.

Bind each claim to a test. "Zero-downtime upgrades" becomes a CI job that upgrades a seeded cluster under synthetic load and fails the build if a single request drops. If the claim cannot be expressed as an assertion, it is a wish, and wishes belong in the roadmap document.
Publish the harness, not the headline. A benchmark travels with hardware, dataset, version pins, seeds and p95 numbers. Medians flatter, tails inform, and anyone can reproduce a number that ships with its own runner.
Give every claim an owner and an expiry date. Capabilities decay silently when dependencies change. A claim nobody revalidated in two quarters is technical debt wearing a suit.
Run a claim-failure budget. Track how often reality contradicts documentation the same way you track error budgets. When the budget burns, feature work pauses until the gap closes.
Log your retractions. A changelog entry stating that a previously advertised behavior was removed buys more durable trust than three launch posts, because it proves the other entries were audited by someone willing to lose face.

Documentation Is Where Credibility Is Cheapest to Buy

Most teams write documentation that describes the happy path and quietly omits the cliff edge. This is a false economy, because users find the cliff anyway, and they find it while angry and unsupervised.

A "known limitations" section is the highest-leverage page you can write. Name the concurrency ceiling. State which schemas the migration tool refuses. Say plainly that the SDK retries idempotent calls only, and that non-idempotent writes are the caller's problem. Every failure mode you disclose converts a future support ticket into a design decision the user makes with open eyes, and it inoculates your remaining claims. Readers extend enormous credit to documentation that admits something, because admission is expensive and therefore hard to fake.

Your Personal Balance Sheet

This scales down to the individual. Your credibility as an engineer is a running tally of forecasts against outcomes, and almost nobody keeps score deliberately. Start writing estimates down with the assumptions attached, then re-read them at delivery. The exercise is humbling for about three months and permanently useful after that, because you stop offering confidence you have not earned and start offering ranges you can defend.

The same discipline applies to code review. When you approve a generated pull request you did not fully understand, you are not saving time; you are borrowing it at an interest rate set by whoever gets paged. Reviewing AI output with the skepticism you would apply to a talented contractor with zero context is not conservatism. It is accounting.

Credibility Compounds

The uncomfortable truth in all this data is that the tax is invisible in the quarter you incur it and unavoidable in the quarter you pay it. Teams that over-claim look faster for two quarters and slower forever after, because every subsequent statement they make gets discounted by an audience that has learned to check.

Credibility behaves like a test suite. It is tedious to build, nobody applauds it, and its entire value shows up on the day something breaks and you can tell the truth quickly, precisely, and without having to negotiate with your own previous announcements.

Nobody Is Planning for Retroactive Forgery

Sonia Bobrik — Thu, 10 Sep 2026 01:09:14 +0000

Every discussion of quantum computing and cryptography runs on the same rail: an adversary records encrypted traffic today and reads it once a sufficiently large machine exists. The case made in this examination of the cryptographic clock is the version most engineers have internalised, and it is correct as far as it goes. But it describes only the confidentiality half of public-key cryptography. The other half — signatures, provenance, notarisation, everything answering who made this and when — fails on a different clock, in the opposite direction, and its remedy stops working the instant the break arrives. That asymmetry is the most consequential thing in this transition that almost nobody has on a roadmap.

Verification Checks Math, Not History

A signature verifier is a pure function. It takes a message, a signature, and a public key, and returns a boolean. It has no access to when the signature was produced. It cannot distinguish a signature computed in 2019 from one computed in 2036 by someone who has recovered the private key and typed whatever date they liked into the metadata.

This is why the reassuring line — "signatures can't be harvested, so they're not urgent" — is technically true and practically misleading. Nobody un-signs your 2019 release artifact. What happens instead is that your 2019 release artifact stops meaning anything, because a forged one is now indistinguishable from it. The cryptographic property that dies is not integrity. It's discriminating power: the ability of a signature to separate the authentic from the fabricated. Once ECDSA falls, every classical signature ever produced collapses into the same evidentiary category as an unsigned file with a plausible date on it.

Work out where that lands in a normal engineering organisation and the surface is enormous. Signed Git tags and commits. Container image attestations and transparency-log entries. Notarised installers and driver packages. Signed firmware images sitting in devices that will still be deployed in 2040. SBOM attestations, build provenance, audit trails a regulator will want to inspect a decade from now. None of it is confidential. All of it is load-bearing.

The Timestamp Trap

The instinctive fix is a trusted timestamp. Wrap the artifact in an RFC 3161 token from a timestamp authority, or a qualified electronic timestamp under eIDAS, and you have third-party proof that the signature existed before a given moment. Long-term validation formats in the PAdES and CAdES families are built on precisely this idea, and over seventy jurisdictions grant such timestamps legal standing.

The trap: the timestamp authority signs its tokens with RSA or ECDSA. Break the TSA's key and an attacker doesn't merely forge documents — they mint backdated proof that the forgeries are old. The mechanism everyone is relying on to rescue historical signatures has exactly the same failure mode as the signatures it rescues, and it fails in the direction that manufactures false history rather than merely destroying true history.

Which produces the inversion at the heart of this piece. Confidentiality exposure is fixed at capture time. If a session was recorded in 2023 under classical-only key exchange, nothing you do in 2027 helps; that packet is already in someone's storage array. Forgery exposure is fixed at break time. An archive re-signed with post-quantum signatures and post-quantum timestamps before the break retains its evidentiary weight afterwards; the same archive left alone does not. Signatures are the half where action still changes the outcome — but only while the window is open, and the window closes without an announcement.

The Deadline That Arrives First Isn't TLS

The standards bodies already priced this in, and the ordering surprises most people who assume browsers lead. The NSA's CNSA 2.0 algorithms advisory sets the earliest deadline in its entire schedule for software and firmware signing: support and prefer by 2025, exclusive use by 2030. Web browsers, cloud services, and operating systems get until 2033. Networking equipment, 2030.

The rationale is stated plainly in NSA's own guidance: a quantum-resistant root of trust may be needed in firmware years before the rest of the system can catch up, because firmware is the component you cannot patch your way out of later. If a device shipping in 2027 validates its updates with ECDSA burned into a boot ROM, that device has no upgrade path at all once ECDSA falls. The signature verification code is the thing that would have to be replaced, and it is the thing gating replacement.

Note also what NSA specifies for that use case: not ML-DSA, and explicitly not SLH-DSA. Software and firmware signing is assigned the stateful hash-based schemes LMS and XMSS from SP 800-208, with the multi-tree variants HSS and XMSS^MT disallowed and LMS with SHA-256/192 named as the preferred parameter set. That choice has consequences most developers have never had to think about.

Stateful Signatures Break Your Deployment Model

Every signature scheme working engineers have used is stateless. Sign the same message twice with ECDSA and nothing bad happens. LMS and XMSS are not like this. They are Merkle trees over a finite supply of one-time keys, and each key index may be used exactly once. Reuse an index and you don't get a warning — you get catastrophic private key exposure.

Translate that into ordinary infrastructure practice and things start breaking immediately. You cannot snapshot a signing VM and restore it later; the restored image will re-issue indices the original already consumed. You cannot run two signers behind a load balancer from the same key material. Your disaster recovery runbook — restore last night's backup, resume service — becomes a key-compromise event. Blue-green deployments, autoscaling, container immutability, "cattle not pets": every reflex that makes modern deployment safe makes stateful signing unsafe.

This is the real reason NSA pushes signing into hardware security modules with hardware-managed state. It isn't ceremony. It's that the state is mutable, strictly non-replicable data whose accidental duplication destroys the key, and no ordinary deployment pipeline is designed to hold data with that property.

Bitcoin Is Running the Experiment in Public

If you want to see retroactive forgery risk play out with real money and a real deadline, watch Bitcoin, because it is the one system where the vulnerable public keys are already published forever and cannot be recalled.

Roughly 6.7 to 6.9 million BTC — over a third of circulating supply as of March 2026 — sit in outputs whose public keys are visible on-chain. That includes early pay-to-public-key outputs from the network's first years, every address that has ever been spent from, and every Taproot keypath spend. These aren't keys that might leak. They are published, permanent, and waiting.

The response has been two proposals. BIP-360 introduces a quantum-resistant output type. BIP-361, published in April 2026 under the title "Post Quantum Migration and Legacy Signature Sunset," goes further and proposes phasing out legacy ECDSA and Schnorr signatures entirely — first blocking new sends to vulnerable address types, then, years later, refusing to honour spends from them at all. Reporting on the developer backlash captures the conflict cleanly: the proposal would permanently freeze an estimated 1.7 million coins in ancient addresses whose owners are dead, lost, or gone, including roughly a million attributed to Satoshi.

Two details generalise well beyond cryptocurrency. First, the attack model the BIP authors describe is a covert bleed — derive keys quietly, move value slowly over months, never announce. Under that model the break becomes public knowledge long after it happens, which is precisely the scenario in which "we'll migrate when we see evidence" fails. Second, and more broadly applicable: BIP-361 is the first mainstream proposal to accept that when public keys are permanently published and a signature scheme is dying, the only real protection is to stop honouring the scheme. The freezing debate is fundamentally an argument about what to do with artifacts that cannot be re-signed. Every organisation holding a signed archive will eventually have some version of that argument, with auditors instead of miners.

What Actually Shrinks the Blast Radius

The good news is that the work is mostly unglamorous and mostly available now:

Dual-sign new artifacts. Attach a post-quantum signature alongside the classical one rather than replacing it. Verifiers that don't understand the new algorithm ignore it; verifiers in 2035 have something that still discriminates. Cost is bytes and a second signing call.
Anchor instead of re-signing at volume. For large evidence logs, build a Merkle tree over the records and post-quantum-sign the root. One signature covers millions of entries, and per-record proofs stay small — considerably cheaper than wrapping each entry individually.
Migrate the timestamp authority before the end-entity certificates. A quantum-safe TSA can rescue classical signatures beneath it. A classical TSA cannot rescue anything, and can be used to fabricate history.
Treat signing state as infrastructure, not configuration. If you adopt LMS or XMSS, index state needs the same rigour as a database primary: hardware-held, never restored from backup, never forked.
Decide now what happens to artifacts you can't re-sign. Third-party notarisations, vendor-signed firmware in the field, records under legal hold. The answer may be "accept the loss," but that should be a decision with a date on it, not something discovered during a dispute.

The confidentiality story ends with a straightforward, if grim, conclusion: the data was taken, and it will be read. The provenance story ends somewhere stranger — with a dispute in which both parties hold signatures that verify, and no cryptographic means of telling which one is telling the truth. That outcome is still preventable today. It stops being preventable on a date that will not be announced in advance.

The Trust Protocol the Kernel Shipped in a Text File

Sonia Bobrik — Thu, 10 Sep 2026 01:07:29 +0000

Every couple of decades, software discovers it cannot prove where its own code came from, and every time the fix turns out to be a line of text rather than a technology. That is happening again right now, and the pattern is not confined to engineering — a recent examination of how technology companies are rebuilding trust after the era of automated communication describes reporters who now insist on primary documents before they will print a number, which is the same instinct a maintainer has when a stranger sends a patch with no reproducer. The difference is that one community has already shipped a working answer, in reStructuredText, with no launch event and no vendor behind it. It is worth reading closely, because almost every corporate AI policy currently being drafted gets the same problem wrong.

The Last Time Nobody Could Prove Anything

In 2003, SCO began asserting that proprietary UNIX code had found its way into Linux. The claim was legally weak and eventually collapsed, but it was expensive precisely because it was hard to refute. The kernel had changelogs, yes, but no systematic record of the path a patch travelled: who wrote it, who passed it along, who asserted the right to contribute it. Absence of documentation is not evidence of theft, but it is an excellent place to stand while you allege one.

On 23 May 2004, Torvalds sent a request for discussion about explicitly documenting patch submission. Within about a week, the sign-off procedure was in the tree. The solution was not a code scanner, not an audit firm, not a contributor licence agreement with a signature page. It was a trailer at the bottom of a commit message — a short, human-made certification, permanently attached, trivially greppable, and cheap enough that nobody could argue about the overhead. Twenty-two years later it is still load-bearing infrastructure across an enormous slice of open source.

Keep that shape in mind, because it repeats.

Two Trailers Doing Two Different Jobs

In December 2025, following consensus reached at that year's Maintainers Summit, the kernel merged an official policy on machine assistance. The kernel's AI coding assistants documentation is short, and its central move is a separation most organisations never make.

Agents are forbidden from adding a Signed-off-by line. Only a human can certify the Developer Certificate of Origin, and the human submitter carries the whole load: reviewing generated code, confirming licence compatibility, signing off, and owning the result. Attribution goes somewhere else entirely, into a new trailer:

Assisted-by: LLM coccinelle sparse

The format is Assisted-by: LLM followed by optional specialised analysis tools — coccinelle, sparse, smatch, clang-tidy. Ordinary tooling like git, gcc, make and your editor is explicitly excluded, because listing it would be noise.

Notice what the trailer does not contain: a vendor, a product, a model string. That reads like an oversight until you think about maintenance. Model identifiers churn every few months, and naming a vendor invites an argument about which brand to blame instead of a conversation about whether the patch is correct. The trailer records that a class of tool participated. That is the fact a reviewer can actually use.

The deeper design decision is the split itself. Assisted-by is descriptive: it says how the change came to exist. Signed-off-by is a certification: it says a named person accepts responsibility. Most AI policies being written this year fuse these into a single disclosure checkbox, which produces a field that is simultaneously legally meaningless and operationally useless. Provenance and liability are different data types. Store them separately.

The Constraint Is Bandwidth, Not Authenticity

The kernel's companion document on tool-generated content opens by naming the real problem rather than moralising about it: reviewer and maintainer bandwidth is a scarce resource. That single framing does enormous work. Once the question is resource allocation rather than authenticity, the rules stop being philosophy and become scheduling.

It also lets the document draw a boundary that almost everyone else fumbles. "AI-assisted" is a worthless category if it stretches to cover autocomplete, so the guidelines explicitly exclude trivial tool use: spelling and grammar cleanups, identifier completion and boilerplate, mechanical renames, running a formatter. What falls in scope is any case where a meaningful amount of the contribution was not written by a person in the sign-off chain — a generated function, a machine-drafted file cleaned up afterwards, a changelog produced by handing the patch to a model, even a changelog translated from another language. If a tool found the bug, that belongs in the changelog too, partly as credit and partly so other developers learn the tool exists. When it is ambiguous, the instruction is to disclose.

Proportional Scrutiny Instead of a Ban

Several projects responded to the same pressure by banning generated contributions outright. The kernel did something harder and more durable: it made scrutiny scale with the proportion of generated content, and it published the maintainer's menu of legitimate responses. A maintainer may treat the patch like any other, reject it outright, demand extra testing, review it at lower priority than human-written work, ask the contributor to explain how the model was trained, ask them to demonstrate they understand the code, or — my favourite — respond with a better prompt instead of a code suggestion.

That last option quietly promotes the prompt to a reviewable artifact. And the disclosure the guidelines request is not a checkbox but a description: which tools, what input those tools received (the Coccinelle script itself, for instance), the prompts or a summary of them for longer sessions, which portions of the change were affected, and how the result was tested. A reviewer can act on that. A checkbox tells them nothing except that someone read a policy.

The enforcement clause is equally plain: you are expected to understand and defend everything you submit, and if you cannot, maintainers may reject the series without detailed review. Cost lands on the claimant, which is the only arrangement that has ever survived contact with volume.

The Procedure Reads Like an Interface Contract

The bug-fixing procedure attached to the policy is nine mandatory steps, and it is the most quietly radical part of the document. Read the process documentation in full rather than keyword-searching fragments of it. Record the commit ID. For any non-trivial bug, build a reproducer, and abandon the report if the bug evaporates under one. Write the fix — declared explicitly not optional, on the reasoning that anything capable of finding a bug is capable of fixing it, and that a fix written in the same session inherits the reasoning context. Build it, run checkpatch, discard fixes that fail. Find maintainers with get_maintainer.pl. Consult the threat model to classify the issue, and leave the classification to a human. Never send anything yourself.

Then step eight, which carries more weight than the other eight combined: state explicitly what could not be done. Untested, unbuilt, unreproduced — say so. The document is blunt about why, noting how much time maintainers currently lose to unverified reports and untested fixes.

This inverts the default. Normally a reviewer must discover what is missing from a submission. Here the submitter is contractually required to enumerate their own gaps. Declared uncertainty is the single cheapest trust signal in existence, and it is nearly impossible to fake convincingly, because fabrications never volunteer their own limits.

Regulators Arrived at the Same Primitive

While the kernel worked this out from first principles, Brussels arrived somewhere structurally identical from the opposite direction. Article 50 of the AI Act applies from 2 August 2026, and the European Commission's guidelines on AI transparency obligations were finalised on 20 July 2026 alongside a code of practice on marking generated content. Providers of systems producing synthetic audio, image, video or text must mark outputs in a machine-readable format that makes them detectable as generated. People must be told when they are interacting with a system directly. Systems already on the market got until 2 December 2026 for the marking requirement; content produced before the deadline needs no retroactive labelling. Infringements carry fines up to €15 million or 3% of worldwide turnover.

The scope is different — Article 50 binds providers and deployers of systems, not your commit messages — but the mechanism is the same, and it is the interesting part. Both regimes mark at the moment of generation rather than guessing afterwards with a classifier. Detection is an arms race you lose slowly and then all at once. Declaration is a protocol, and protocols compose.

Porting This Into a Repository You Actually Own

The kernel's version is tuned for an email-based workflow with strong maintainer authority, but the primitives transfer cleanly to any project with a review process.

Split provenance from accountability. One trailer describes how the change was produced; a different, human-only signature accepts responsibility for it. Never collapse them into one field.
Write your out-of-scope list before your in-scope list. If a policy technically covers autocomplete, nobody will follow it, and selective non-compliance corrodes the whole thing.
Ask for prompts and inputs, not a yes/no flag. Store what a reviewer would need to reproduce the generation, not merely the fact that generation occurred.
Require a reproducer and require a gap statement. "I could not test this on hardware" belongs in the pull request body, not in a reviewer's discovery process three days later.
State the scrutiny curve openly. Contributors should know in advance that a mostly generated patch gets slower, harder review — that is information, not punishment.
Keep it greppable and plain-text. The value compounds only if you can query five years of history without a bespoke tool.

What It Does Not Fix

Worth being honest about the limits, because the enthusiasm around provenance metadata is starting to outrun its capabilities. These trailers are self-reported and cryptographically unverified; nothing stops someone omitting one. They function in the kernel because there is a named maintainer with a reputation, a review culture with teeth, and a credible threat of having your series ignored. Bolt the same trailers onto a repository where nobody reviews anything and you have manufactured a compliance artifact, not trust.

But that is exactly the point, and it is why this pattern keeps recurring. The 2004 sign-off did not verify anything either. It created a durable, attributable record of a human being making a claim, and it made that claim cheap to record and expensive to walk back. Twenty-two years later, faced with a machine that can produce infinite plausible text, the kernel's answer is a second line in the same commit message, written by the same accountable person.

Not glamorous. Still the only thing anybody has found that works.

Your Launch Post Is Less Rigorous Than a Government Data Release

Sonia Bobrik — Thu, 10 Sep 2026 00:57:08 +0000

Somewhere in your last release announcement there is a number with no unit attached to it, no interval around it, and no date stamped on it. Maybe it was 40% faster. Maybe it was 99.99% uptime, or a cost saving, or a benchmark score. Whoever reads that number and has to act on it — a procurement reviewer, a platform lead, an investor, a lender — must decide how much of their own risk to price into your confidence. An industry analysis of how announcements get read as lightweight disclosure documents in construction and development makes the consequence explicit for people who sign checks, and the mechanism is identical in software: the reader is not hunting for your best number, they are hunting for the range you would defend under questioning. This is an argument about the three things every published number needs and almost never has.

The release format nobody in tech copied

On September 1, 2026, the U.S. Census Bureau reported that construction spending in July ran at a seasonally adjusted annual rate of $2,157.6 billion, 0.5 percent below the revised June estimate of $2,167.7 billion. Then it did something no engineering blog has ever done. It attached ±0.8 percent to that change, and marked it with an asterisk meaning the 90 percent confidence interval includes zero — in plain language, there is not enough evidence to conclude the decline happened at all.

Read that again. A statistical agency published a headline movement and, in the same sentence, told you the movement might not exist. Its tables tag every figure with p for preliminary or r for revised. The methodology note states that the data are annualized and adjusted for seasonality but not for price changes, so you know exactly what basis you are standing on.

That is four pieces of information per number: value, basis, uncertainty, vintage. Now compare it to "we cut p99 latency by 40%." One piece of information, three missing, and the reader has no way to reconstruct the other three without asking you.

The most expensive implicit unit in history

On September 23, 1999, NASA lost the Mars Climate Orbiter. The story usually gets compressed into "someone forgot to convert to metric," which is true and almost useless.

Here is what actually happened. Ground software called SM_FORCES produced impulse data for the angular momentum desaturation events the spacecraft performed during its nine-month cruise. The software interface specification required those values in newton-seconds. The file delivered them in pound-force-seconds. Because one pound-force-second is roughly 4.45 newton-seconds, the navigation team's model absorbed about 22 percent of the real effect of every thruster firing, and the error accumulated quietly for months, far too small on any single event to trip an alarm. The orbiter arrived at roughly 57 kilometres altitude instead of the planned 226 and did not survive.

The board's Phase I report on the mishap is worth reading in full, because the uncomfortable part is this: the onboard software was correct. The numbers were correct. Both units were legitimate measures of impulse. What failed was that a bare number crossed an organisational boundary carrying its unit only by convention, and the receiving system trusted the convention.

Every announcement you publish is that boundary. Inside your team, "40% faster" has a shared basis — everyone knows which workload, which hardware, which percentile. Outside, it is a bare number crossing an interface with nothing but convention holding the meaning in place.

The mirror-image failure: turning an interval into a verdict

The unit problem has a twin, and it is arguably worse because it looks like rigour.

In March 2019, Nature published a call by more than 800 scientists to stop treating statistical significance as a verdict. Valentin Amrhein, Sander Greenland and Blake McShane were not asking for a ban on P values. Their argument was about compression loss: sorting results into "significant" and "non-significant" makes people treat two nearly identical estimates as categorically different, and routinely converts "we did not detect a difference" into "there is no difference." They argued for describing the interval and discussing what the values at both ends would mean, rather than collapsing everything into a binary.

Developers perform exactly this compression every week. A benchmark run produces a distribution across hundreds of iterations. The blog post publishes a single ratio. A load test finds no regression above the noise floor, and the changelog says "no performance impact." Absence of a detected regression is not evidence of no regression, and everyone reading your post who has run a benchmark knows it — which is precisely why they discount the claim.

A number is three fields, not one

The fix is unglamorous and takes about ninety seconds per claim. Treat a published measurement as a composite value:

{
  "metric": "request_latency_p50",
  "value": 126, "unit": "ms",
  "delta": { "pct": -40, "ci95": [-34, -45], "method": "bootstrap, 10k resamples" },
  "basis": { "n_runs": 500, "instance": "c6i.4xlarge", "corpus": "2026-08" },
  "vintage": { "measured": "2026-08-14", "published": "2026-08-19", "status": "preliminary" }
}

In prose, the same discipline turns this:

"Our new engine is 40% faster."

into this:

"Median request time fell from 210 ms to 126 ms across 500 runs on c6i.4xlarge — a 40% reduction, 95% interval 34% to 45%, measured 14 August 2026 against the 2026-08 corpus."

The second version is longer, less quotable, and dramatically more expensive to dismiss. That trade is the entire point.

Revisions are a feature you have to build

Statistical agencies revise published figures on a schedule and mark the vintage so anyone holding an old number knows it has moved. Software teams silently edit the blog post.

A quietly mutated number is worse than a wrong one, because it destroys everyone's ability to reconcile older references to your work. Keep the URL stable, keep an append-only revision note at the top, and never rewrite history in place. If your benchmark methodology changed, say which vintage the reader is looking at. Nobody has ever lost a deal by disclosing that a preliminary figure was refined; plenty have lost one when a reviewer found two contradictory numbers under the same link.

What to attach to every number you publish

Unit and basis — the workload, percentile, or accounting definition, next to the figure, not in a footnote
Sample and selection rule — n, and how those runs were chosen or discarded
An interval and the method that produced it — bootstrap, standard error, min-max across runs; any of them beats none
Vintage — measurement date, publication date, and status: preliminary, revised, or final
A reproduction path — hardware, config, dataset, commit hash
A scope word — measured, modeled, projected, or contracted, because these are four different commitments

Verification cost is the real currency

Every reader who cannot re-derive your number has to pay for the uncertainty themselves, in extra diligence, in a discount applied to your claim, or in a decision they defer. That cost lands on you whether or not you see the invoice.

The organisations whose numbers move real money — statistical agencies, mission control, peer-reviewed journals — figured this out decades ago, and they all landed in the same place: publish the range, name the unit, date the vintage, and revise in the open. It is not a higher standard than engineering deserves. It is the standard engineering already applies to its own instruments, right up until the moment it writes the announcement.

Reputation Is a Permission System, and Nobody Audits Theirs

Sonia Bobrik — Thu, 10 Sep 2026 00:55:44 +0000

In October 2021, someone opened a pull request against an obscure compression library. It edited an .editorconfig file. By any measure available at the time it was polite, useful, and utterly unremarkable. Two and a half years later, that same contributor shipped a backdoor into xz-utils that came within days of landing in the stable channels of nearly every major Linux distribution. What made it work was not a clever exploit primitive. It was accumulated goodwill: precisely the asset that this analysis of how sustained visibility compounds into long-term authority treats as a competitive advantage, run in reverse and pointed at a build system. Reputation is an access-control layer. Most engineering organizations have never once reviewed the permissions it grants.

The Longest Con in Modern Infrastructure

The xz-utils incident, CVE-2024-3094, is usually filed under "supply chain attack." That framing undersells it. The technical payload was elegant — an IFUNC resolver hijacking RSA_public_decrypt at runtime, activating only on x86-64 glibc systems built with dpkg or rpm, obfuscated inside binary test fixtures and a modified build-to-host.m4 that appeared only in release tarballs and never in the public Git tree. That's good tradecraft. It is not the interesting part.

The interesting part is the two-and-a-half-year account warm-up that preceded it. First contribution: October 2021. First authored commit: January 2022. Then months of legitimate, genuinely useful work — code review, translations, CI maintenance, infrastructure cleanup. Around mid-2022, a cluster of accounts with thin histories and suspiciously recent creation dates appeared on the xz-devel mailing list, complaining about slow release cadence and pressuring the sole maintainer to bring on help. One of them wrapped the pressure in sympathy about the maintainer's mental health while insisting the community deserved more. That maintainer was one unpaid volunteer looking after a library embedded in essentially every Linux system in existence.

He relented. Commit access followed, then release authority. The backdoor commit landed 22 January 2024; version 5.6.0 shipped 24 February. It was caught on 28 March by a Microsoft engineer benchmarking PostgreSQL who noticed SSH logins were taking about half a second too long and refused to let it go.

The attacker did not bypass the trust model. The attacker satisfied it. Every gate the ecosystem had was social, and every one of them was cleared honestly.

Then the Attackers Automated the Social Layer

If xz was the artisanal version, September 2025 was the industrial one. A self-replicating npm worm nicknamed Shai-Hulud began harvesting credentials from developer machines and CI runners, then using the stolen npm tokens to publish poisoned versions of every other package the victim maintained. No operator in the loop. CISA's alert on the npm ecosystem compromise put the initial blast radius above 500 packages and told organizations to pin dependencies to releases published before 16 September 2025 and rotate every developer credential they had.

It kept evolving. The December 2025 wave moved execution into the preinstall phase, so the payload ran before tests or scanners ever got a turn. It dropped a Bun runtime, registered a self-hosted GitHub Actions runner, and used TruffleHog against the victim's own filesystem. Microsoft's Defender research team documented the campaign in detail, including a detail that ought to be taught in every onboarding session: some malicious commits were authored under the name "Linus Torvalds." A display name is not an identity. It never was.

The 2026 variants got worse. Later waves spanned npm and PyPI simultaneously, installed persistence hooks into local AI coding tools so every future session re-executed the payload, and — in at least one documented case — shipped malicious packages carrying valid SLSA Build Level 3 provenance attestations, because the release pipeline itself was the thing that got hijacked. Provenance proved the artifact came from the expected pipeline. It did not prove the pipeline was still yours.

The Number That Explains Everything

Here is the structural fact under all of this. Tidelift's maintainer research has found, across multiple years, that roughly 60% of open source maintainers are unpaid, and that unpaid maintainers overwhelmingly work alone. The same research found paid maintainers were about 55% more likely to have implemented core security practices — the gaps are stark on exactly the controls that matter here, including published security disclosure plans and signed releases with artifact provenance.

Read that against the xz timeline and the picture resolves. A social-engineering campaign targeting an exhausted solo volunteer is not a sophisticated attack. It is the cheapest available attack, and it is cheap because the ecosystem has spent two decades extracting enormous value from people it declined to pay. Roughly 60% of maintainers report having quit or seriously considered quitting. Every one of those exits is a project looking for a new maintainer, which is to say a project with an open application process for adversaries.

Hardening the Layer You Cannot Compile

Concrete things that actually change the risk profile, roughly in order of effort-to-benefit:

Add a soak period. New versions sit for 24–72 hours before your builds adopt them. Nearly every worm in this family was caught within that window.
Kill install scripts by default (npm ci --ignore-scripts) and allowlist the handful of packages that genuinely need them.
Move from long-lived tokens to trusted publishing / OIDC, and require WebAuthn rather than TOTP for publish operations.
Treat CI secrets as already-leaked. Short TTLs, narrow scopes, no ambient cloud credentials on build runners.
Verify commit signatures, because display names are free and signatures are not.
Audit maintainer concentration in your dependency tree — a bus factor of one is a security finding, not a trivia fact.
Fund the maintainers you depend on, which is the only item on this list that reduces the attack surface rather than merely observing it.

What This Means If You Are the One Being Trusted

Flip the perspective. If you ship a library, run a dev tool company, or maintain anything other people build on, the same mechanics apply to you, just with the polarity reversed.

Your credibility is what buys you the benefit of the doubt during an incident, the willingness to upgrade, the assumption of good faith when something breaks at 3am. It is also, uncomfortably, the thing an attacker would inherit if they compromised your publishing pipeline. Both facts point to the same discipline: make your identity verifiable rather than merely familiar. Signed releases. A SECURITY.md with real response timelines. Named humans attached to decisions. Provenance you can explain. A public record of how you behaved the last time something went wrong.

That work is slow and it does not trend. It also cannot be faked on a two-year timeline by a determined adversary, which is more than can be said for a friendly commit history.

The Uncomfortable Conclusion

We spent years building cryptographic verification for artifacts and almost none for the humans authorized to produce them. Sigstore, SLSA, and SBOMs all answer "did this come from where it claims?" None of them answer "should that place still be trusted?" The 2026 attestation-carrying worm demonstrated that gap in production.

The honest position is that trust in software is transitive, unmonitored, and granted mostly by vibes accumulated over time. Attackers understood that before we did. The defense is not more suspicion of strangers — open source dies without newcomers. The defense is making trust explicit, revocable, observable, and, wherever money is involved, actually paid for.

Check your package-lock.json. Then check who maintains the top twenty entries, and whether any of them have posted in the last six months.

The Largest Schema Extension Experiment in History Has Been Running Since 2009

Sonia Bobrik — Thu, 10 Sep 2026 00:55:02 +0000

Somewhere in your codebase there is a column named custom_field_3, a JSONB blob called metadata, or a plugin API that lets integrators define their own event types. Every extensible system eventually runs into the same question, and most of us only ever guess at the answer: what happens to the consumers downstream once everybody starts extending? We don't actually have to guess. The answer has been measured continuously, at national scale, in public, for over fifteen years — and it matters more now than it did, because the evidence gathered on why losing a single analyst quietly reprices an entire company shows the human interpretation layer thinning out fastest at exactly the organizations least able to absorb the loss. What's left reading your output is a query. This is about whether your data shows up in it.

The Setup, in Terms a Backend Engineer Will Recognize

Since 2009, every public company in the United States has had to submit its financial statements in XBRL, an XML-based markup format. Strip away the accounting and the architecture is familiar: roughly eight thousand independent organizations write records against one shared, versioned schema — the US GAAP taxonomy, republished annually by the FASB — and the whole corpus is exposed through a free public REST API with no authentication and no keys.

The endpoints are worth knowing even if you never touch finance. The SEC's own API documentation covers three: companyconcept for one field from one filer, companyfacts for everything one filer has ever reported, and frames, which is the interesting one — it slices a single concept across every reporting entity for a given calendar period, snapping each filer's ragged fiscal calendar onto a common grid. Fair-access rules cap you at ten requests per second and require a User-Agent header that identifies you by name and email. Bulk ZIPs rebuild nightly around 3am ET.

And buried in that documentation is the sentence this whole article hangs on. The aggregation APIs only include facts that use a non-custom taxonomy — us-gaap, ifrs-full, dei, srt — and that apply to the entire filing entity. Everything else is silently absent.

Companies are permitted to extend the schema. The query layer just doesn't carry the extensions.

The Rule Nobody Follows

The regulation governing extensions is unusually blunt for a legal text. Under Regulation S-T, a filer must create a custom element if and only if no appropriate standard tag exists. Not "if it fits better." Not "if the label reads nicer." The rule explicitly rejects an inappropriate standard label as sufficient justification on its own.

So how often does a system with a legally-mandated "extend only when strictly necessary" clause actually get extended? The SEC's Division of Economic and Risk Analysis has published the number every year for a decade. Across annual reports from 2016 through 2024, average custom tag rates hover in a narrow band of roughly 16 to 22 percent depending on filer category and year, with a visible bump around 2020 and a modest decline through 2024.

Read that again in engineering terms. Roughly one in five line items in the corpus is a bespoke field, in a system where bespoke fields are supposed to be the exception. If a product manager told you 20% of your API's payload keys were vendor-specific extensions, you would not describe that schema as standardized. You would describe it as forked eight thousand ways.

Extension Rate Is a Property of Your Tooling

Here's where the data stops being merely interesting and starts being a lesson.

The averages hide the tail. When DERA staff went looking in 2014 for filers whose custom tag rate exceeded 50% — meaning more than half of their line items were invented fields — smaller filers made up 96% of that group. Staff review of the large filers with high extension rates generally found the extensions justified. Among the small ones, they found systematic evidence of custom tags created where a perfectly good standard tag already existed. And the staff pointed at a cause that has nothing to do with accounting: many of those filers had routed their submissions through the same handful of third-party filing vendors.

The trend lines say the same thing more quietly. Through 2019 and 2020, large accelerated filers' extension rates moved around while smaller reporting companies climbed steadily year over year. The gap wasn't driven by small companies having genuinely stranger businesses than large ones. Large companies had teams and software that pushed back. Small companies had a vendor whose importer made "create new element" the path of least resistance.

Any engineer who has inherited a database where half the columns are attr_1 through attr_12 already knows this story. Extension rate is not a measure of how unique your domain is. It is a measure of how cheap your tooling made the escape hatch relative to the effort of finding the right existing field. Make the escape hatch one click and it becomes the default. Ship a search that surfaces the correct standard field in under three seconds and it stops being the default.

What It Costs to Be in Your Own Namespace

The consequence is concrete and easy to demonstrate:

UA='Jane Dev jane@example.com'

# Every filer that reported the standard Revenues concept for CY2024Q1
curl -s -H "User-Agent: $UA" \
  'https://data.sec.gov/api/xbrl/frames/us-gaap/Revenues/USD/CY2024Q1.json' \
  | jq '.data | length'

# Now inspect which namespaces the API will even acknowledge for a filer
curl -s -H "User-Agent: $UA" \
  'https://data.sec.gov/api/xbrl/companyfacts/CIK0000320193.json' \
  | jq '.facts | keys'
# -> ["dei","us-gaap"]   ...and that is the entire universe.

That second call is the punchline. No matter how many bespoke elements a company defined, the response keys are a short list of standard taxonomies. The company's own namespace is not there and never will be. The number was disclosed. It was filed correctly. It passed validation. And it is invisible to every consumer working through the aggregation layer, which increasingly means every consumer at all.

For a large company this is a rounding error, because a dozen analysts read the raw exhibit anyway and translate it by hand. For a company with thin coverage and no analysts left, the aggregation layer is the only reader. The organizations extending hardest are precisely the ones with the least human interpretation left to compensate.

Europe Shipped a Fix Worth Stealing

The EU hit the same wall with its own mandate and responded with a design pattern rather than a prohibition. Under the European Single Electronic Format, an issuer may still create extension elements, but each one must be anchored to the closest standard taxonomy concept — a relationship recorded in the definition linkbase, so a consumer encountering an unknown element can walk the edge to a canonical one it does understand. When ESMA published its 2024 update to the ESEF Reporting Manual it tightened this further, clarifying that anchors must point to a core element sharing the same data type.

That is a genuinely good piece of schema engineering, and it generalizes far beyond filings:

Don't ban extension, require a mapping — a custom field with a declared edge to a canonical field is queryable; one without is a dead end
Enforce type compatibility on the mapping — an anchor from a monetary value to a text block is worse than no anchor, because it looks valid
Store the mapping in the schema, not the documentation — a relationship a machine can traverse survives; a wiki note explaining what acme_adj_ebitda_v2 means does not
Instrument your extension rate and watch it by customer segment — the segment with the highest rate is telling you where your standard fields or your UI are failing
Promote recurring extensions into the standard on a schedule — the FASB adds elements annually precisely because a static core schema guarantees a growing fork

The Reader You're Actually Writing For

The financial story and the engineering story converge on the same point. When a market loses the analysts who used to read a company's filings and translate the idiosyncratic bits into something comparable, the surviving reader is a program that queries standard fields and moves on. Anything sitting in a private namespace isn't judged harshly — it simply isn't seen. That is a worse outcome than being criticized, because it produces no signal at all.

Your API has the same structure. Somewhere downstream, a consumer is running the equivalent of a frames query against your standard fields, and whatever your users buried in metadata is not in the result set. The question worth asking on your own schema this week isn't whether extension is allowed. It's what percentage of the payload is currently extension, whether that number is being driven by real domain complexity or by an autocomplete that's easier to ignore than to use, and whether anything custom carries an edge back to something canonical. Those three numbers are cheap to compute and, on the evidence of eight thousand companies filing for fifteen years, nobody computes them until the humans who used to paper over the mess are already gone.

Your Feature Has a Cost Per Execution. Why Isn’t It in the Code?

Sonia Bobrik — Tue, 18 Aug 2026 15:30:38 +0000

A strange thing happens inside modern software companies: engineers can tell you the latency of an endpoint to the millisecond, but often nobody can tell you what executing that endpoint actually costs. That gap matters more than it used to. The broader financial discipline described in Business Finance That Actually Prevents Failure becomes much more concrete when applied at the software layer, because a growing number of products now accumulate real costs every time a user clicks a button, uploads a file, generates an image, runs a search, sends a message, or asks an AI model a question. A feature can be technically successful, heavily used, loved by customers—and economically terrible.

For decades, software benefited from an attractive assumption: once the product was built, serving one more user was comparatively cheap.

That assumption has not disappeared, but it has become dangerously unreliable.

A modern application may call an LLM, invoke an OCR service, generate embeddings, query a vector database, send an SMS, use a geocoding API, process an image, write logs to an observability platform, transfer data across regions, run a serverless function, store the result, and pay a transaction fee before the user sees a single response.

Each component might look inexpensive in isolation.

The feature is not.

We Still Design Features as if Compute Were Free

Imagine a startup selling an AI document-analysis product for $49 per month.

The product team launches a feature called “Deep Review.” Users upload contracts and receive a detailed analysis.

Engagement is excellent.

Customers love it.

Usage grows rapidly.

Everyone celebrates.

But one Deep Review is not one operation. Behind the button, the system might extract text, classify pages, call a large model several times, generate embeddings, search stored context, call another model to verify the answer, save the output, and retain the source document.

Assume, purely as an example, that an ordinary review costs the company $0.18 to process.

That sounds irrelevant.

Then someone uploads a huge document.

It needs multiple OCR passes. Chunking creates dozens of model calls. A retry fires after one provider times out. The verification step receives far more context than expected. That review costs $1.40.

A customer on the $49 plan runs 70 of them.

The customer has paid $49.

The company may have spent close to the entire subscription price on one feature before paying for databases, support, engineering, payment processing, salaries, or anything else.

The feature has not failed.

Its economics have.

This is one of the most important architectural changes developers need to recognize: in a metered software stack, product behavior and financial behavior are no longer separate systems.

“Cloud Bill” Is Too Coarse a Data Type

A monthly infrastructure bill tells you approximately as much about product economics as total CPU utilization tells you about which endpoint is slow.

You need attribution.

If the company spends $80,000 on infrastructure, the interesting questions are not limited to “Why is AWS expensive?” or “Can we reduce the bill by 10%?”

The interesting questions are:

Which customers caused the spend?

Which workflows caused it?

Which product tier generated it?

Which release changed it?

Which feature creates the highest gross profit?

Which popular feature becomes less profitable as usage increases?

Which customer appears valuable in the CRM but loses money after its actual resource consumption is included?

This is not merely a finance problem. AWS’s work on SaaS cost attribution makes the architectural implication clear: understanding resource consumption at the tenant and feature level can influence pricing, product decisions, and architecture itself.

That is a radically better framing than “engineering needs to reduce cloud costs.”

Cost is not something finance discovers after engineering has finished building.

Cost is an output of the architecture.

Cost Should Travel With the Request

Most applications already propagate context through their systems.

A request may carry a user ID, tenant ID, trace ID, session ID, request ID, experiment ID, region, and application version.

Why not economic context?

Suppose an AI workflow generates an event after each billable or resource-intensive operation:

{
  "tenant_id": "tenant_482",
  "feature": "deep_review",
  "operation": "contract_analysis",
  "provider": "model_provider",
  "model": "large_model",
  "input_units": 43820,
  "output_units": 6140,
  "estimated_cost": 0.173,
  "request_id": "req_91af",
  "release": "2026.08.18"
}

This is not intended to replace the provider's invoice.

It solves a different problem.

The invoice tells you what the company owes.

Application-level cost attribution tells you what created the obligation.

Once that information exists, entirely new questions become easy to answer.

You can compare feature revenue with feature cost. You can identify customers whose usage patterns are structurally different from everyone else's. You can discover that a new release increased the cost of a workflow. You can compare two implementations not only on latency but on cost per successful outcome.

Most importantly, engineers gain a feedback loop.

Without that loop, architecture has financial side effects that remain invisible until someone notices the monthly bill.

The Most Dangerous Customer May Be Your “Best” Customer

SaaS dashboards train teams to celebrate heavy users.

More sessions.

More queries.

An Infinite Loop Can Now Appear on the Income Statement

Software engineers already protect systems against technical runaway conditions.

We limit recursion.

We set timeouts.

We cap retries.

We rate-limit APIs.

We kill jobs that run for too long.

We stop queues from expanding indefinitely.

But consider an AI agent.

The agent receives a task, calls a model, invokes a tool, reads the result, decides it needs more information, calls another tool, queries the model again, retries an unsuccessful step, expands its context, and repeats the cycle.

From a technical perspective, the workflow may still be functioning exactly as designed.

From an economic perspective, it may have entered a runaway loop.

This produces a new category of engineering requirement: financial bounds.

An operation should not only have a timeout. It may need a cost ceiling.

A job should not only have a maximum retry count. It may need a maximum cumulative inference budget.

A customer should not only have an API rate limit. The application may need a resource budget based on the economics of the customer's plan.

A feature should not only satisfy latency and reliability requirements. It may need an acceptable cost-per-successful-execution range.

That sounds obvious once stated.

It is rarely treated as a first-class software requirement.

Put Economics Into the Pull Request

Here is where things get more interesting.

Suppose a developer improves an AI workflow.

The old implementation makes one expensive model call.

The new implementation performs five smaller calls because the developer discovers that decomposition improves answer quality.

The accuracy benchmark improves 8%.

The latency remains acceptable.

Tests pass.

The pull request looks excellent.

But suppose the cost per successful workflow rises from $0.11 to $0.39.

Is the new version better?

There is no universal answer.

If customers pay $20 every time the workflow succeeds, almost certainly.

If it is included without limits inside a $9 monthly plan, perhaps not.

The point is that the economic regression belongs in the engineering discussion.

Teams already reject code because it creates unacceptable latency, memory consumption, security exposure, or reliability risk.

Why should a 250% increase in variable cost remain invisible?

For measurable workflows, teams can go surprisingly far with simple tooling.

A benchmark suite can record the number of external calls.

It can record input and output units.

It can estimate compute duration.

It can compare those values with a baseline.

It can flag a pull request that makes a common workflow dramatically more expensive.

Not every cost estimate will be perfect. It does not need to be.

A smoke detector does not need to calculate the insurance value of the house before it becomes useful.

The Database Query That Saves $50,000 Is Still an Optimization

Developers frequently debate optimization using technical language.

This query is 200 milliseconds faster.

This cache reduces database load.

This architecture supports more requests per second.

This model produces better answers.

Those are legitimate improvements.

But at sufficient scale, some of the highest-impact performance work may be invisible when measured only in milliseconds.

Imagine that a high-volume request performs three redundant database operations. Removing them saves an amount so small per request that nobody cares during development.

Multiply that amount across hundreds of millions of executions.

Now it matters.

Or imagine that an image-processing workflow keeps the original, intermediate files, generated variants, and debug artifacts forever.

Nothing breaks.

Storage simply compounds.

Or a tracing configuration sends huge payloads for successful requests that nobody will ever inspect.

Or an AI application sends an entire conversation history back to a model even when only a small section is relevant.

Technically, the product works.

Economically, the implementation contains waste.

The important shift is not “developers should always choose the cheapest architecture.”

That would be bad engineering.

The shift is: developers should be able to see the economic consequence of architectural choices.

Sometimes paying more is absolutely correct.

A more expensive model may improve conversion enough to justify itself.

Additional redundancy may be essential for reliability.

Lower latency may generate enough business value to justify significantly higher infrastructure spend.

Premium observability may reduce incident duration.

The goal is not minimum cost.

The goal is deliberate cost.

“Unlimited” Is an Engineering Decision

Product teams love the word “unlimited.”

Customers do too.

Engineers should hear something else when they see it:

What technically prevents one user from consuming 10,000 times more resources than another user paying the same price?

Sometimes the answer is that nothing prevents it because marginal cost really is negligible.

Fine.

Sometimes the answer is that extreme usage is statistically rare enough that the economics still work.

Also fine.

But sometimes “unlimited” simply means nobody modeled the tail.

Average users are frequently irrelevant to infrastructure risk. Outliers matter.

The same principle appears in performance engineering.

A system with a 100 ms average response time can still be terrible if its tail latency is 12 seconds.

Product economics also have tails.

The average customer may cost $6 per month to serve while the top one percent costs $90.

If pricing was designed around the average, growth can gradually select for the customers who exploit the mismatch most effectively.

That is not abuse.

They are using the product you sold them.

Build a Cost Map Before You Build a Cost Dashboard

You do not need a massive FinOps implementation to start.

You need to understand where money enters the execution path.

For one important customer action, trace the full chain from click to result and identify every resource whose cost changes with usage.

For example:

Trigger: user requests a video analysis
Variable work: upload, transcoding, model inference, object storage, database operations, data transfer, notifications
Cost driver: video duration, resolution, model runtime, generated output size
Customer dimension: tenant, plan, geography, contract type
Product dimension: feature, workflow version, experiment
Business output: successful analysis, revenue associated with usage, gross contribution

That is the only list this article needs because the important part comes afterward.

Instrument one workflow.

Not the entire company.

Pick the feature that is expensive, rapidly growing, strategically important, or difficult to understand.

Then ask a question most teams cannot currently answer:

What happens to our gross profit if usage of this exact feature increases 10x tomorrow?

If the answer requires three people, two spreadsheets, a cloud invoice, and a week of analysis, the architecture is hiding business-critical information.

The Best Architecture May Depend on Who Is Using It

Cost attribution also complicates a sacred engineering instinct: finding the single “best” implementation.

There may not be one.

An enterprise customer paying $50,000 per year might justify a computationally expensive workflow that produces the highest possible accuracy.

A self-service customer paying $12 per month may need a different model, smaller context window, lower retention period, asynchronous processing, or stricter usage limits.

That is not necessarily an inferior product.

It is resource allocation.

Cloud architecture already changes resources according to workload. Product architecture can do the same according to economics.

Model routing is an obvious example.

A request does not automatically need the most capable model available.

A lightweight classification might go to a smaller model. An ambiguous case can escalate. A high-value workflow can justify a more expensive path. Repeated context can be cached. Inputs can be compressed. Work that does not require immediate completion can be batched.

The interesting engineering problem becomes:

What is the cheapest execution path that still delivers the required outcome?

That is much better than asking engineers to “cut AI costs.”

Your Unit Test Knows Whether the Function Works. It Could Also Know Whether the Business Model Still Works.

Software development has spent decades moving failure detection earlier.

We moved testing from users to QA.

Then from QA to automated test suites.

Then into continuous integration.

We moved security checks into development pipelines.

We moved dependency scanning into pull requests.

We moved performance benchmarks closer to the code.

The same direction makes sense for variable product economics.

A feature whose economics are only discovered on a monthly invoice has a feedback loop measured in weeks.

A feature whose resource consumption is measured during development has a feedback loop measured in minutes.

That does not mean putting the CFO in GitHub.

It means recognizing a simple truth:

In modern metered software, cost is increasingly a runtime property.

Runtime properties belong close to engineering.

The Next Generation of Great Developers Will Understand the Machine and the Meter

There was a period when a developer could reasonably treat infrastructure economics as someone else's concern.

Servers were purchased centrally. Finance handled contracts. Product set pricing. Engineering built the application.

Cloud computing already weakened that separation.

Serverless weakened it further.

API-first software weakened it again.

AI may finally destroy it.

A developer can now add a few lines of code and change the company's variable cost structure instantly. Choosing a different model, changing context length, adding a second validation pass, moving data between regions, retaining files longer, increasing observability volume, or introducing a third-party API can alter the economics of a feature without changing its price by one cent.

That gives engineers more responsibility.

It also gives them more influence.

The developer who can say, “This version is faster,” is useful.

The developer who can say, “This version is faster, improves successful completion by 6%, and reduces cost per successful task by 31%,” is participating in the business at an entirely different level.

The future of software engineering is not about turning developers into accountants.

It is about giving architecture one more observable property.

We already measure whether software works.

We measure how fast it works.

We measure whether it is available.

We measure whether it is secure.

Now, for the growing class of software in which every meaningful action consumes metered resources, we should measure one more thing:

Was executing it worth what it cost?

The Most Dangerous File in Your Repo Might Be SECURITY.md

Sonia Bobrik — Tue, 18 Aug 2026 12:41:53 +0000

Developers write far more legally consequential prose than they think, and almost none of it is code. It's the SECURITY.md in the repo root. It's the "Security" page someone in marketing asked you to fill in three years ago. It's the status page update typed at 2 a.m., and the sentence in a customer notice specifying exactly which data was affected. The research summarized in this overview of what the evidence shows about cyber incident disclosure treats post-breach communication as a measurable discipline with predictable failure modes — and the enforcement record of the last three years has quietly turned it into an engineering discipline too. In the most closely watched cybersecurity case of the decade, the only allegation that survived a motion to dismiss concerned a technical description of access controls posted on a website.

The claim that survived was written by engineers

On July 18, 2024, Judge Paul Engelmayer of the Southern District of New York issued a 107-page opinion in the SEC's case against SolarWinds and its CISO. Most of it was a defeat for the agency. Claims built on blog posts, press releases, and podcast appearances were dismissed as non-actionable corporate puffery — statements too general for any reasonable investor to lean on. The theory that cybersecurity controls fall under "internal accounting controls" was rejected outright. Post-incident 8-K disclosures were held to be reasonable given what was knowable at the time.

One thing lived: the company's "Security Statement," a technical page describing its practices to customers. The court let claims proceed specifically on its representations about access controls and password policy, because those were concrete enough to rely on and, as pled, contradicted by internal presentations, security assessments, and Slack messages. The SEC ultimately dismissed the whole action with prejudice in November 2025, so no liability was ever established — but the legal line drawn in 2024 didn't go anywhere. Vague marketing language is protected precisely because it says nothing. The specific, verifiable technical claim is the one with teeth.

Read that sentence again if you maintain a trust page. "We take security seriously" is legally inert. "All administrative access requires MFA" is a factual assertion about your infrastructure that someone will one day compare against your actual IAM configuration, your Jira backlog, and your team's Slack history.

A file-name review became a false public statement

The second case is more uncomfortable, because the mistake was a technical judgment call that any of us could make under pressure.

Blackbaud discovered a ransomware intrusion in May 2020. To scope it, technology staff reviewed the names of exfiltrated files rather than analyzing their contents. Based on that review, the company posted a notice in July 2020 telling customers the attacker had not accessed bank account information or Social Security numbers. Then customers began writing in — over a thousand messages — many pointing out that they had entered sensitive data into fields the software did not encrypt. Deeper analysis confirmed unencrypted bank account details and Social Security numbers had in fact been taken. That finding never reached the people responsible for the company's public disclosures, and the website statement stayed uncorrected while a later quarterly filing described data-exfiltration risk as hypothetical. The SEC's settled order imposed a $3 million penalty in March 2023, without alleging intentional misconduct.

There is no villain in that story. There is a scoping shortcut, a schema assumption ("that field holds notes, not SSNs"), and a missing edge in the org chart between the person who learned the truth and the person who had published the falsehood. All three are engineering artifacts.

It is not only a public-company problem

Anyone at a startup assuming this is a Fortune 500 concern should read the FTC's finalized order against GoDaddy from May 2025. The agency's theory was straightforward: the company advertised "award-winning security" while lacking multi-factor authentication, threat monitoring, and secure connections for customer data. Section 5 of the FTC Act reaches any company making deceptive claims, private or public, seed-stage or not. The remedy reads like a backlog someone else wrote for you — mandatory MFA including at least one method that doesn't require a phone number, HTTPS on APIs handling covered information, an update-management program, biennial third-party assessments, and incident reporting to the Commission within ten days.

Why silence is not the safe default

The instinct after reading all this is to say nothing about security anywhere, ever. The empirical record argues the opposite. In a study published in the Review of Accounting Studies, Amir, Levi, and Livne compared attacks companies disclosed themselves against attacks that were concealed and later surfaced by outsiders. Withheld incidents were associated with roughly a 3.6% decline in equity value in the month of discovery; disclosed incidents, around 0.7%. Their model also suggested managers tend to speak only once outsiders already suspect an attack with about 40% probability — meaning the incidents that stay hidden skew toward the severe ones, and the "breaches don't really hurt stock prices" folk wisdom is built largely on the mild cases that got announced.

So the goal is not silence. It is writing things that stay true under adversarial reading:

Describe controls that are enforced, not intended. If MFA is required for 94% of admin accounts, the honest sentence names the exception. A published claim your own audit log contradicts is the exact shape of every case above.
Version your security page like code. Keep it in the repo, require review, and let git log prove when each claim was accurate. An undated marketing page is a permanent unqualified assertion.
Never scope a breach by metadata alone. File names, table names, and bucket paths describe intent, not contents. Users put card numbers in "comments" fields. Verify before publishing a negative.
Prefer "we have confirmed X" over "Y did not happen." Negative claims require exhaustive verification; positive claims about confirmed findings age gracefully as the investigation continues.
Make correction a defined path, not a favor. Whoever discovers the earlier statement was wrong needs a named recipient and an obligation to use it. Blackbaud's penalty rests substantially on that link being absent.
Assume Slack is exhibit A. Internal messages contradicting public claims were central to the surviving SolarWinds allegation. Write internally as though it will be read aloud, not because you're hiding anything, but because accurate internal writing is what makes accurate public writing possible.

The uncomfortable summary

Nothing in the enforcement record punishes being breached. Courts and regulators accept that competent organizations get compromised. What draws liability is the delta between what a company published about itself and what its own engineers knew — a gap authored, almost always, by people writing documentation rather than exploits.

The fix isn't legal review of everything. It's treating security documentation as a claim about a system, with the same expectation of verification you'd apply to any other assertion about production. If you can't point to the control that makes a sentence true, delete the sentence.

The Engineering Principle Your Startup's Balance Sheet Is Missing

Sonia Bobrik — Tue, 18 Aug 2026 12:36:54 +0000

Developers spend years internalizing a simple truth: unreadable code eventually kills a project, no matter how clever it is. What most of us never notice is that the same law governs the business wrapped around our code, and a recent piece arguing that the real financial edge is legibility, not growth, makes that connection impossible to ignore. A company whose finances cannot be read quickly by an investor, a lender, or a senior engineer deciding whether to accept an offer is carrying the corporate equivalent of a 4,000-line function with no tests. It might run today. Nobody can safely bet on it tomorrow.

Why Engineers Should Care About a Finance Concept

If you write software for a living, your salary, your equity, and your roadmap all sit downstream of decisions made by people reading your company's numbers. When those numbers are confusing, the confusion does not stay in the finance department. It shows up as a hiring freeze announced without warning, a "strategic pivot" that kills the service you spent a year building, or a funding round that closes on brutal terms because investors priced in uncertainty.

Paul Graham captured the core question years ago in his essay on whether a startup is default alive or default dead: given current growth and current spending, does the company reach profitability before the money runs out? What is striking about that framing is how few founders can answer it, and how few engineers ever think to ask. Legibility starts exactly there. A financially legible company can answer that question in one sentence, with numbers, on any given Tuesday.

The parallel to software is almost mechanical. Technical debt is the gap between how a system behaves and how easily that behavior can be understood. Financial illegibility is the gap between how a business performs and how easily that performance can be verified. Both compound quietly. Both feel free right up until the moment someone external needs to evaluate you, whether that is a new team member reading the codebase or a bank reading the ledger.

Reading a Company the Way You Read a Codebase

Engineers already own the mental tools for this. You know how to trace data flow, distinguish signal from noise, and spot the difference between a system that works and a system that merely demos well. Applied to a business, that skill set translates into a short review checklist worth running before you join a startup, accept equity in place of cash, or push your own side project toward incorporation:

Trace the cash, not the revenue. Revenue is a promise; cash arriving in the account is the merged pull request. Ask how long the gap is between "customer signed" and "money landed."
Check the dependencies. One customer generating 40% of income is a single point of failure, exactly like one unmaintained library holding up production.
Look for observability. Can leadership produce current runway, gross margin, and burn within a day? If the answer requires "pulling some things together," the monitoring stack is fiction.
Read the error handling. How does the company behave when a big invoice is paid late? Improvised panic is a smell; a documented playbook is a feature.
Inspect the interfaces. Do the story told to investors, the story told to employees, and the actual ledger describe the same system? Divergence between docs and code is always a warning.

That is the only list you need, because the underlying move is singular: treat the business as a system under review and refuse to accept "trust me, it's fine" as a substitute for readable state.

Working Capital Is Just Memory Management

The least glamorous concept in this whole domain turns out to be the most decisive one. Working capital, which Investopedia defines cleanly as the difference between current assets and current liabilities, is effectively a company's available RAM. Inventory sitting in a warehouse is allocated memory doing nothing. Unpaid invoices are pointers to money that exists in theory. A business can post impressive growth while leaking working capital the way a service leaks memory: everything looks fine on the dashboard until the process gets killed at 3 a.m.

For anyone freelancing or running a small SaaS, this stops being an analogy and becomes daily reality. Invoicing the day work ships, setting payment terms before delivery rather than after, and knowing your personal runway to the week are not accounting chores. They are the financial equivalent of writing tests before merging: small disciplines that make your entire operation auditable by anyone, including future you.

Legibility Is a Feature You Can Ship

Here is the optimistic ending, and it is genuinely optimistic. Unlike growth, which depends heavily on market luck, legibility is fully within your control. You can ship it. A one-page document explaining how your project makes money, a spreadsheet that reconciles with the bank account, a public changelog of pricing decisions, a straight answer to the default-alive question: each of these is a pull request against the fog.

The companies and the individual developers who win the next few years will not necessarily be the fastest-growing ones. They will be the ones that are easiest to believe, because every claim they make can be traced to evidence in constant time. Make your finances as readable as you wish every codebase were, and you will have built the rarest asset in a skeptical market: a story that survives code review.