AppSec Start -- Project Assessment

The entry point for any codebase. Detects what the project is, what data it handles, what scanners are available, and recommends exactly which /appsec:*

tools are relevant, in what order, and why.

This skill runs entirely in the main agent context. It does NOT dispatch subagents. It produces a recommendation, not findings.

Supported Flags

This skill accepts a subset of cross-cutting flags. Read ../../shared/schemas/flags.md for the full specification.

Flag Behavior

--scope

Ignored. Start always assesses the full project.

--format text

Human-readable ASCII output (default).

--format json

Structured JSON assessment.

--format md

Markdown report.

--quiet

Suppress explanations, output tool list only.

Workflow

Execute all 6 steps sequentially in the main agent context. Use Glob, Grep, Read, and Bash tools to gather evidence. Do NOT guess -- only report what you find.

Step 1: Detect Tech Stack

Read project manifests to determine languages, frameworks, databases, and infrastructure. Check for each of these files using Glob:

File Pattern Reveals

package.json

Node.js, npm dependencies, scripts

package-lock.json , yarn.lock , pnpm-lock.yaml

Dependency lockfiles

requirements.txt , Pipfile , pyproject.toml , setup.py

Python

go.mod , go.sum

Go

Cargo.toml , Cargo.lock

Rust

Gemfile , Gemfile.lock

Ruby

pom.xml , build.gradle , build.gradle.kts

Java/Kotlin

*.csproj , *.sln

.NET/C#

composer.json

PHP

Dockerfile , docker-compose.yml , docker-compose.yaml

Containers

serverless.yml , serverless.yaml , serverless.ts

Serverless

terraform/.tf , **/.tf

Terraform IaC

*.yaml in .github/workflows/

GitHub Actions CI/CD

.gitlab-ci.yml

GitLab CI/CD

Jenkinsfile

Jenkins CI/CD

.circleci/config.yml

CircleCI

Read each found manifest to extract framework names, database drivers, and notable dependencies. Build a concise stack summary.

Step 2: Detect Data Sensitivity

Scan the codebase for patterns indicating sensitive data handling. Use Grep with these patterns:

PII indicators:

• User model fields: email , phone , address , ssn , date_of_birth , social_security , national_id , passport

• GDPR patterns: consent , gdpr , data_subject , right_to_forget , data_protection

Financial indicators:

• Payment integrations: stripe , paypal , braintree , adyen , square

• Card patterns: card_number , cvv , credit_card , payment_method

• Transaction models: transaction , invoice , billing , subscription

Health data indicators:

• HIPAA terms: hipaa , phi , protected_health , medical_record , diagnosis , patient

Auth mechanism indicators:

• JWT: jsonwebtoken , jwt , jose

• OAuth: oauth , passport , openid

• Session: express-session , cookie-session , session_store

• Password storage: bcrypt , argon2 , scrypt , pbkdf2

Classify data sensitivity as: None detected, PII, Financial, Health/PHI, or combinations.

Step 3: Detect Architecture Patterns

Determine the application type by scanning for these indicators:

Pattern Indicator Files / Code

API-only backend Route handlers without template/view rendering, OpenAPI/Swagger spec

Full-stack Template engines (EJS, Pug, Jinja, ERB), React/Vue/Angular alongside API

GraphQL .graphql files, graphql in dependencies, schema definitions

WebSocket ws , socket.io , websocket in dependencies or code

Serverless serverless.yml , Lambda handlers, Cloud Functions

Microservices Multiple Dockerfile s, service mesh config, multiple package.json s

Monolith Single deployment unit, single database connection

Business logic heavy Payment processing, e-commerce models, fintech calculations

Many dependencies 100+ entries in lockfile

CI/CD present .github/workflows/ , .gitlab-ci.yml , Jenkinsfile

Step 4: Detect Installed Scanners

Check PATH for known scanner binaries using Bash which commands. Run these checks in parallel:

which semgrep which bandit which gosec which brakeman which cargo-audit which gitleaks which trufflehog which trivy which osv-scanner which checkov which tfsec which kics which npm (for npm audit) which pip-audit

Read ../../shared/schemas/scanners.md

for the full scanner registry and detection patterns.

Mark each as detected or not. For language-specific scanners, only report relevance if the language is in the detected stack.

Step 5: Check Existing Security Configs

Scan for security configurations already in place:

Config What to Check

ESLint security .eslintrc* files for eslint-plugin-security or security rules

CSP headers Content-Security-Policy in middleware, meta tags, or config

CORS config cors() middleware config, Access-Control-Allow-Origin settings

Rate limiting express-rate-limit , bottleneck , rate limit middleware

Helmet/headers helmet in dependencies, security header middleware

Input validation joi , zod , yup , class-validator , express-validator

.gitignore

Whether .env , secrets, and keys are excluded

Dependabot .github/dependabot.yml for automated dependency updates

Note what is present and what is missing. This informs recommendations.

Step 6: Output Tailored Recommendation

Based on all detected signals, produce a prioritized list of /appsec:*

tools to run, with rationale for each.

Priority rules:

• /appsec:secrets --scope full is ALWAYS priority 1. Committed secrets are the most common and most damaging solo dev mistake.

• Tools matching detected data sensitivity rank higher (financial data detected -> prioritize business-logic , race-conditions ).

• Tools matching detected architecture rank higher (GraphQL detected -> include graphql ).

• Tools with no relevant attack surface in this project go to the SKIP list.

• Include the "why" for each recommendation -- reference specific files or patterns found.

Output Format

Text Format (default)

===================================================== APPSEC START -- Project Assessment

PROJECT: <project name from package.json or directory> STACK: <languages, frameworks, databases, infra> DATA: <data sensitivity classifications> SCANNERS: <scanner> Y/N <scanner> Y/N ...

RECOMMENDED TOOLS (priority order):

1. /appsec:secrets --scope full WHY: <rationale referencing specific findings>

2. /appsec:<tool> --scope <recommended scope> WHY: <rationale referencing specific findings>

...

SKIP (not relevant for this project):

• /appsec:<tool> (<reason>)
• ...

EXISTING SECURITY:

• <config found> -- <status>
• ...

QUICK START: /appsec:run # Run top priorities automatically /appsec:run --depth deep # Thorough analysis /appsec:run --depth expert # + Red team simulation /appsec:full-audit # Everything, with dated report

=====================================================

JSON Format

{ "project": "<name>", "stack": { "languages": [], "frameworks": [], "databases": [], "infra": [] }, "data_sensitivity": [], "architecture": [], "scanners": { "<name>": true|false }, "existing_security": { "<config>": true|false }, "recommended_tools": [ { "rank": 1, "tool": "secrets", "scope": "full", "rationale": "..." } ], "skip": [ { "tool": "graphql", "reason": "No GraphQL schema found" } ] }

Caching

After assessment, write the results to .appsec/start-assessment.json so that /appsec:run can reuse the detection results without re-scanning. Include a timestamp so stale results can be detected (older than 24 hours or if package.json / manifest mtime has changed).

Follow-Up Prompt

After presenting the assessment, suggest:

Ready to scan? Run one of: /appsec:run Run recommended tools automatically /appsec:<top-priority-tool> Start with the highest priority /appsec:full-audit Exhaustive audit with dated report