YanoSecA finding is a supported security weakness with evidence, context, impact and a fitting action. A lead is a possible issue that still needs confirmation. A tool label can suggest a next question without establishing that a security requirement failed.
Evidence says what was actually checked and where the result came from. Impact describes the supported harm. Severity judges that harm in context, including exposure and affected assets. Remediation proposes a corrective change; retest states how to check it. These written activities use a rubric, not an uploaded or automatically graded report.
Before you begin
- Recommended first
- The rule for every tool from here on, Notes: scope, command, result, time, Passwords, hashes, and dumps, Access control and IDOR
- Estimated time
- 14 min reading, 14 min activity. Setup and optional practice may take longer.
- Where you work
- Use only the supplied North Desk fictional cards and source in a desktop or mobile browser. Keep predictions in private notes. No login attempt, recovery tool, framework module, permission change, domain setup or target connection is required. Optional later lab setup has a separate budget.
- Without a lab
- All evidence needed for the activity appears on this page. Copy it into notes if downloads are unavailable. Read the labeled model and predict each result; a paper trace practises the reasoning while tool operation waits for a lab. Reading needs no JavaScript. Answer checking needs JavaScript and a secure context; saving progress also needs usable browser storage.
After this lesson you can:
- Classify a version-only note as an unconfirmed lead.
- Separate the supplied observation from missing behavior and impact evidence.
- Draft a bounded next-check proposal without inventing a result.
01Example
Fresh original finding model. It is authored evidence, not a request performed in this session.
Requirement: only approved editors may change a schedule.
Card W: an unapproved reader’s change is denied.
Supported: the stated check enforced the rule for this case.
Unsupported: a finding that all readers can modify schedules.
Limit: one supplied case does not establish every route’s behavior.02What has to be true
A defensible claim needs a security rule and evidence about whether it held. A version string alone says neither what behavior occurred nor what harm followed. Name missing confirmation rather than adding an impressive severity label.
Keep artifact identifiers and exact relevant observations so another permitted reviewer can follow the reasoning. Redact passwords, tickets and session secrets; a report should not disclose authentication material to make a claim look more complete.
Separate a lead from a supported security finding and keep the impact inside the available evidence.Model. A teaching model drawn by hand. It shows the idea, not real tool output.
Read the full explanation below.
Required rule
Requirement: only approved editors may change a schedule.Card W
Card W: an unapproved reader’s change is denied.The supplied case enforced the stated rule
The unapproved reader was denied in Card W.
One case does not establish every route’s behavior.
Original fictional teaching evidence
The unapproved reader was denied in Card W. One case does not establish every route’s behavior.
Follow the explanation
- The unapproved reader was denied in Card W. One case does not establish every route’s behavior.
- The supplied denial does not support the opposite conclusion. A finding needs evidence of a failed rule.
Read every state and value
1. The unapproved reader was denied in Card W. One case does not establish every route’s behavior.
- Evidence selected
- Required rule · Card W
- Current claim
- enforced
- Source origins
- Original fictional teaching evidence
2. The supplied denial does not support the opposite conclusion. A finding needs evidence of a failed rule.
- Evidence selected
- Required rule · Card W
- Current claim
- all
- Source origins
- Original fictional teaching evidence
03Classify note N-14
Use raw note N-14 and the finding template. Its behavior-reproduced line is none.
Finding template
Label: original template. The essay is not graded. No upload exists.
Title:
Status: verified finding, or lead
Asset:
Evidence: what was actually checked, with the card id
Impact: what that evidence supports, and what it does not
Remediation: the change that would address the evidence
Retest: how to check the change without repeating a guess
Limit: uncertainty, redaction, and scope
A scanner label or a version banner, with no reproduced behavior, stays a lead.
Do not paste a password, a ticket, or a session secret into the evidence line.
Raw note N-14
Label: original fictional note. No scanner was run.
Tool label: "service version 2.3 matches a module name"
Asset named in the note: files-3.lab.invalid
Behavior reproduced: none
Response saved: none
Scope grant: read the note
N-14 is a label. It does not show what files-3 did.
- Copy the asset, source label and actual version-match observation. Separate that observation from an untested explanation.
- Mark missing behavior and impact confirmation explicitly; do not invent a saved response.
- Draft a bounded next-check proposal under an appropriate future grant, with a stop if scope is missing.
- Stop at the lead record. This activity does not run a scanner or validate the suspected weakness.
04Optional challenge
For about ten optional minutes, write a false-positive review note explaining how a later safe confirmation could reject a version-based suspicion. The rubric is a stated expected behavior, preserved actual evidence and an honest status change; no test is executed.
05Fresh cases for the checks
Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.
Review card A: three independent fictional notesOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
Requirement: a reader may see only their own saved note.
N1: version label resembles a module; no behavior checked.
N2: saved response S8 returns another account’s note to a reader; no modification is tested.
N3: saved response S9 denies another account’s note to a reader.
These are supplied fictional observations, not new requests.
Next-check card BOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
Grant: read the already-saved S8 response and its owner record only.
Allowed: compare response contents with the owner record and draft a proposed future retest.
Excluded: new requests, identifier changes and service contact.
Follow-up card COwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
A version lead predicted that a reader could edit a note. A later supplied authorized check records denial of that edit. Only this one case was checked.
06Explain the evidence and its limit
Optional self-check: draft claim, cited evidence, impact, limit and a next-check proposal from one note.
Review it: distinguish a lead from evidenced behavior, avoid untested severity claims, and keep proposals within the grant.
07Common mistakes
If a version label becomes a confirmed weakness, find the missing behavior and requirement comparison.
If a finding claims another account’s data, verify the supplied owner and requester instead of assuming a different identity.
If a severity term replaces evidence, restore the supported harm and context before rating it.
References
- NIST ITL Bulletin, December 2008
Assessment background on supported findings, analysis, mitigation and reporting.
- NIST SP 800-115 publication page
Assessment background on supported findings, analysis, mitigation and reporting.