A compliance owner wants all 300 CWE-20 findings closed as one remediation item. What do you argue?
answer
- a label is not a work item
- Class level, so no shared fix
- the closure is the riskier option for them
- sample, do not sweep
- theme yes, unit of closure no
basics
~20 sA Class label is a vocabulary term, not a work item. Three hundred rows sharing it span unrelated resources and unrelated fixes, so closing them together closes nothing. Re-map the dominant ones to Base instead.
solid answer
~50 sThe argument has three moves. First, the factual one: `CWE-20` sits at Class level, so those 300 rows have in common only that something arrived from outside and was used badly — different resources, different consequences, different owners, different code. No single change satisfies them. Second, the honest one: that number is not a defect population, it is an unmapped backlog, and a single closure is a reporting artefact. If an auditor samples three rows and finds three unfixed unrelated bugs, the programme's credibility goes, not just the number. Third, the practical one, because re-mapping 300 rows is not free: sample them, find the two or three Base entries that dominate, turn those into real items with owners, and label the residue unmapped rather than closed. Then settle what the register's unit of closure is — a class label can be a *theme*, but the unit must be something a change can satisfy.
go deeper
Know that many findings can carry the same weakness class without being the same bug. Do not read a count of rows sharing a label as a count of one repeated defect.
Explain why a Class-level label implies no shared change, and what re-mapping to a Base entry adds: a resource, a consequence, and something a fix can satisfy.
Be able to run the triage — sample, find the dominant Base entries, look for a shared upstream component, label the residue honestly — and to defend the resulting numbers under sampling.
Own the negotiation. Decide the register's unit of closure, argue it in the compliance owner's currency of audit risk rather than taxonomy, and fix the intake rule so the same backlog does not regenerate.
## Why this argument keeps happening Someone with an audit deadline is looking at a register with 300 rows carrying the same label. From where they sit, one label is one thing, and one thing can have one owner, one plan and one closure date. The taxonomy invites exactly this reading: it looks like a list of named defects, so a label looks like a defect. It is not, and the gap between those two readings is the whole problem. ## Move one: what the label actually asserts `CWE-20` is a **Class**-level entry. Class-level entries describe a shape of mistake independent of resource and technology, which is why almost any flaw involving something that crossed a trust boundary can honestly be filed under it. Those 300 rows therefore share one property: somebody could describe each of them with the same sentence. They may share nothing else — not a language, not a service, not a team, not a fix. Say this concretely rather than taxonomically. Pull three rows at random and read them out. If one is a parser writing outside a buffer, one is a service that accepts an unbounded field, and one is a job that trusts a filename from a queue, the owner can see for themselves that there is no single change that closes all three. That demonstration wins the argument faster than the abstraction hierarchy does. ## Move two: what a single closure would cost Closing 300 rows as one item produces a number that is true about the register and false about the estate. Two failure modes follow, and the second is the expensive one. - **The reporting failure.** Next quarter the same bugs are re-found and re-filed, because nothing changed. The register now looks like it regressed, and the programme spends its credibility explaining why. - **The assurance failure.** An auditor samples. Sampling a closed item and finding it unfixed does not read as a taxonomy dispute; it reads as a control that does not work. That converts a mapping-hygiene problem into a finding against the programme itself. This is the move that actually persuades a compliance owner, because it is stated in their currency: the single closure is the riskier option *for them*. ## Move three: what you offer instead, given that re-mapping is not free Refusing without an alternative loses. Three hundred manual re-mappings is real work nobody funded, so propose the triage: 1. **Sample, do not sweep.** Read enough rows to find the Base entries that dominate — in most estates two or three do. Those become genuine remediation items: a resource, a consequence, and a change that can be verified. 2. **Look upstream, not per-row.** If forty of the rows are the same mistake made by one shared library or one code generator, the remediation unit is that component, and forty rows close honestly on one change. This is the outcome the owner wanted, arrived at legitimately — and it is only visible once the rows are mapped at Base. 3. **Label the residue, do not close it.** What you did not re-map stays open with an explicit state meaning "class label only, not yet a defect statement". That is an honest number and it is defensible to an auditor. 4. **Fix the intake.** Whatever process is attaching Class labels at creation keeps producing this backlog. Agree a mapping standard — file at the most specific level the evidence supports, Class only as provisional — or the same conversation recurs next quarter with a bigger number. ## What you concede Concede that the class label has real value: as a **theme**, it is exactly how you notice that one shape of mistake dominates your estate, and that is a legitimate input to where training and design effort go. What it cannot be is the unit of closure. Offering the owner a themed view alongside a Base-level register usually settles it, because their actual need is a small number of things to report on, not a specific interpretation of the taxonomy. ## The judgment being tested This question is not about CWE. It is about whether you can hold a line on what a number means when someone with legitimate pressure and no security background needs the number to mean something else — and whether you can do it while giving them a workable path rather than a lecture. The wrong answers are both easy: agree and produce a false closure, or refuse on principle and hand back a 300-row problem with no plan.
- The owner says the deadline does not allow re-mapping. What is the minimum honest answer?Split the register in two: a small number of Base-level items with owners, derived from a sample, and an explicitly labelled unmapped remainder. That is deliverable inside a deadline and it is defensible under sampling. What is not available is a single closure across all 300, because that is a claim about the estate that nobody can support.
- Is there any case where many rows genuinely do close on one change?Yes, and it is worth hunting for. When the rows trace to one shared library, one code generator or one configuration template, the remediation unit is that component and the rows close together honestly. But that is discovered by mapping at Base and looking upstream — it is a property of the code, not of the label they happen to share.
- How do you stop the same backlog reappearing next quarter?Change the intake rule rather than the register. Require mapping at the most specific level the evidence supports, allow a Class label only as an explicitly provisional state, and make that state visible in reporting. Otherwise whatever process attached the Class labels keeps producing them and the argument repeats at a larger scale.
saying these in an interview costs you the question
- Agrees to a single closure to protect the deadline
- Refuses on taxonomy grounds without offering a path
- Treats the count of class-labelled rows as a defect population
- Assumes shared class label implies shared owner or shared fix
- Ignores that the intake process will regenerate the backlog