Skip to main content

13.9 Journal: what you found, and what you decided

Make a permanent note. In your vault, create Projects/lab-vulnerabilities.md and record:

  • What you scan, and how. Which machines, which images, which kind of scan from lesson 13.1, and how often you intend to repeat it. "How often" is the part that turns a scan into a programme.
  • The scanning account from lesson 13.6: what it is called, what privileges you gave it, and the one sentence of reasoning for that choice.
  • Your prioritisation rule, in your own words. Mine is "KEV first, then fixable criticals, then everything else by exposure." Yours should be a sentence you could defend to somebody who disagreed.
  • Every accepted risk, in the five-part format from lesson 13.8, with its review date. This list is the one an auditor reads first in Module 16.
  • Where vuln.db lives, and the three queries from 13.3 that you would re-run. Paste the SQL in. Future you will not remember the join.
  • What the credentialed scan did to your detections in lesson 13.6, and what you decided to do about the recurring alert.

Then today's daily note​

Under what I did: the scan, and the number. "772 findings became 4" is a sentence worth having written down in your own words.

Under what broke: this module breaks in slow ways rather than loud ones. A feed sync that looked hung and was not. A .import that produced an empty table because of a path. A container that would not start. Write down which, and what you checked before you found it.

Under what I learned: pick one, and write it as though explaining it to someone who has not done this module.

  • Why severity is not priority, with your own numbers as evidence
  • Why an uncredentialed clean report is weak evidence
  • Why a risk acceptance with no review date is not an acceptance

Under open questions: the good ones here are about coverage. What is in your lab that nothing scanned? What would a scan miss entirely, given the three types in lesson 13.1? If a new critical vulnerability in a common library were announced this afternoon, how quickly could you answer "are we running it?"

The exercise worth doing before you close​

Take ten minutes and answer one question honestly:

Which of the findings you are not fixing would you be embarrassed to explain after an incident?

That is a different question from "which is highest severity", and it is closer to how these decisions get judged in hindsight. If the answer to any of them is "I would struggle", that one is not really accepted. It is deferred, and it belongs on your backlog with a date.

Put that list in the permanent note.

Close the loop​

cd ~/git/lab-journal
git status
git add -A
git commit -m "journal: module 13 complete"
git push

Your scan data is worth keeping too, but be careful what you commit. A report describing exactly which of your machines are vulnerable and how is a map for anybody who reads it.

# Your compose stacks, including the greenbone one from 13.4.
cd ~/docker
git add -A
git commit -m "stacks: greenbone community edition"
git push

Do not commit vuln.db, the raw scan exports, or the KEV copy. The database is regenerable in two minutes from commands you have written down, the exports are sensitive, and the KEV catalog is a public file that is stale the moment you save it. If you want the queries preserved, commit a .sql file with the queries in it. That is the useful part.

Tick Module 13 in Projects/lab-progress.md.