| name | fips-finding-triage |
| description | Classifies an individual FIPS crypto audit finding as real cryptography or a non-cryptographic use of a crypto primitive, using structured diagnostic reasoning. Follows the abductive triage methodology of resolving coordinate mismatches first, since most findings are non-crypto, then tracing data flow and protocol requirements only when a usage is genuinely ambiguous. Use when an audit surfaces a CRITICAL or WARNING finding that needs classification, when a vendored dependency's crypto usage may not ship in the binary, or when producing evidence for a compliance review. |
| metadata | {"author":"TGPSKI","version":"1.0"} |
| license | MIT |
| compatibility | Go 1.24+ (native FIPS 140-3 module), bash. Operates on findings emitted by the fips-crypto-audit skill plus the Go source under review; no network access required. |
FIPS Finding Triage
Structured diagnostic reasoning for classifying individual FIPS crypto audit findings. Determines whether a crypto/ package usage is actual cryptography or non-cryptographic use of a crypto primitive.
This skill follows the abductive triage methodology: resolve coordinate mismatches first (majority of findings are non-crypto), then investigate deeper only when the usage is genuinely ambiguous.
When to Use
- Audit found a CRITICAL or WARNING finding and you need to classify it
- A finding's context is ambiguous — could be crypto or non-crypto
- Vendor dependency uses crypto and you need to determine if it ships in the binary
- Generating evidence for a compliance review
Tier 1 — Fast Path (resolves ~80% of findings)
Most FIPS audit findings are coordinate mismatches: code using a crypto primitive for a non-cryptographic purpose. Check these discriminating signals first, in order:
Check 1: Is it in vendor/ or test code?
| Status | Action |
|---|
In vendor/ and a build-time tool (linter, codegen, analysis) | FALSE POSITIVE — not compiled into binary. Close. |
In vendor/ and a runtime dependency | Continue to Check 2, but note: fix owner is upstream. |
In *_test.go or test/ directory | LOW PRIORITY — fix during test refactor. Close unless specifically asked. |
| In production code (non-test, non-vendor) | Continue to Check 2. |
Check 2: What does the surrounding code do?
Read 10-15 lines of context around the crypto call. Look for these discriminating patterns:
| Pattern | Verdict | Confidence |
|---|
| Hash result used as map key, annotation, label, or file name | NON-CRYPTO | High |
| Hash result compared for equality (dedup, cache hit) | NON-CRYPTO | High |
Hash result stored as sha256:... prefix string | NON-CRYPTO (content-addressable) | High |
Hash result used in fmt.Sprintf("%x", ...) for display/logging | NON-CRYPTO | High |
Hash used with hmac.New() for request signing or MAC verification | CRYPTO | High |
Key generated with rsa.GenerateKey() or ecdsa.GenerateKey() | CRYPTO | High |
Used inside tls.Config{} or x509.CreateCertificate() | CRYPTO | High |
| Password hashing (bcrypt, scrypt, argon2, or MD5/SHA-1 for passwords) | CRYPTO | High |
Result feeds into cipher.NewGCM(), cipher.NewCBCEncrypter() | CRYPTO | High |
Check 3: Variable and function naming
Names reveal intent. Check the function name, variable names, and comments:
| Name pattern | Verdict |
|---|
computeHash, configHash, specHash, contentHash | NON-CRYPTO |
fingerprint, checksum, digest (without "verify") | NON-CRYPTO |
cacheKey, dedup, etag, annotationHash | NON-CRYPTO |
sign, verify, encrypt, decrypt, authenticate | CRYPTO |
seal, open, mac, hmac (as operation, not just import) | CRYPTO |
password, credential, token (with hash operation) | CRYPTO |
Tier 2 — Deep Investigation (only if Tier 1 is inconclusive)
If the fast path doesn't resolve the finding, investigate deeper:
Step 1: Trace the data flow
rg -n --type go -A 10 '<hash_variable>' <file>
Follow the hash output. Where does it go?
- Into a comparison → NON-CRYPTO
- Into a network write or crypto operation → CRYPTO
- Into a struct field or map key → NON-CRYPTO
- Into a signature or MAC → CRYPTO
Step 2: Check if the algorithm matters
For non-crypto uses, the specific hash algorithm is irrelevant — any hash would work. Ask: "Would replacing MD5 with FNV-1a or CRC32 break the functionality?"
| Answer | Verdict |
|---|
| No, any hash works | NON-CRYPTO — swap to hash/fnv or crypto/sha256 |
| Yes, must be MD5 specifically | Check why — protocol compat? Then PROTOCOL-MANDATED |
| Yes, must be cryptographically secure | CRYPTO — needs FIPS-approved algorithm |
Step 3: Check protocol requirements
If the code implements a protocol (SSH, PGP, WebSocket, AWS S3, UUID):
rg -n -i 'rfc|protocol|spec|standard|compat' <file>
| Status | Verdict |
|---|
| RFC mandates this algorithm (e.g., UUID v3 requires MD5) | PROTOCOL-MANDATED — needs upstream fix or build-tag gate |
| Protocol supports this as legacy option (e.g., SSH 3DES) | PROTOCOL-LEGACY — needs upstream decision |
| No protocol requirement found | Continue investigation |
Output
For each finding, produce a classification record:
### <file>:<line> — <package>.<function>()
- **Classification**: ACTUAL CRYPTO | NON-CRYPTO | PROTOCOL-MANDATED | TEST-ONLY | FALSE-POSITIVE
- **Confidence**: High | Medium | Low
- **Evidence**: <what you observed that led to this classification>
- **Remediation**:
- ACTUAL CRYPTO → replace with FIPS-approved algorithm
- NON-CRYPTO → swap to `hash/fnv`, `hash/crc32`, or `crypto/sha256`
- PROTOCOL-MANDATED → swap or gate behind build tag; document the RFC requirement
- TEST-ONLY → swap algorithm in test code
- FALSE-POSITIVE → no action, exclude from scanner
- **Effort**: XS (<15 min) | S (<1 hour) | M (<4 hours) | L (>4 hours)
Evidence Hierarchy
When classifying findings, trust evidence in this order:
| Label | Source | Trust |
|---|
| DEFINITIVE | Code context: actual function calls and data flow | Highest |
| CONFIG | Variable/function naming, comments, struct tags | High |
| HEURISTIC | Automated pattern matching (non-crypto patterns) | Medium |
| SOCIAL | "Someone said this is fine" | Do not trust — verify |
Follow-up Skills
- Use
@fips-remediation-plan/SKILL.md after classifying all findings to generate TODO lists
- Use
@fips-crypto-audit/SKILL.md to re-audit after fixes to confirm resolution