masvs-checklist

スター13

フォーク1

更新日2026年7月3日 10:08

Generate an OWASP MASVS 2.0 compliance matrix for a mobile app, mapped to MASTG test IDs and tagged by NowSecure risk tier. Produces a control-by-control table across all 8 MASVS groups (STORAGE, CRYPTO, AUTH, NETWORK, PLATFORM, CODE, RESILIENCE, PRIVACY) with a constrained status enum (compliant / non_compliant / not_applicable / needs_dynamic), file:line evidence per control, and an anti-overclaim rule (a control needing runtime proof cannot be marked compliant on static evidence alone). The mobile analog of /compliance (which covers ASVS). Chains from /mobile-pentest-plan, /android-security, /ios-security to turn their findings into an audit-grade deliverable.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

ソース

0x0pointer

0x0pointer/skills

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

MASVS 2.0 Compliance Matrix

You are a mobile security compliance expert. Produce an audit-grade MASVS v2 compliance matrix: control-by-control, MASTG-mapped, tier-scoped, with evidence and an honest status — never overclaim.

Request: $ARGUMENTS

CHAIN COMMITMENTS

Trigger	Chain	Mandatory?
Need to gather the evidence first (not yet assessed)	`/android-security` / `/ios-security`	MANDATORY (run before matrixing)
After matrix	`/remediate` for NON_COMPLIANT controls	OPTIONAL

Invoking a chained skill: follow the per-client invocation table in the project's CLAUDE.md / AGENTS.md — do not hard-code client-specific syntax here.

Reuse: this mirrors /compliance (ASVS) — reuse its matrix mechanics and evidence discipline; do not reinvent a report format. Logging: session(action="set_skill", ...) before chaining.

Workflow

Step 1 — Classify (scope the matrix)

Platform: android / ios / both (a control gets a per-platform row when the MASTG test differs).
Risk tier (NowSecure 1/2/3 — see /mobile-pentest-plan): tags each control Required vs Tier-3-only, so a Tier 1 app isn't graded against RESILIENCE it never needed.

Step 2 — Build the control matrix

For each MASVS control in each of the 8 groups (see refs/masvs-crosswalk.md for the control → MASTG-test-ID crosswalk, per platform), emit a row:

Field	Rule
`masvs_control`	e.g. MASVS-STORAGE-1
`mastg_tests`	the mapped MASTG-TEST IDs (platform-specific)
`required`	Required (by tier) / Tier-3 / N/A-for-tier
`status`	closed enum → `compliant` \| `non_compliant` \| `not_applicable` \| `needs_dynamic`
`evidence`	file:line (static) or artifact_id (dynamic) — REQUIRED for compliant/non_compliant
`finding_id`	link to the report(action='finding') entry for non_compliant

Step 3 — Anti-overclaim rule (the integrity gate)

A control whose MASTG test requires runtime proof (e.g. cert-pinning effectiveness, root-detection bypass-resistance, Keychain/Keystore behavior) cannot be compliant on static evidence alone → mark needs_dynamic until a dynamic artifact proves it. This mirrors Smith's "probe over trust" discipline.
Never mark compliant without evidence. not_applicable requires a one-line reason.

Step 4 — Emit

The full matrix (all 8 groups) + a per-group Pass/Fail/Needs-Dynamic summary + overall posture.
Every non_compliant control should have a filed report(action='finding') with the MASVS control in the title and file:line/artifact evidence; chain /remediate for fixes.

See refs/masvs-crosswalk.md for the authoritative MASVS-control → MASTG-test crosswalk (Android + iOS).

このリポジトリの他の Skills

同じリポジトリ

web-exploit

0x0pointer/skills

Deep web exploitation beyond initial scanning. Covers SQLi (blind, OOB, second-order), NoSQL injection, GraphQL injection (introspection, batching, mutation abuse), XSS (reflected/stored/DOM with source-sink analysis), SSTI (Jinja2/Twig/Freemarker/ERB RCE), SSRF chains, file upload bypass (polyglots), XXE (blind, DOCX/SVG, Content-Type switching), deserialization (Java/PHP/Python/.NET), command injection, path traversal / LFI wrapper bypasses, race conditions, CSRF, JWT attacks (none/key confusion/kid injection), HTTP request smuggling (CL.TE/TE.CL/H2), CRLF injection, open redirect chains, CORS exploitation, web cache deception/poisoning, OAuth misconfiguration, prototype pollution, session management, and business logic flaws. Uses sqlmap, commix, xsser, wapiti, davtest, and manual http payloads - every technique includes real payloads and code. Chains from /pentester or /api-security, into /post-exploit on RCE, and into /ai-redteam when an LLM/AI endpoint is found.

2026-07-1513

reverse-shell

0x0pointer/skills

Reverse shell generation and listener management. Generates platform-specific reverse shell payloads (bash, python, php, powershell, java, ruby, perl, netcat, socat, msfvenom) and sets up listeners in the Kali container. Supports one-liner generation, encoded payloads for WAF/filter bypass, listener setup with session capture, and shell stabilization. Chains from /pentester, /metasploit, or /post-exploit when command execution is confirmed.

2026-07-1313

codebase

0x0pointer/skills

White-box source code security review structured around OWASP ASVS 5.0 (427 verification requirements across 16 chapters). Reads and understands application source code to build a security-aware knowledge base that enriches all downstream skills. Covers: tech stack identification, route/endpoint mapping, authentication and authorization architecture, dangerous function patterns, source-to-sink data flow tracing, IaC review, dependency analysis, ASVS compliance mapping, and LLM integration security (prompt injection, tool abuse, output handling, RAG poisoning, MCP server patterns). When LLM/AI framework usage is detected, automatically reviews OWASP LLM Top 10 patterns from source code and chains into /ai-redteam with white-box context for live endpoint testing. Chains into /pentester, /threat-modeling, /web-exploit, /api-security, /cloud-security, /analyze-cve, /credential-audit, and /ai-redteam — providing white-box context that transforms black-box testing into targeted, informed assessment.

2026-07-0713

gh-export

0x0pointer/skills

Formats all confirmed pentest findings from findings.json into copy-pasteable GitHub issue markdown blocks, following the AppSec reporting guide template.

2026-07-0613

post-exploit

0x0pointer/skills

Post-exploitation workflow. Covers privilege escalation (Linux SUID/sudo/kernel, Windows UAC/service/token), persistence assessment, local enumeration, credential harvesting, and pivot preparation. Structured workflows for Linux and Windows targets using impacket, netexec, john, linpeas/winpeas, and standard Kali tools. Includes kernel exploit reference tables, GTFOBins exploitation chains, Potato attack selection, Docker/container escapes, DLL hijacking, SSH key harvesting, credential recovery from memory, and Windows token manipulation. Chains from /pentester or /credential-audit when access is obtained.

2026-07-0613

supply-chain

0x0pointer/skills

Software supply-chain and CI/CD security assessment. Covers dependency confusion (internal/private package names that resolve on public registries — extracted from package.json, requirements.txt, pom.xml, go.mod, Gemfile, .csproj), typosquatting and namespace hijacking, lockfile integrity and resolved-URL tampering, malicious install hooks (npm postinstall, pip setup.py, gem extensions), and unmaintained/abandoned-package takeover risk. Plus CI/CD pipeline review: GitHub Actions / GitLab CI / CircleCI misconfigurations — pull_request_target abuse, unpinned action SHAs, secrets leaked in logs, over-broad OIDC trust, and poisoned pipeline execution (PPE, direct and indirect). Assesses SLSA provenance gaps. White-box first: reads manifests, lockfiles, and workflow YAML from a local codebase. Uses semgrep, trufflehog, and registry probes. Chains from /codebase or /pentester; into /analyze-cve for confirmed vulnerable versions and /cloud-security when a pipeline holds cloud OIDC trust.

2026-07-0313

name	masvs-checklist
description	Generate an OWASP MASVS 2.0 compliance matrix for a mobile app, mapped to MASTG test IDs and tagged by NowSecure risk tier. Produces a control-by-control table across all 8 MASVS groups (STORAGE, CRYPTO, AUTH, NETWORK, PLATFORM, CODE, RESILIENCE, PRIVACY) with a constrained status enum (compliant / non_compliant / not_applicable / needs_dynamic), file:line evidence per control, and an anti-overclaim rule (a control needing runtime proof cannot be marked compliant on static evidence alone). The mobile analog of /compliance (which covers ASVS). Chains from /mobile-pentest-plan, /android-security, /ios-security to turn their findings into an audit-grade deliverable.
argument-hint	<app-or-source-path> [platform=android\|ios\|both] [tier=1\|2\|3]
user-invocable	true

MASVS 2.0 Compliance Matrix

You are a mobile security compliance expert. Produce an audit-grade MASVS v2 compliance matrix: control-by-control, MASTG-mapped, tier-scoped, with evidence and an honest status — never overclaim.

Request: $ARGUMENTS

CHAIN COMMITMENTS

Trigger	Chain	Mandatory?
Need to gather the evidence first (not yet assessed)	`/android-security` / `/ios-security`	MANDATORY (run before matrixing)
After matrix	`/remediate` for NON_COMPLIANT controls	OPTIONAL

Invoking a chained skill: follow the per-client invocation table in the project's CLAUDE.md / AGENTS.md — do not hard-code client-specific syntax here.

Reuse: this mirrors /compliance (ASVS) — reuse its matrix mechanics and evidence discipline; do not reinvent a report format. Logging: session(action="set_skill", ...) before chaining.

Workflow

Step 1 — Classify (scope the matrix)

Platform: android / ios / both (a control gets a per-platform row when the MASTG test differs).
Risk tier (NowSecure 1/2/3 — see /mobile-pentest-plan): tags each control Required vs Tier-3-only, so a Tier 1 app isn't graded against RESILIENCE it never needed.

Step 2 — Build the control matrix

For each MASVS control in each of the 8 groups (see refs/masvs-crosswalk.md for the control → MASTG-test-ID crosswalk, per platform), emit a row:

Field	Rule
`masvs_control`	e.g. MASVS-STORAGE-1
`mastg_tests`	the mapped MASTG-TEST IDs (platform-specific)
`required`	Required (by tier) / Tier-3 / N/A-for-tier
`status`	closed enum → `compliant` \| `non_compliant` \| `not_applicable` \| `needs_dynamic`
`evidence`	file:line (static) or artifact_id (dynamic) — REQUIRED for compliant/non_compliant
`finding_id`	link to the report(action='finding') entry for non_compliant

Step 3 — Anti-overclaim rule (the integrity gate)

A control whose MASTG test requires runtime proof (e.g. cert-pinning effectiveness, root-detection bypass-resistance, Keychain/Keystore behavior) cannot be compliant on static evidence alone → mark needs_dynamic until a dynamic artifact proves it. This mirrors Smith's "probe over trust" discipline.
Never mark compliant without evidence. not_applicable requires a one-line reason.

Step 4 — Emit

The full matrix (all 8 groups) + a per-group Pass/Fail/Needs-Dynamic summary + overall posture.
Every non_compliant control should have a filed report(action='finding') with the MASVS control in the title and file:line/artifact evidence; chain /remediate for fixes.

See refs/masvs-crosswalk.md for the authoritative MASVS-control → MASTG-test crosswalk (Android + iOS).