Route methodology skills to real catalog skills instead of dead role names: - platform-engineering: docker-management -> docker-compose - backend-engineering: technical-architect -> api-design-and-evolution, reviewer -> qa-methodology - frontend-engineering: ux-designer -> product-design-and-ux, technical-architect -> api-design-and-evolution, writer -> neutral, reviewer -> qa-methodology - security-audit-methodology: reviewer -> qa-methodology, debugger -> systematic-debugging - data-engineering: UX designer -> product-design-and-ux - technical-documentation: writer -> neutral, technical architect -> software-architecture-analysis, debugger -> systematic-debugging, reviewer -> qa-methodology - operational-design: executive-methodology -> strategy-frameworks - technical-documentation/references/agent-facing-docs.md: drop dead deployment-methodology skill_view example Also bring modified skills' descriptions up to the quality validator's imperative-verb + negative-boundary requirement and regenerate catalogs. agent-council's external hermes-profiles list is retained unchanged. Closes #234 Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
3.7 KiB
name, description, license, compatibility, metadata
| name | description | license | compatibility | metadata | ||||
|---|---|---|---|---|---|---|---|---|
| security-audit-methodology | Plan authorized security reviews with threat modeling, architecture and dependency audits, and vulnerability classification. Use for scoped defensive security assessment. Do not use for offensive operations, unauthorized testing, or security control implementation. | MIT | Authorization for the target system is required. This skill provides defensive methodology, not a substitute for qualified security review. |
|
Security Audit Methodology
Authorization and safety boundary
Before any assessment, confirm the target, scope, permitted techniques, data-handling rules, and escalation contact. Do not probe systems, access accounts, exploit findings, or alter production state without explicit authorization. Record findings as evidence for the responsible owner; this skill does not certify compliance or replace qualified security review.
Security is not a checklist — it's a posture. This methodology covers systematic evaluation of code, architecture, dependencies, and operational practices for security weaknesses.
The Security Engineer's Domain
| You own | You don't own |
|---|---|
| Threat modeling — STRIDE, attack trees, trust boundaries | General code review — that's the qa-methodology |
| Vulnerability assessment — classification, severity, reproduction | Performance analysis — that's the systematic-debugging |
| Security architecture review — authn/authz, data flow, secrets management | Operational reliability — that's SRE |
| Dependency analysis — supply chain, known vulnerabilities, license risk | Compliance certification — that's legal |
| Security testing guidance — fuzzing, SAST/DAST integration | Incident response execution — that's SRE/on-call |
Reference Files
| Reference | When to load |
|---|---|
references/threat-modeling.md |
Evaluating a system's attack surface — STRIDE per component, trust boundaries, data flow analysis |
references/vulnerability-classification.md |
Assessing a finding — CVSS scoring, CWE mapping, severity triage, exploitability assessment |
references/security-architecture-dependency-audit.md |
Reviewing authentication (OAuth 2.0, OIDC, SAML, mTLS), authorization (RBAC/ABAC/ReBAC), session management, secrets management, and dependency/supply chain security (SBOM, CVE matching, license analysis, SLSA framework) |
Core Principles
Trust nothing, verify everything — Every input, every boundary, every assumption is a potential attack surface. Default deny, explicit allow.
Defense in depth — No single control is sufficient. Authentication without rate limiting, encryption without key management, input validation without output encoding — each is a vulnerability waiting to chain.
Least privilege — Every component, every user, every process should have exactly the permissions it needs and no more. Over-privilege is the most common security debt.
Understand the attacker's perspective — The question isn't "can this be exploited?" It's "how would an attacker think about this system?" Model their incentives, constraints, and capabilities.
Fix the class, not the instance — One SQL injection means you need parameterized queries everywhere, not just at that one endpoint. A single XSS means review the entire rendering pipeline.
Portability
This skill is intentionally host-neutral. Use your agent's normal mechanisms to load the references, templates, and scripts listed here. Do not assume a particular profile system, task orchestrator, memory service, or response-handoff format.