diff --git a/README.md b/README.md index 97d5e85..1a737b9 100644 --- a/README.md +++ b/README.md @@ -27,6 +27,17 @@ for information about our development standards. - We want to help interpret and respond to these reports - they can be confusing, may contain false positives, and will raise questions. - Campus IT Professionals can contact securitysupport@illinois.edu. +## Installation + +```bash +cd ~/projects +git clone https://github.com/techservicesillinois/secdev-code-risk-tools +cd ~/projects/my_project_1 +gh skill install --from-local ~/projects/secdev-code-risk-tools/ +``` + +Then follow the interactive prompts to choose between the available skills, where they should be available, and for which AI tools. + ## Data Sources For data sensitivity, see [Data Classification](https://www.cybersecurity.illinois.edu/data-classification/). diff --git a/code-cost/SKILL.md b/code-cost/SKILL.md new file mode 100644 index 0000000..5c1761f --- /dev/null +++ b/code-cost/SKILL.md @@ -0,0 +1,46 @@ +--- +name: code-cost +description: Measures the cost of the project in terms of maintainability and complexity. +--- + +## Analyzing maintainability + +Use this skill when asked to assess code quality, complexity, technical debt, +or "how maintainable is this codebase". + +## Setup + +Prompt the user for where to install tools and output reports. +Default to using a temporary directory. + +## Setup if there are JavaScript files + +Use `eslint` to assess code quality. +Use `knip` to look for dead code in JavaScript code files. + +## Setup if there are Python files + +If the project contains Python code, install Python static analysis tools: + +```bash +python -m venv .venv.analysis +.venv.analysis/bin/pip install radon vulture pycodestats +``` + +Use `radon` to analyze Python file code complexity. + +- Maintainability index for Python comes from `radon mi -j`. +- Treat rank `C` (MI less than 10) as a real problem worth flagging in a summary. + +Use `vulture` to look for dead code in Python files. + +- Use `vulture --min-confidence 80`. +- `vulture` output is informational only — cross-check a few hits before recommending deletion, since dynamic dispatch can cause false positives. + +Use `pycodestats` to generate counts of lines of code in Python files. + +## Report Format + +- When summarizing for a human, lead with the handful of worst offending files. +- Prompt the user where to place the output report. +- Default to a name that includes `code-cost` and the current project name, and the current date. diff --git a/code-risk/SKILL.md b/code-risk/SKILL.md new file mode 100644 index 0000000..12849aa --- /dev/null +++ b/code-risk/SKILL.md @@ -0,0 +1,170 @@ +--- +name: code-risk +description: 'Conduct a read-only cybersecurity review of application code and configuration. Use when: performing a security audit, checking for OWASP Top 10 vulnerabilities, reviewing authentication or authorization logic, identifying injection risks, finding exposed secrets or misconfigured CSP headers, auditing third-party dependencies, or assessing input validation and output encoding. Produces a findings report.' +argument-hint: 'Optional: scope (e.g., "auth module", "API layer", "all files")' +--- + +# Cybersecurity Review + + +## Purpose + +Audit code, configuration, and dependencies for security vulnerabilities and produce a structured findings report. Agents should treat this skill as **read-only**. + +## When to Use + +- Security audit before a release or deployment +- Reviewing authentication, session management, or authorization code +- Checking CSP headers, CORS policy, or other HTTP security controls +- Identifying injection risks (SQL, XSS, command injection, etc.) +- Auditing third-party dependencies for known CVEs +- Scanning for hardcoded secrets or credentials in source code +- Assessing input validation and output encoding + +______________________________________________________________________ + +## Procedure + +### 1. Determine Scope + +If the user specified a scope (e.g., a module or file path), limit the review to that area. Otherwise, review the full workspace. Identify: + +- Entry points (HTTP handlers, CLI args, form inputs, file uploads) +- Trust boundaries (client/server, user/admin, external APIs) +- Data flows involving sensitive information + +### 2. Gather Context (Read-Only) + +Use search and file-reading tools to collect: + +- Source files +- Configuration files +- Dependency manifests +- Build/deploy scripts + +You may run `npm audit --json` for informational output. + +### 3. Evaluate Against Security Categories + +Check each applicable category below and record any findings. + +#### A01 — Broken Access Control + +- Are authorization checks present on all protected routes/resources? +- Can users access resources belonging to other users (IDOR)? +- Is the principle of least privilege applied? + +#### A02 — Cryptographic Failures + +- Is sensitive data (PII, tokens, passwords) transmitted or stored in plaintext? +- Are weak or deprecated algorithms in use (MD5, SHA1, DES)? +- Are TLS/HTTPS enforced for all external connections? + +#### A03 — Injection + +- Are user inputs sanitized or parameterized before use in queries, shell commands, or template engines? +- Is `innerHTML`, `dangerouslySetInnerHTML`, `eval()`, or `document.write()` used with user-controlled data? +- Are SQL/NoSQL queries built with string concatenation? + +#### A04 — Insecure Design + +- Are there missing rate limits on authentication or sensitive endpoints? +- Is business logic enforced server-side, or only client-side? + +#### A05 — Security Misconfiguration + +- Are default credentials or example configs present? +- Are debug modes, verbose error messages, or stack traces exposed in production? +- Are unnecessary features, ports, or services enabled? +- Are HTTP security headers present and correctly configured (CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy)? + +#### A06 — Vulnerable and Outdated Components + +- Do dependency manifests include packages with known CVEs? +- Are dependencies pinned to specific versions? +- Are dev dependencies accidentally included in production builds? + +#### A07 — Identification and Authentication Failures + +- Are session tokens sufficiently random and rotated after login? +- Are there protections against brute force (lockouts, CAPTCHA, rate limiting)? +- Are passwords hashed with a modern algorithm (bcrypt, argon2, scrypt)? + +#### A08 — Software and Data Integrity Failures + +- Are third-party scripts loaded from CDNs with Subresource Integrity (SRI) hashes? +- Is CI/CD pipeline configuration reviewed for unauthorized modification risks? + +#### A09 — Security Logging and Monitoring Failures + +- Are security-relevant events (login failures, access denials) logged? +- Are logs free of sensitive data (passwords, tokens, PII)? + +#### A10 — Server-Side Request Forgery (SSRF) + +- Does the application make HTTP requests to URLs supplied by the user? +- Are allow-lists used to restrict permissible destinations? + +#### Additional Checks + +- **Secrets in source**: Look for hardcoded API keys, tokens, passwords, or private keys in source files and git history hints. +- **Cookie security**: Are `HttpOnly`, `Secure`, and `SameSite` attributes set on sensitive cookies? +- **Content Security Policy**: Is a CSP defined? Does it avoid `unsafe-inline` or `unsafe-eval`? +- **Dependency confusion**: Are internal package names squattable on public registries? +- **Supply chain**: Are `package-lock.json` or equivalent dependency files omitted from source control? + +### 4. Compile the Findings Report + +Structure the report as follows. Omit sections with no findings. + +Use the report text below verbatim replacing placeholders with actual values. If a finding requires further investigation beyond available tools, note it as "Needs manual review". + +## Findings Report + +**Reviewed:** `` +**Date:** `` + +The purpose of this document is to help DevOps staff associated with the University of Illinois fulfill their [responsibility](https://cam.illinois.edu/policies/fo-36) to comply with Illinois Cybersecurity standards, including[IT05](https://go.illinois.edu/secstd-IT05), [IT07](https://go.illinois.edu/secstd-IT07), [IT08](https://go.illinois.edu/secstd-IT08), and [IT13](https://go.illinois.edu/secstd-IT13). + +This skill is a DRAFT. Rather than share this DRAFT, please encourage colleagues to contact securitysupport@illinois.edu for the latest version. + +This document is [TLP:AMBER](https://www.cisa.gov/news-events/news/traffic-light-protocol-tlp-definitions-and-usage), as it may contain information about potential vulnerabilities in a live campus service. This document should be shared only within the impacted team and the Privacy and Cybersecurity teams, and with their leadership, as needed, but otherwise kept confidential. + +Faculty and staff of the the University of Illinois may contact securitysupport@illinois.edu for assistance with understanding these results. + +### Summary + +| OWASP Category | Count | +|-----------------------------------------------------|-------| +| A01 — Broken Access Control | N | +| A02 — Cryptographic Failures | N | +| A03 — Injection | N | +| A04 — Insecure Design | N | +| A05 — Security Misconfiguration | N | +| A06 — Vulnerable and Outdated Components | N | +| A07 — Identification and Authentication Failures | N | +| A08 — Software and Data Integrity Failures | N | +| A09 — Security Logging and Monitoring Failures | N | +| A10 — Server-Side Request Forgery (SSRF) | N | +| Other Findings | N | + +______________________________________________________________________ + +### Findings + +For each finding, use this format: + +#### Title — Category + +**File/Location:** `path/to/file.ts:line` +**Description:** What the vulnerability is and why it matters. +**Evidence:** Relevant code snippet or configuration value (quote directly from source). +**Recommendation:** What should be done to remediate (description only). +**Reference:** OWASP link and CVE if applicable. + +______________________________________________________________________ + +## Constraints + +- This skill is meant to produce findings only. +- If a finding requires further investigation beyond available tools, note it as "Needs manual review" rather than speculating.