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 , 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.