All lessons Leer en español

Security in depth · Unit 30 · Lesson 6 of 11

Fix the cause behind the visible symptom

Separate a visible fix from evidence that a shared defect was corrected.

4 minreadyShort lesson

Helpful before thisReporting: turn evidence into useful improvements

See all lessons in this topic

After this lesson you can

  • Distinguish symptom correction, causal hypothesis, and verification of related consumers.

Fixing the visible problem may leave the condition that produced it unresolved.

Keep cause and symptom separate

A symptom is observed behavior. A root-cause hypothesis proposes the underlying condition that produced it, but needs evidence before becoming a confirmed explanation. Similar symptoms can have different causes, and one shared cause can affect several components.

Assume a fictional catalog’s approved policy hides draft records from public viewers. Its preview page, export service, and API all depend on a shared policy library, but their complete configurations and call paths have not been compared.

Visible symptom → Underlying condition → Durable correctionVisible symptomUnderlying conditionDurable correction
The middle node requires causal evidence. Correcting a symptom does not automatically establish or eliminate the underlying condition.

Supplied correction record

  • P1: A supplied preview result included a draft record for a public viewer, contrary to policy.
  • P2: A local preview filter was changed; the same supplied review conditions now exclude the draft.
  • P3: An engineering note proposes a missing shared-policy check as the cause. No supporting code review or result from the export service or API is included.

Define what the fix establishes

P2 supports correction of the observed preview symptom under those conditions. It does not show whether the shared library was defective, whether the preview failed to use it, or whether another local condition caused the result. P3 remains a hypothesis.

Review the shared policy’s responsibility and each relevant consumer before deciding the corrective scope. If a common condition is confirmed, address it at the appropriate shared boundary and verify legitimate as well as prohibited outcomes for the affected consumers.

Do not label the unreviewed export or API as confirmed vulnerable merely because they share a dependency.

Model update: Preview symptom corrected. Proposed shared cause unconfirmed; export and API coverage remains open.

Terms you met

Root-cause hypothesis

Check yourself

No timer. No penalties. Read the explanation and try again whenever you like.

  1. Which status best fits P1-P3?

    Show the answer

    Correct answer: The preview symptom is corrected; the shared-policy hypothesis and other consumers still need review. P2 supports the narrow change. P3 makes a shared cause worth investigating but does not establish the behavior of the export or API.

Try it

  • WriteWrite a finding update for P1-P3: corrected symptom, proposed shared cause, two unresolved consumers, and required verification. Keep the shared cause labeled as a hypothesis.
References