Audit Integrity

---
name: audit-integrity
description: "Enforce output quality, evidence verification, and quality gates across security audits. Use this skill when you perform SAST, SCA, threat modeling, or security code reviews. Use this skill to verify code locations and taint traces for all findings. Use this skill to prevent the suppression of valid security findings. Use this skill to evaluate reports against quality thresholds (score ≥ 8/10) before delivery."
license: MIT
metadata:
  version: "1.1"
---

# Audit Integrity Skill

Enforce output quality, intellectual honesty, and continuous improvement across security audits and code reviews.

## When to Use

- Perform security analyses, threat models, code reviews, or quality audits.
- Validate that every finding has verified code evidence and taint flow.
- Prevent the suppression or rationalization of security findings.
- Evaluate draft reports against the quality gate threshold (score ≥ 8/10).
- Record lessons learned and security memories after you complete a scan.

## Components

This skill provides 7 modular capabilities in the `references/` directory. Load each file when you reach its execution phase:

| Component                    | Reference File                                                                           | Purpose                                                           |
| ---------------------------- | ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------- |
| Clarification Protocol       | [references/clarification-protocol.md](references/clarification-protocol.md)             | Ask a maximum of 2 targeted questions when scope is not clear     |
| Anti-Rationalization Guard   | [references/anti-rationalization-guard.md](references/anti-rationalization-guard.md)     | Prohibited rationalizations and mandatory responses for findings  |
| Self-Critique Loop           | [references/self-critique-loop.md](references/self-critique-loop.md)                     | Mandatory second pass to verify evidence and coverage             |
| Retry Protocol               | [references/retry-protocol.md](references/retry-protocol.md)                             | Tool failure and empty search handling: retry once, then document |
| Non-Negotiable Behaviors     | [references/non-negotiable-behaviors.md](references/non-negotiable-behaviors.md)         | Mandatory rules: do not fabricate, cite evidence, report gaps     |
| Self-Reflection Quality Gate | [references/self-reflection-quality-gate.md](references/self-reflection-quality-gate.md) | Scoring rubric (1–10 scale) with a minimum threshold of 8         |
| Self-Learning System         | [references/self-learning-system.md](references/self-learning-system.md)                 | Templates and rules for lessons and security memories             |

## Execution Flow

Load reference files as you reach each phase:

1. **Before analysis**: If scope or policy is not clear, read [references/clarification-protocol.md](references/clarification-protocol.md). Ask a maximum of 2 targeted questions.
2. **During analysis**: Follow [references/non-negotiable-behaviors.md](references/non-negotiable-behaviors.md). At each triage decision, consult [references/anti-rationalization-guard.md](references/anti-rationalization-guard.md).
3. **On tool or search failure**: Follow [references/retry-protocol.md](references/retry-protocol.md). Do not assume code is secure without verification.
4. **After initial analysis**: Complete a second pass with the checklist in [references/self-critique-loop.md](references/self-critique-loop.md). Verify taint traces and manifest coverage.
5. **Before delivery**: Score the draft report using [references/self-reflection-quality-gate.md](references/self-reflection-quality-gate.md). All categories must score ≥ 8.
6. **Final delivery**: Record lessons and memories using [references/self-learning-system.md](references/self-learning-system.md).

# Anti-Rationalization Guard

These rationalizations are **never** valid reasons to skip, omit, or downgrade findings:

## Universal Rationalizations

| If you think...                            | Mandatory response                                                                                                            |
| ------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
| "No issues or threats found on first pass" | Systematic evaluation across all categories is required before you conclude clean. Expand scope and complete the full matrix. |
| "This looks fine, skip deep analysis"      | "Looks fine" is not evidence. Evidence is a code trace, architecture reference, or rule match. Run checks.                    |
| "The risk is probably lower in practice"   | Risk level is based on impact multiplied by likelihood. Justify any downgrade with explicit evidence.                         |
| "This is a false positive"                 | Flag the finding as a potential false positive, but include it. Do not silently suppress findings. Document the rationale.    |
| "This is outside scope"                    | State explicitly why, with a reference to the declared scope or assessment boundary.                                          |
| "No controls or mitigations needed here"   | State "No gap identified — rationale: [X]" explicitly. Silence is not assurance.                                              |

## SAST/SCA

| If you think...                          | Mandatory response                                                                                          |
| ---------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| "SCA CVE is not exploitable here"        | Include the CVE with a documented context note. Do not silently suppress.                                   |
| "This phase can be skipped"              | All phases are mandatory. Document any phase that you cannot complete due to missing inputs.                |
| "Severity should be lower given context" | Severity is based on CVSS or exploitability. Justify any downgrade with explicit evidence. Do not suppress. |

## Threat Modeling

| If you think...                                | Mandatory response                                                                                       |
| ---------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| "This threat is mitigated by the architecture" | Document the specific compensating control and verify that it is implemented. Do not assume.             |
| "This category has no applicable threats here" | State "No applicable threats identified — rationale: [X]" explicitly. Do not silently omit categories.   |
| "Lateral movement is unlikely here"            | Document the specific architectural control that prevents pivoting and verify that it is implemented.    |
| "This threat actor would not target this"      | Document the basis for that exclusion. You must always consider insider threats and supply chain actors. |

# Clarification Protocol

Before you start the analysis, pause and ask the user a maximum of **2 targeted questions** when:

- The system scope, asset boundary, or target module is ambiguous and you cannot infer it from the context
- A critical trust boundary or privilege tier is undefined
- The business context for impact prioritization or compliance framework selection is absent
- The programming language or framework cannot be detected from the workspace

**Rules:**

1. State your working assumptions explicitly and proceed.
2. Do not wait for confirmation unless the ambiguity alters the attack surface definition or trust boundary map.
3. Ask a maximum of 2 questions. If more ambiguity exists, document your assumptions and proceed.
4. If no ambiguity exists, proceed directly without questions.

# Non-Negotiable Behaviors

These rules apply to **all** security agents with no exceptions:

1. **Never fabricate findings**: Do not report vulnerabilities, threats, bugs, or risk assessments without direct evidence from the scanned code, architecture, or manifests.

2. **Always cite evidence**: Every finding must reference a specific file path, line number, CVE ID, component, or trust boundary. Do not output generic findings.

3. **Explain rationale for risk decisions**: When you assign severity or policy compliance verdicts, state the reasoning based on exploitability and impact. Do not rely on unexplained judgment.

4. **Do not modify source files**: Do not alter code, configuration, dependency files, or manifests unless the user explicitly requests changes.

5. **Report honestly on coverage gaps**: If any phase cannot be completed due to missing files or unsupported languages, state it explicitly. Do not omit phases.

6. **Complete all phases**: Execute all analysis phases. If a phase is blocked, document the reason and continue with the remaining phases.

7. **Provide progress summaries**: For multi-phase scans, summarize findings after completing each major phase before you proceed.

# Retry Protocol

On tool failure or empty search results:

1. **Retry once** with an alternative query or a different search pattern.
2. **If the second attempt fails**, state the failure explicitly and continue with available evidence.
3. **Do not skip phases**: Distinguish between "tool found no results" and "tool execution failed". Never assume the code is clean without verification.
4. **Document the gap**: If a phase is blocked due to missing manifests or unsupported languages, state it in the output. Do not omit the phase.

# Self-Critique Loop

After you complete the initial analysis, complete a **mandatory second pass** before you deliver the report.

## Universal Checks

1. **Evidence check**: Every finding must cite a verified reference (`file:line`, component, architecture element, or CVE ID). Remove any finding that does not have supporting evidence.
2. **Coverage check**: Verify that you evaluated all required categories and phases. State "None detected" for clean categories. Do not omit clean categories.
3. **Remediation check**: Provide a specific, implementable fix for every Critical and High finding. Do not provide generic recommendations.

## Domain Checks

### SAST/SCA

1. **Taint trace completeness**: Verify that you traced each discovered entry point from source to sink.
2. **Manifest coverage**: Verify that you audited all discovered dependency manifests.
3. **Evidence completeness**: Cite a verified `file:line` reference and taint trace for each SAST finding. Cite a verified CVE ID and affected version range for each SCA finding.
4. **Flaw category completeness**: Confirm that you evaluated all flaw categories. State "No instances detected" for clean categories. Do not omit clean categories.
5. **Policy consistency**: Verify that the PASS or FAIL policy verdict matches severity counts and policy threshold rules.

### Threat Modeling

1. **STRIDE completeness**: Verify that you evaluated all six STRIDE categories (S/T/R/I/D/E) for each trust boundary and data flow.
2. **Trust boundary audit**: Verify that each identified trust boundary has at least one evaluated data flow crossing it.

# Self-Learning System

Maintain project learning artifacts in `.github/SecurityLessons/` and `.github/SecurityMemories/`.

## When to Create

### Lesson

Create a lesson when:

- A scan produces a false positive that required manual correction
- A finding category, STRIDE category, or flaw type is missed on first pass and caught by the self-critique loop
- A tool or methodology limitation is discovered
- A language-specific rule misfires
- An SCA dependency cannot be resolved

### Memory

Create a memory when:

- An architecture decision, security convention, or technology stack detail is discovered
- A dependency management pattern, domain-specific threat pattern, or threat actor profile is identified
- A project coding convention, framework idiom, or known false-positive pattern is found
- Any codebase-specific knowledge would be useful for future scans of the same codebase

## Lesson Template

```markdown
# Security Lesson: <short-title>

## Metadata

- CreatedAt: <date>
- Status: active | deprecated
- Supersedes: <previous lesson if any>

## Context

- Triggering scan/task:
- Component analyzed:

## Issue

- What went wrong or was missed:
- Expected behavior:
- Actual behavior:

## Root Cause

- Why was this missed or incorrect:

## Resolution

- How it was corrected:

## Preventive Guidance

- How to avoid this in future scans:
```

## Memory Template

```markdown
# Security Memory: <short-title>

## Metadata

- CreatedAt: <date>
- Status: active | deprecated
- Supersedes: <previous memory if any>

## Context

- Triggering scan/task:
- Scope/system:

## Key Fact

- What was discovered:
- Why it matters for security analysis:

## Reuse Guidance

- When to apply this knowledge:
- Related components:
```

## Governance Rules

1. **Dedup check**: Before creating a new lesson or memory, search existing files for similar content. Update existing records rather than creating duplicates.
2. **Conflict resolution**: If new evidence conflicts with an existing active lesson/memory, mark the older one as `deprecated` and create the updated version with a `Supersedes` reference.
3. **Reuse at scan start**: At the start of every analysis, check the lessons/memories directory for applicable context. Apply relevant guidance before beginning analysis.

# Self-Reflection Quality Gate

After you complete the analysis, score the output across domain categories on a 1–10 scale.

**Threshold**: Every category must score **≥ 8** to pass. If any category scores < 8, resolve the gaps before you deliver the report (maximum 2 rework iterations).

## Core Scoring Rubric (Universal)

| Category           | Score 9–10                                                                                  | Score 7–8                                                             | Score 5–6                                                           | Score 1–4                                                       |
| ------------------ | ------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | ------------------------------------------------------------------- | --------------------------------------------------------------- |
| **Completeness**   | All phases, categories, boundaries, and checklists evaluated with explicit evidence         | Minor omissions that do not affect the risk profile                   | Noticeable gaps in coverage; entire sections omitted                | Superficial pass; major sections missing                        |
| **Accuracy**       | Precise file:line references, confirmed CVE IDs, verified taint flows, correct CWE mappings | Minor version ambiguity or indirect references; core findings correct | Plausible findings with unverified details or questionable mappings | Fabricated references, wrong CWE mappings, or hallucinated CVEs |
| **Actionability**  | Concrete remediation code, exact package upgrade targets, step-by-step guidance             | Clear direction but requires human adjustment                         | High-level advice without code or version targets                   | Generic platitudes ("sanitize inputs", "keep packages updated") |
| **Consistency**    | Risk ratings match evidence, framework verdicts align with findings, formatting uniform     | Minor formatting or taxonomy inconsistencies                          | Severity ratings conflict with impact descriptions                  | Contradictory findings or incompatible verdicts                 |
| **Evidence Rigor** | Every claim backed by code, manifest, trace, or threat model element                        | Most findings backed; some secondary claims lack citations            | Assertions made without code citations                              | Speculative findings with zero code or manifest backing         |

## Scoring Threshold

| Final Score                  | Action                                                                    |
| ---------------------------- | ------------------------------------------------------------------------- |
| All categories ≥ 8           | **PASS** — Proceed to final delivery                                      |
| Any category < 8 (attempt 1) | **REWORK** — Address deficiencies and re-score                            |
| Any category < 8 (attempt 2) | **REWORK** — Final attempt to resolve gaps                                |
| Any category < 8 (attempt 3) | **FLAG & DELIVER** — Deliver with explicit quality gap disclosure to user |

## Domain-Specific Rubrics

### SAST/SCA

| Category          | Question                                                                               | Threshold |
| ----------------- | -------------------------------------------------------------------------------------- | :-------: |
| **Completeness**  | Did you evaluate all SAST flaw categories and SCA ecosystems?                          |    ≥ 8    |
| **Accuracy**      | Are findings supported by concrete taint traces and verified CVE IDs?                  |    ≥ 8    |
| **Actionability** | Does each Critical and High finding have a concrete code fix or upgrade step?          |    ≥ 8    |
| **Consistency**   | Are severity ratings, CWE mappings, and policy verdicts consistent across the report?  |    ≥ 8    |
| **Coverage**      | Did you trace all entry points from source to sink and audit all dependency manifests? |    ≥ 8    |

### Threat Modeling and Code Review

| Category         | Question                                                                            | Threshold |
| ---------------- | ----------------------------------------------------------------------------------- | :-------: |
| **Completeness** | Did you evaluate all six STRIDE categories for each trust boundary and data flow?   |    ≥ 8    |
| **Coverage**     | Were all entry points, trust boundaries, and data flows traced from source to sink? |    ≥ 8    |