security-audit
Install
mayros skill install security-audit
mayros skill install [email protected]
Vulnerability detection with OWASP Top 10 mapping and confidence scoring
README
name: security-audit description: Vulnerability detection with OWASP Top 10 mapping and confidence scoring type: semantic user-invocable: true semantic: skillVersion: 1 permissions: graph: [read, write] proofs: [request, verify] memory: [recall, remember] assertions: - predicate: "audit:vulnerability" requireProof: true - predicate: "audit:clean" requireProof: true - predicate: "audit:recommendation" requireProof: false queries: - predicate: "audit:vulnerability" scope: agent - predicate: "audit:history" scope: namespace
security-audit
Comprehensive vulnerability detection with OWASP Top 10 (2021) mapping, confidence scoring, and data-flow tracing. Designed for production security review of codebases, APIs, and infrastructure configurations.
Audit Methodology
1. Confidence Scoring
Every finding includes a confidence score (0-100%) reflecting how certain the auditor is that the vulnerability is real and exploitable:
| Level | Range | Action | |-------|-------|--------| | confirmed | >95% | Report as vulnerability, proof required | | high | 80-95% | Report as vulnerability, proof required | | medium | 60-80% | Report as recommendation only | | low | <60% | Do not report --- insufficient evidence |
Only report findings with confidence above 80% as vulnerabilities. Findings between 60-80% are downgraded to recommendations. Anything below 60% is suppressed entirely to avoid false-positive fatigue.
2. OWASP Top 10 Mapping
All findings are mapped to the OWASP Top 10 (2021) with corresponding CWE identifiers:
- A01 - Broken Access Control (CWE-284): Missing function-level access control, insecure direct object references, CORS misconfiguration, metadata manipulation, path traversal.
- A02 - Cryptographic Failures (CWE-327): Use of broken algorithms (MD5, SHA1, DES), hardcoded secrets, missing TLS, insufficient key sizes (<2048 RSA, <256 AES).
- A03 - Injection (CWE-79 XSS, CWE-89 SQLi, CWE-78 OS Command Injection): Unsanitized input reaching SQL, shell, HTML, LDAP, XPath, or ORM sinks. Trace from source to sink.
- A04 - Insecure Design: Business logic flaws, missing threat modeling artifacts, insufficient rate limiting, predictable resource identifiers.
- A05 - Security Misconfiguration: Default credentials, debug endpoints in production, overly permissive policies, missing security headers (CSP, HSTS, X-Frame-Options).
- A06 - Vulnerable and Outdated Components: Dependencies with known CVEs, End-of-Life runtime versions, missing lockfiles.
- A07 - Identification and Authentication Failures (CWE-287): Weak password storage (plain text, unsalted), missing brute-force protection, session fixation, insecure "remember me".
- A08 - Software and Data Integrity Failures (CWE-502): Insecure deserialization, unsigned CI/CD artifacts, auto-update without signature verification.
- A09 - Security Logging and Monitoring Failures (CWE-778): No audit trail for sensitive operations, PII in logs, missing anomaly detection hooks.
- A10 - Server-Side Request Forgery (CWE-918): User-controlled URLs passed to server-side HTTP clients, missing URL allowlists, DNS rebinding.
3. Data Flow Tracing
For injection and data-handling vulnerabilities, trace the complete data flow:
Source -> Sanitizers (if any) -> Sink
- Source: User input entry points (request params, headers, body, file uploads, environment variables, database reads).
- Sanitizers: Validation, encoding, escaping, parameterization functions applied along the path.
- Sink: Dangerous operations (SQL execution, shell commands, HTML rendering, file system writes, HTTP requests).
A vulnerability is confirmed when a tainted source reaches a dangerous sink without adequate sanitization.
4. Risk Score Calculation
Risk Score = Severity Weight x (Confidence / 100)
Severity weights:
- critical = 4
- high = 3
- medium = 2
- low = 1
A critical finding with 90% confidence gets risk score 3.6. Findings are sorted by risk score descending to prioritize remediation.
5. Exclusions
The following are explicitly out of scope for this audit:
- Denial of Service (DoS) attacks (resource exhaustion, algorithmic complexity)
- Secrets on disk (use dedicated secret scanning tools)
- Rate limiting as a standalone finding (covered under A04 Insecure Design only when part of business logic)
- Memory safety issues in managed languages (unless directly exploitable)
6. Semantic Integration
- Use
skill_assertwithaudit:vulnerabilitypredicate for confirmed findings (confidence >80%). Proof is required. - Use
skill_assertwithaudit:cleanpredicate when the audit completes with no vulnerabilities found. Proof is required. - Use
skill_assertwithaudit:recommendationfor medium-confidence findings (60-80%). - Consult
skill_memory_contextfor historical audit data to track remediation progress.
7. Output Format
Each vulnerability finding includes:
ID: <unique identifier>
Title: <short description>
Severity: critical | high | medium | low
Confidence: <0-100>%
Confidence Level: confirmed | high | medium | low
OWASP: <A01-A10 category>
CWE: <CWE-ID>
Description: <detailed explanation>
Data Flow: source -> sanitizers -> sink
Recommendation: <remediation guidance>
Risk Score: <computed score>
8. Audit Summary
The final report includes:
- Total findings by severity
- Overall risk score (sum of individual risk scores)
- Top OWASP categories affected
- Clean areas (components that passed all checks)
- Comparison with previous audits (if history available)
Versions
Comments
Sign in to leave a comment.
Loading comments...