Tiny Auditor

List of always-true audit primitives:

Formatting and Style

• Report format consists of ToC, Executive Summary, Findings Summary Table, and Findings. If the report is around a single finding, only the finding should be there.
• Finding name format must be [C/H/M/L]-[Number] [Impact] via [Weakness] in [Feature]
• Finding name number should mark his relative severity next to all the other items of the same level (e.g. H-1 is more of a priority than H-2)
• Findings summary table should consist of ID (e.g. C-1), Risk, Status, and possible audit-specificity that’s key to track from a report receiver perspective) (e.g. if there are two environments tested, then a column for prod and staging or env names might make sense
• Standard finding headings should be Severity, Probability, Locations, Description, Attack Flow, Remediations
• Finding headings should match across all findings of the report
• Vulnerable Occurrences are bullets with (usually) github links with exact line references and commit paths to the vulnerable sections of the code that directly create the vulnerability. If the audited item is not a code with direct gitlink, specifiy all the affected endpoints, or whatever it is instead. If an evidence (e.g. api key name) is preset, prioritize it in reading of the bullets (e.g. - found_secret (Line 485)) - where line is a hyperlink, putting more priority on the key name itsefl which is easier on the fixing team to understand on a quick read. If you are doing code-link - explaner text, the explainer text is really bloat unless it really explains something so leave it optional, and don't hyperlink it (just the link itself not the explainer part right of the "-")
• Description must be technically accurate but concise and abstract. Plain narration of what was done and found.
• Description must follow “XXX is a feature that does XXX, During the audit it was found that XXX. Although <protocol dispute point or mitigating factor if exists>, an attacker that does XXX might…” - each portion should be logically separated with a newline to allow for easy clear reading
• If severity is uncertain (e.g. no clear poc) the finding description needs to end with a note explaining the realism of it, while still emphasizing why it’s still a risk.
• Attack Flow must be a bullet-point breadcrumb trace of how an attacker might exploit the finding from gaining prerequisites to actual exploitation. if the finding is not exactly an attacker gets to X, it should be developer/employee makes mistake Y, etc.
• Remediations must be priority-sorted bullet items of fix recommendations to the team, usually, its one most-ideal fix and descending to next-best things that compliment/do 80% of the fix for 5% the effort. but if the best recommendation is the cleanest, that’s preferred.
• Remediations (especially 2nd 3rd and so on) might be complementary or additional but not really stopping the fix, if that’s the case it should be clear from the way it is portrayed (e.g. As an extended blast-reduction, you may consider xxx)
• Remediations must be battle-tested and NOT introduce extra complexity and NEVER introduce other risks
• All text (finding name, description etc) needs to speak as if 80% certain because it should describe the vulnerable condition and the attack surface it opens, not assert the worst-case result as 100% guaranteed.
• Extra thought processes, checks, and metadata is not relevant for the report itself - the report is about portraying the findings to the board
• No emojis, no unnecessary or repeating information, no fluff
• Use regular dashes over em-dashes
• Finding summary table should clearly match findings to the component (one look at the finding summary table will tell the protocol "oh, they were on-track")
• Every title in the finding body (e.g. description) should be a in its own line and have a newline before the text begins (description -> new line -> description text)
• For impact, name the realistic actor (could also be a fat-fingering operator / lazy dev / curious user, not always a genius attacker), state the loss in plain terms, and be honest about reachability. If you can't name a realistic actor, the impact is "hardening," not "attack."
• Some findings' impact is just an inflation/duplication of whatever is written on the description ending, in which case it is redundant
• Almost all of the points to use ; are redundant - the point of descriptions and writing in a repot are to be read humanly, natural flow sentences rather than ";" or similar
• Description + Impact should usually be no longer than 12 lines (excluding bullets), and recommendations between 2~3. If it's more - ask yourself why.
• Screenshots - using available browser tools (or asking users where lacking) for screenshots to walkthrough the finding (key points only and poc) are helpful, their standardized location is under or between the lines of description (like short story with pictures consecutive style, in the following image xxx)

Severity classification

• Bug severity (C=4/H=3/M=2/L=1) should always be derived from severity = (risk x probability) when the highest severity is 16 and the lowest is 1 (end result low severity 1-4, medium severity 5-8, high severity 9-11, critical severity 12-16) - we never specify the risk numbers directly, though
  • Risk calculation should be abstracted away and not written other than the resulting Severity and Probability.
• Attacks that require a privileged pre-requisite (e.g. admin role) are instantly Low probability, with the exception of bugs that can arise due to normal routine done by a privileged admin
• Attacks that don’t have a strong attacker incentive (attackonomics) are instantly low probability
• Comparative severity - in the same report, a Critical can’t be of less severity than a Low
• Increase the severity of bugs that directly affect business-critical assets or defy core protocol purpose
• Critical example: a bug exploitable by any unprivileged threat actor and leads to loss of funds or devastating security outcome
• If a bug has a very easy, ricochet-free mitigation plan - it can slightly increase its severity score
• Severity hierarchy - sometimes findings get removed added or reclassified which affects the order, so if we are enforcing a C1,C2,H1,M1,M2 hierarchy (in ToC, finding table, finding headings and possible cross-references) and a change occurred, e.g. a new High was introduced which is more risk than existing H1, then H1->H2 and H1 takes its place and we update that everywhere on the page where needed
• Uncertain probabilities - if a finding probability is undetermined / unknown it should automatically be low, it’s either we can prove some issue exists or we can’t