MayrosSkills Hub
Back to browse

security-audit

ApiliumApiliumv1.0.34300
officialplatinum (7/8)Clean scan

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_assert with audit:vulnerability predicate for confirmed findings (confidence >80%). Proof is required.
  • Use skill_assert with audit:clean predicate when the audit completes with no vulnerabilities found. Proof is required.
  • Use skill_assert with audit:recommendation for medium-confidence findings (60-80%).
  • Consult skill_memory_context for 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

v1.0.3Feb 27, 2026
v1.0.2Feb 27, 2026
v1.0.1Feb 27, 2026
v1.0.0Feb 26, 2026

Comments

Sign in to leave a comment.

Loading comments...