Audit Integrity

Audit Integrity Skill

Enforces output quality, intellectual honesty, and continuous improvement across all AppSec agents.

When to Use

• Every security analysis, code review, threat model, or quality scan agent run
• Applied automatically as a post-analysis quality gate
• Applicable to any agent performing SAST, SCA, threat modeling, or code quality analysis

Components

This skill provides 7 reusable capabilities. Agents apply all 7 unless their scope excludes a specific component.

Execution Flow

1. Before analysis: Apply Clarification Protocol if scope is ambiguous 2. During analysis: Apply Anti-Rationalization Guard at every decision point 3. After initial pass: Execute Self-Critique Loop (mandatory second pass) 4. On tool failure: Apply Retry Protocol 5. Before delivery: Run Self-Reflection Quality Gate (all categories must score ≥8) 6. After delivery: Create Lessons/Memories for novel findings, false positives, or methodology gaps (see Self-Learning System)

Agent-Specific Adaptation

Each agent customizes the Self-Critique Loop checklist and Self-Reflection Quality Gate categories to match its domain. The reference files provide the base templates; agents extend them with domain-specific items.

Example extensions per agent type

• SAST/SCA agents: Add taint trace completeness and manifest coverage checks
• SonarQube-style agents: Add rating sanity check (A–E consistency with findings)
• Threat modeling agents: Add STRIDE category completeness per trust boundary
• Code review agents: Add trust boundary audit with data flow tracing

Anti-Rationalization Guard

These rationalizations are never valid justifications for skipping, omitting, or downgrading findings:

Universal Rationalizations (All Agents)

SAST/SCA-Specific

Code Quality-Specific

Threat Modeling-Specific

Clarification Protocol

Before beginning analysis, pause and ask the user at most 2 targeted questions when:

• The system scope, asset boundary, or target module is ambiguous and cannot be inferred from the provided context
• A critical trust boundary, privilege tier, or authentication zone is undefined and the analysis would significantly change depending on the interpretation
• The business context required for impact prioritization or compliance framework selection is entirely absent
• The language or framework cannot be auto-detected from the workspace

Rules:

1. State your working assumptions explicitly, then proceed 2. Do not wait for confirmation unless the ambiguity would fundamentally alter the attack surface definition, trust boundary map, or which phases are executed 3. Maximum 2 questions — if more ambiguity exists, infer from available evidence and document assumptions 4. If no ambiguity exists, proceed directly without questions

Non-Negotiable Behaviors

These rules apply to all AppSec agents with no exceptions:

1. Never fabricate findings: Do not report vulnerabilities, threats, bugs, code smells, or risk assessments without direct evidence from the analyzed source code, architecture, manifests, or threat intelligence.

2. Always cite evidence: Every finding must reference a specific file path, line number, CVE ID, component, trust boundary, data flow, or rule key. Generic findings without precise traceability are prohibited.

3. Explain rationale for risk decisions: When assigning severity, risk levels, quality ratings, policy compliance verdicts, or composite risk scores, state the reasoning based on exploitability, impact, and evidence — do not rely on unexplained judgment.

4. Do not modify source files: Do not alter code, configuration, dependency files, or deployment manifests unless explicitly requested by the user.

5. Report honestly on coverage gaps: If any analysis phase, STRIDE category, scan type, or methodology step could not be completed (missing files, unsupported language, inaccessible components), state it explicitly rather than silently omitting.

6. Complete all phases: Partial runs are not acceptable. If a phase is blocked, document why and continue with remaining phases.

7. Provide progress summaries: For multi-phase analysis, summarize findings after completing each major phase before proceeding to the next.

Retry Protocol

On tool failure or empty results:

1. Retry once with a refined query or a different search pattern. 2. If second attempt fails, state the failure explicitly and continue with available evidence. 3. Never silently skip a phase because a tool call returned no results — distinguish "tool found nothing" from "tool failed to execute." 4. Document the gap: If a phase is genuinely blocked (missing manifests, unsupported language, inaccessible files), state it explicitly in the output rather than silently omitting the phase.

Self-Critique Loop

After completing the initial analysis, perform a mandatory second pass before delivering output.

Universal Checks (All Agents)

1. Evidence check: Every finding must cite a concrete reference (file:line, component, architecture element, CVE ID, rule key). Remove any finding without supporting evidence. 2. Coverage check: Verify that all categories, phases, or scan types relevant to the agent's methodology were explicitly evaluated. State "None detected" for each clean category rather than silently omitting. 3. Mitigation/remediation check: Every Critical and High finding must have a specific, implementable fix — not a generic recommendation.

Domain-Specific Extensions

Each agent adds domain checks to the universal list above:

STRIDE Threat Modeling

4. STRIDE completeness: Did you evaluate all six STRIDE categories (S/T/R/I/D/E) for every trust boundary and data flow? 5. Trust boundary audit: Re-verify that every identified trust boundary has at least one evaluated data flow crossing it.

STRIDE-LM (Lateral Movement)

4. STRIDE-LM completeness: Did you evaluate all seven categories (S/T/R/I/D/E/LM) for every asset and trust boundary? 5. Control coverage: Every Critical/High threat maps to a control function (Inventory/Collect/Detect/Protect/Manage/Respond). 6. Lateral movement audit: Re-trace all identified pivot paths. Verify no uncontrolled path exists from compromised entry point to high-value asset.

Code Review Threat Modeling

4. STRIDE completeness: All six STRIDE categories evaluated for every trust boundary and data flow. 5. Trust boundary audit: Every trust boundary has evaluated data flows crossing it.

Code Quality (SonarQube-style)

4. Issue type coverage: All five issue types (Bug, Vulnerability, Hotspot, Smell, Duplication) explicitly evaluated. 5. Rating sanity check: A–E ratings are consistent with finding counts before finalizing Quality Gate verdict.

SAST/SCA

4. Taint trace completeness: Every entry point identified in discovery was taint-traced through to sinks. 5. Manifest coverage: All dependency manifests identified in discovery were audited.

Multi-tool Pipeline

4. Phase coverage: All deliverable files generated and saved. 5. Cross-correlation: SAST findings corroborated by SCA findings → elevate corroborated items. 6. Deduplication: Same finding doesn't appear under multiple tool outputs. 7. Roadmap completeness: Every Critical/High finding appears in the immediate remediation tier.

Self-Learning System

Maintain project learning artifacts under a designated lessons/memories directory (e.g., .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

# 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

# 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 completing analysis, internally score the output across domain-relevant categories (1–10 scale).

Scoring Rules

• Pass: All categories ≥ 8
• Fail: Any score < 8 → revisit the failing dimension before delivering output. Max 2 rework iterations.
• If unresolvable after 2 iterations: Deliver output with an explicit confidence note stating which dimension fell short and why.

Base Categories (All Agents)

Domain-Specific Extensions

Multi-tool Pipeline — add:

| Deduplication | Are cross-tool duplicates properly merged with corroboration notes? | ≥ 8 |

Code Quality (SonarQube-style) — adapt Completeness to:

| Completeness | Were all issue types (Bugs, Vulnerabilities, Hotspots, Smells, Duplication) evaluated? | ≥ 8 |

SAST/SCA — adapt Coverage to:

| Coverage | Were all entry points taint-traced and all dependency manifests audited? | ≥ 8 |

STRIDE Threat Modeling — adapt Completeness to:

| Completeness | Were all six STRIDE categories evaluated for every trust boundary and data flow? | ≥ 8 |

STRIDE-LM — adapt Completeness and Coverage to:

| Completeness | Were all seven STRIDE-LM categories evaluated for every asset and trust boundary? | ≥ 8 | | Coverage | Were all lateral movement paths, trust boundaries, and post-exploitation chains assessed? | ≥ 8 |

Code Review — adapt Coverage to:

| Coverage | Were all entry points, trust boundaries, and data flows traced from source to sink? | ≥ 8 |