tiny-auditor

• SKILL.mdcore · 13,258 bytes

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