Mapping every red-team finding onto an ML attack taxonomy 'for coverage' — what does a full grid establish?
answer
- a vocabulary, not a checklist
- cells are not equally reachable
- labels on results, not boxes to fill
- start from what your deployment exposes
- most cells should be legitimately empty
basics
~20 sAlmost nothing about the model's exposure. A filled grid records which experiments someone chose to run and had vocabulary for. A taxonomy classifies the assumptions a result was obtained under; it is not a checklist whose completion measures anything.
solid answer
~50 sA full grid establishes that your team wrote something in every box. It does not establish coverage, because the cells are not equally reachable in your deployment, not equally severe, and not exhaustive — and one finding that reproduces once in five tries fills a cell exactly as well as a reliable one. The value of a shared classification of ML attacks runs the other way: it tags each result with the adversary it assumed — what they could see, how much they could touch, at which stage — so that this quarter's result is comparable with last quarter's and with a supplier's claim. Coverage is a different exercise: list the adversaries your deployment actually exposes, which is a much shorter list, and ask which of those anyone has tested. Most cells will be legitimately empty, and one or two deserve repeated work.
go deeper
Recall that a classification of ML attacks is a shared vocabulary for stating what a result assumed, not a checklist, and that filling boxes is not the same as testing your system.
Be able to explain why cells are unequal — different reachability, different severity, different reproduction rates — and why that makes a completion percentage meaningless.
Show the reviewer's move: build the exposure list from the deployment first, mark which taxonomy cells it can even reach, and record access, budget, stage and reproduction rate on every finding.
Own the reporting change. Once completion becomes a metric it gets gamed, so replace the number that leaves your team with an exposure-based one before someone else picks the grid.
## What a classification of ML attacks is actually for A taxonomy of adversarial-ML attacks — the NIST adversarial-ML taxonomy is the usual reference — cross-cuts three things: the stage the adversary acted at, what they were trying to achieve, and what they were assumed to know and be able to reach. That structure exists so that two people arguing about an attack can find the assumption they actually disagree about. It is a vocabulary for stating conditions, and a result stated without its conditions cannot be compared with any other result. It is not an inventory of everything that can go wrong with your system, and it was never built to be scored. ## Why a filled grid measures nothing Four reasons, and each one is enough on its own. **The cells are not equally reachable.** If nobody outside your organisation can write into the training corpus, the training-stage cells are not gaps in your programme; they are adversaries you do not face. Filling them with contrived exercises spends real red-team hours purchasing a shape on a slide. **The cells are not equally severe.** One cell may hold a finding that flips one input in a demonstration; another may hold a finding that changes behaviour for every input carrying a condition somebody else controls. The grid gives them the same visual weight. **A cell says nothing about the strength of what is in it.** A finding that reproduces once in five attempts fills its box as completely as one that reproduces every time. So does a result obtained by granting the attacker far more than any real adversary has. **The partition is not exhaustive and was not meant to be.** A published taxonomy lags the literature by construction. An attack with no cell is still an attack, and a team trained to work from the grid is trained not to see it. ## The direction the value actually flows Use the axes as *labels on results*, not as *boxes to fill*. Concretely, a finding is worth writing down when it carries: the access the adversary was granted, the budget they worked under in its own unit, the stage they acted at, and the reproduction rate. With those, three things become possible that were impossible before. 1. **Comparison over time.** Next quarter's run of the same exercise sits beside this one, because both name the same assumptions. 2. **Comparison across suppliers.** A vendor's claim can be placed on the same axes, and where it declines to state one, that silence becomes visible. 3. **Disagreement that resolves.** Two engineers who disagree about whether a finding matters usually disagree about the adversary, not the mathematics. Naming the access and the stage ends the argument in a minute instead of a meeting. ## What a coverage exercise looks like instead Start from the deployment rather than the taxonomy. Who can send inputs to this model, and what comes back to them — a label, a score, an attribution? Who can influence what it learns — an open collection pipeline, a labelling queue, a partner feed? Whose checkpoint is in the artefact you serve? That enumeration produces a handful of adversaries that are real for you. Coverage is then a plain question with a plain answer: which of those has anyone actually tested, under what budget, and when. The result is a short list with most of the taxonomy left blank, and that is the correct shape. A programme whose report shows a sparse grid over a well-argued exposure list is in far better condition than one showing a dense grid with no statement of which cells its deployment can even reach. ## What to say when the grid is already a target Once a filled grid becomes a metric, it gets filled — that pressure is structural, not a failure of the people involved. The useful counter-move is to change what the report contains rather than to argue against the grid: publish the exposure list beside it, mark each cell as reachable or not with a one-line reason, and record reproduction rate next to every finding. The grid can stay; it just stops being the number anyone quotes. ## Wrong readings to avoid - An empty cell is not a clean bill of health for that adversary; it usually means nobody ran that experiment. - A full cell is not proof the model is exposed there; the assumptions granted may exceed anything a real adversary has. - Percentage-of-cells-filled is not a coverage figure. It has no denominator anyone can defend, because the taxonomy's cell count is a property of the document, not of your system.
- Leadership wants a percentage of the taxonomy 'covered' — what number do you give instead?Give a count against an exposure list you can defend: the adversaries this deployment actually exposes, how many of those have been tested in the last period, and the reproduction rate of what was found. That denominator is arguable in a meeting; the taxonomy's cell count is a property of somebody else's document.
- What does an empty cell in such a grid most often mean?That nobody ran that experiment. It can also mean the adversary is not reachable in your deployment, which is a legitimate and valuable answer — but only if someone wrote down the reason. An unlabelled empty cell is indistinguishable from an untested one, so the reason is the part worth recording.
- Is the taxonomy useless for planning, then?No — it is useful precisely as a prompt list when you build the exposure map, because it names stages and adversary positions people forget, such as write access to a labelling queue. The failure is scoring completion rather than using it to ask questions. Read it to generate candidates, then test the ones your deployment exposes.
saying these in an interview costs you the question
- Treats cell completion as a coverage metric
- Reads an empty cell as evidence of safety
- Runs contrived exercises for adversaries the system never exposes
- Gives a filled cell the same weight regardless of reproduction rate
- Assumes a published taxonomy enumerates every possible attack