security-deep-dive

Identify and quantify security vulnerabilities in repository code using a six-step per-sink process.

Updated May 20, 2026

Search Tags:#security #vulnerability #inventory #code-audit #risk-report

Ready to run

npx skills add https://github.com/lukehinds/scrutineer-attest-test --skill security-deep-dive-lukehinds

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: security-deep-dive
Source: https://github.com/lukehinds/scrutineer-attest-test/tree/main/skills/security-deep-dive
Command: npx skills add https://github.com/lukehinds/scrutineer-attest-test --skill security-deep-dive-lukehinds

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Audit the first-party source for security vulnerabilities using an inventory-first, six-step per-sink methodology. The target is this codebase's own code, not its dependencies.

Core Features & Use Cases

Inventory-driven mapping of sinks, trust boundaries, and risk across the repository.
Phase 1 inventory followed by Phase 2 per-sink analysis to determine real findings vs pattern matches.
Produces a machine-readable report (report.json) and a human-friendly narrative.

Quick Start

Run the security-deep-dive workflow on the repository to generate report.json and schema.json.

Frequently Asked Questions about security-deep-dive

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I audit my own codebase for security vulnerabilities?▼

A codebase security audit identifies and quantifies vulnerabilities in your first-party source using an inventory-driven, six-step per-sink process that maps trust boundaries, validates findings, and cross-references prior art to distinguish real vulnerabilities from simple pattern matches.

What is an inventory-driven security audit and how does it work?▼

An inventory-driven security audit works in two phases: Phase 1 maps sinks, trust boundaries, and risk across the repository, followed by Phase 2 per-sink analysis that validates findings, cross-references prior art, and assesses reach to determine real vulnerabilities versus pattern matches.

Can I use this security audit on a large codebase?▼

Yes, this security audit is specifically applicable to medium-to-large codebases where distinguishing real findings from pattern matches matters, producing deterministic reporting and machine-readable artefacts suitable for governance requirements.

How do I generate a machine-readable security risk report?▼

You generate a machine-readable security risk report by running the audit workflow on your repository, which automatically produces a report.json and schema.json containing quantified findings, trust boundary mappings, and deterministic vulnerability data.

Does this code audit scan dependencies or only first-party source?▼

This code audit targets only your first-party source code, not its dependencies, focusing the inventory-driven per-sink analysis entirely on the repository's own code to identify and quantify security vulnerabilities.

What is the best way to distinguish real security findings from pattern matches?▼

The best way to distinguish real security findings from pattern matches is using a six-step per-sink methodology that implements trust boundaries, validation, prior-art cross-referencing, and reach assessment to produce deterministic reporting.