crosswalks: refresh cfgaudit to v1.11.0 (53 rules onto 23 classes)

[predictor2718]

Follow-up to #67, and it closes most of what #68 was tracking.

Coverage

35 rules onto 19 classes → 53 onto 23.

Most of that is not new cfgaudit rules. Five were added in v1.11.0 and three of them map. The other fifteen new mappings are rules that existed all along and now have a home in the four config classes you added from this crosswalk's own gap list:

Record	cfgaudit rules
AVE-2026-00061 TLS verification disabled	CFG075
AVE-2026-00062 unpinned dependency	CFG010, CFG074, CFG055, CFG089
AVE-2026-00063 approval gate bypassed by config	CFG003, CFG004, CFG048, CFG053, CFG063, CFG079, CFG087, CFG091, CFG093, CFG096
AVE-2026-00064 zero-click project-load auto-run	CFG047, CFG067, CFG086

00063 is doing a lot of work, which I take as a sign it was the right class to add.

One mapping moved, on your wording

CFG091 (qwen tools.approvalMode: "yolo") was on AVE-2026-00021, whose text is "a component that explicitly instructs the agent to bypass this confirmation step". It is a setting, not an instruction, and 00063 says it covers the declarative case "independent of any instruction text". Moved. 00021 keeps the instruction-driven rule, CFG029.

The two surfaces you were blocked on

Both are now at mechanism level rather than a topic label, matching what I posted in #68.

Container posture is three mechanisms with no shared detection logic: the daemon redirected off-host (DOCKER_HOST, -H), image trust verification disabled (DOCKER_CONTENT_TRUST=0, --disable-content-trust, --insecure-registry), and a Chromium launcher flag replacing the browser subprocess.

MCP network posture is five: bind-all, wildcard CORS escalating when auth is off in the same env, deprecated sse, a non-loopback proxy, and HTTP transport without log redaction.

Neither is one class. If you pick either up, the daemon redirect and the bind-all case are the highest-value single records.

Two shapes with no class in either direction

Added to the surfaces table because they are the honest leftovers:

• A cleartext endpoint, distinct from TLS verification being disabled. 00061 covers verification switched off; this is no TLS at all. A committed http:// MCP server URL, model base URL, or agent_card_url.
• Natural-language steering of an approval classifier. Cursor's autoRun.allow_instructions is prose the repository feeds to the classifier that decides whether a tool call runs unattended. It falls between 00063 (explicitly not instruction text) and 00021 (an instruction to the agent, not to a gatekeeper).

Three gaps added going the other way

Classes cfgaudit does not cover, recorded so the crosswalk is honest in both directions:

• 00060 and 00069 need server source and binary image analysis respectively, the same layer as 00052, 00053 and 00024.
• 00065 (A2A agent card poisoning) is reachable only as far as the committed pointer. A .gemini/agents/*.md may carry an inline agent_card_json, which cfgaudit recognises well enough to classify the file as a remote agent, but it does not audit the card's contents. It does flag a cleartext agent_card_url and a credential literal in the same file's auth block.

Validation

• crosswalks/cfgaudit-to-ave.json validates against schema/crosswalk-1.0.0.schema.json
• All 29 referenced AVE ids resolve to records in this repo
• All 53 rule-to-class pairs match cfgaudit's cmd/cfgaudit/avemap.go exactly, which is itself drift-guarded on our side by a test that fails if the map and the crosswalk diverge
• Counts taken from dist/ave-records-latest.manifest.json (70 records) and a detection_stage tally (51 static)

One note on cfgaudit's side, since it affects nothing here but is the reason the version moved: v1.11.0 shipped after a false-positive pass over 432 real repositories, which changed two rules. Neither is mapped.

[chaksaray]

Read the full diff, not just the summary. Two things worth raising before merge, one confirmed, one needing a quick answer from you.

Confirmed: the "what cfgaudit reads" column in the markdown table is populated for the four newest mappings (00061-00064) but empty for every pre-existing row, CFG031 through CFG090 all show a blank fourth cell where real descriptive content used to be ("sensitive-path read, env dump, embedded exfil shell" and similar). Looks like an artifact of the refresh rather than intentional. Worth restoring before merge if it's accidental.

Worth confirming: your top-level comment cites 432 real repositories for the v1.11.0 false-positive pass, but the .md gap note for AVE-2026-00036 cites 422 real instruction files for the earlier revert. Could genuinely be two separate passes at different times, that's plausible on its face, just want to confirm rather than assume given how close the two numbers are.

Everything else, the CFG091 remap, the two new surfaces, the coverage arithmetic, checks out on direct read.

[predictor2718]

Both correct. The first one is a bug I introduced, fixed in d489609.

The empty Notes column

I regenerated the markdown table from the machine-readable mapping rather than editing it, and the JSON has no equivalent of that column, so every pre-existing row lost its fourth cell while the four new records kept one. The table had also silently switched from the short class names to the AVE record titles.

Restored the original rows and notes verbatim, then added only what actually changed:

• CFG091 leaves the 00021 row and joins 00063
• CFG097 joins the 00047 row, with its own note
• four new rows for 00061 through 00064

The table diff against main is now two removed lines and five added ones, which is what a mapping refresh should look like. Thanks for reading the diff rather than the summary; a generated table quietly dropping a column is exactly the kind of thing a summary hides.

432 vs 422

Two separate passes. Different dates, different units, different purpose. The numbers landing ten apart is coincidence.

422 real instruction files, 2026-07-22, before v1.10.0. Scoped to files containing network-reconnaissance vocabulary, to decide whether that rule could be made precise enough to keep. It could, but only by requiring an internal, private or subnet target: after tightening it fired on 2 of the 422, both genuine scan <private-IP> directives. That is the pass behind the AVE-2026-00036 gap note, and it is written up in docs/rules/CFG090.md.

432 real repositories, 2026-08-04, before v1.11.0. Scoped to the ten config surfaces that release added, to measure the false-positive rate of pointing existing rule families at files they had never seen. It found one: CFG015 fired on 19 of the 59 repositories carrying a .codex/hooks.json, and 43 of those 46 findings were the identical expression, $(git rev-parse --show-toplevel). Fixed before the tag.

Neither pass touches a mapped rule, so neither changes anything in this crosswalk. Happy to put the distinction in the .md if you want it stated rather than inferable.

[chaksaray]

Checked both gaps you flagged here as "no class in either direction."

Cleartext endpoint (no TLS at all): this turned out to already be covered, not a new record. I checked it against AVE-2026-00061 as the obvious neighbor first and it's genuinely distinct there (00061 is an active downgrade of a present TLS connection, not the same failure mode). But a corpus-wide sweep past that one comparator turned up AVE-2026-00073 (published after your PR was opened) -- its detection_methodology step 3 and remediation already say, verbatim, "reject cleartext http:// destinations... regardless of whether the host itself is otherwise legitimate," and its payload_surface covers "a model/provider base_url config value." So a committed http:// model/provider base URL is already in scope there. AVE-2026-00073 doesn't explicitly name MCP server URLs or agent_card_url in its payload_surface text, only "an equivalent traffic-destination value" as a catch-all -- if you'd find it useful for those two field names to be named explicitly rather than implied, that's a small scope-clarification edit to 00073's own text, not a new ave_id, and I'd rather do that as a deliberate follow-up than unilaterally right now. Let me know if that'd help.

Natural-language steering of an approval classifier (Cursor autoRun.allow_instructions): confirmed as a genuine third category, now AVE-2026-00076. Verified the actual mechanism against Cursor's own docs first (it's a "classifier subagent," not a fully non-agent gatekeeper -- a real correction to the original framing, noted in the record) and ran the three-way provenance_vector comparison against AVE-2026-00021 and AVE-2026-00063 before drafting. Holds up: natural language is the payload (unlike 00063, which is a deterministic boolean flag with zero NL involved), but the target is a separate classifier, not the primary agent (unlike 00021).

Credited to you and this PR in both records' references.