con un clic
awesome-claude-security
awesome-claude-security contiene 96 skills recopiladas de jassics, con cobertura ocupacional por repositorio y páginas de detalle dentro del sitio.
Skills en este repositorio
Statically review a Claude Code / AI-agent setup for security misconfigurations — risky hooks, over-broad permissions, untrusted or cleartext MCP servers, hardcoded secrets, endpoint redirection, over-privileged agents/skills, and prompt-injection in steering files. Use when asked to audit a `.claude/` directory, `settings.json`, `.mcp.json`, a plugin/marketplace, or `CLAUDE.md`, or to add a config-security gate to CI. Drives the `agentscanner` CLI.
Review the training / MLOps pipeline for security weaknesses — data-poisoning surface, feature-store and data-source trust, experiment-tracking and model-registry access control, secrets, and reproducibility/provenance. Use when assessing how models are built and promoted, not how they're served or consumed.
Review the provenance and integrity of models, datasets, and ML artifacts pulled from hubs/registries — unsafe deserialization (pickle, PyTorch/Keras/joblib), untrusted model sources, model/dataset tampering, and signing. Use when an app loads third-party model weights or datasets, or before promoting a model.
Harden a deployed model inference endpoint — authn/authz, rate limiting and abuse control, input validation, and exposure to model-extraction / inversion / membership-inference attacks. Use when reviewing how a model is served (REST/gRPC, Triton/TorchServe/KServe, or a hosted inference API), not how it was trained.
Export a finished security artifact (report, executive summary, diagram, spreadsheet of findings) to Google Drive — right folder, clear naming, and shareable with the intended audience. Use when a deliverable needs to be handed to stakeholders who live in Drive/Docs/Sheets rather than a wiki or tracker.
Turn a security finding (vuln, pentest issue, review item) into a well-formed Jira issue — mapped severity→priority, remediation/repro in the body, labels and components set, and dedup-checked against existing issues. Use when findings need to become tracked, assignable work in Jira.
Publish a security report, runbook, threat model, or assessment writeup to Confluence — correct space/parent, consistent page structure, labels, and links back to related issues/pages. Use when a finished document needs to live in the team wiki, not just a local file.
Look up MITRE ATT&CK tactics, techniques, and mitigations, and map an observed behavior, finding, or detection to the right technique ID(s). Use whenever work needs a consistent ATT&CK reference — detection coverage, threat reports, red-team TTP planning, or tagging a finding.
Map a finding, control, or requirement across security frameworks — CWE, NIST CSF & SP 800-53, CIS Controls, ISO/IEC 27001 — so one piece of work can be expressed in whichever framework the audience uses. Use when a finding needs a CWE, or when aligning controls/gaps across compliance frameworks.
Look up and map to the right OWASP Top 10 family — Web, API, LLM, or Mobile — and give the canonical category ID/name for a finding. Use when you need a consistent OWASP reference for tagging findings, scoping a review, or aligning a report across the appsec/genai plugins.
Assess and establish build artifact provenance and integrity — SLSA provenance level, signing/attestation (Sigstore/cosign, in-toto), and verification at deploy/admission. Use when you need to prove an artifact (container image, package, binary) came from the expected source and build, untampered.
Review third-party dependencies for supply-chain trust risk — typosquatting, dependency confusion, maintainer/abandonment risk, unpinned versions, and malicious install scripts — not just known-CVE counts. Use when assessing how much a project trusts code it didn't write, or vetting a new dependency.
Review a CI/CD pipeline for supply-chain tampering risk — build isolation, runner/agent trust, secret exposure, mutable dependencies, and poisoned-pipeline (PPE) / unauthorized-workflow paths. Use when hardening GitHub Actions, GitLab CI, Jenkins, or similar against build-system compromise.
Manage the vulnerability remediation lifecycle: assign owners and SLAs, track fix/verify/close states, handle risk acceptances and exceptions, and report program metrics (SLA compliance, MTTR, aging, recurrence). Use when turning a prioritized list into tracked, accountable work.
Rank a set of vulnerabilities by real-world risk using CVSS (severity), EPSS (exploit probability), CISA KEV (known exploited), and asset/exposure context — so remediation effort goes to what actually matters first. Use when a triaged finding list needs a defensible "fix this first" order.
Triage raw vulnerability-scanner output (Nessus/Qualys/Trivy/Grype/OpenVAS, cloud or container scans): normalize, deduplicate, validate, and cut false positives so the list is trustworthy before prioritization. Use when handed a scan export or a pile of findings that needs to become an actionable backlog.
Gap-assess an organization or system against a compliance framework (SOC 2, ISO 27001, PCI DSS, HIPAA, GDPR, NIST CSF/800-53), mapping controls to evidence, identifying gaps, and producing a prioritized remediation and audit-readiness plan. Use for compliance gap analysis, certification prep, or audit readiness.
Develop or review security governance documents — policies, standards, procedures, and guidelines — aligned to a framework and the organization's risk, with a clear hierarchy, ownership, and lifecycle. Use to write, assess, or rationalize a security policy set.
Run a structured security risk assessment and maintain a risk register — identify, analyze, evaluate, and treat risks (ISO 27005 / NIST SP 800-30) against the organization's risk criteria. Use for an enterprise/security risk assessment, risk register upkeep, or treatment decisions.
Produce a board / executive security presentation — risk posture and direction, top risks in business terms, program progress against strategy, the metrics that matter, and investment asks tied to risk. Use to prepare for a board or leadership meeting. Audience is non-technical decision-makers.
Translate technical security risk into business and financial terms — top risk scenarios, likelihood × impact, a risk register, and (where useful) quantified loss ranges (FAIR-aware) — to support executive decisions on treat/transfer/accept. Use to communicate or prioritize cyber risk for leadership.
Build or assess a security program strategy and roadmap — current-vs-target maturity, gaps, prioritized initiatives aligned to business objectives and risk appetite, with outcomes, metrics, and budget framing. Use for security program planning, a strategy refresh, or a maturity assessment.
Establish or assess an org-wide secure-by-design program — paved roads / golden paths with secure defaults, automated guardrails, and developer enablement — so the secure way is the default, fast way. Use for engineering-org security strategy at scale (not a single system's design).
Assess the security risk of a technology or product decision for leadership — new technology/vendor adoption, build-vs-buy, third-party/supply-chain, or M&A technical due diligence — and give a clear recommendation with trade-offs. Use to inform a strategic technology decision.
Run an authorized network penetration test: host discovery, port/service enumeration, vulnerability identification, exploitation, and lateral movement/pivoting — within an agreed scope and rules of engagement. Use to actively test internal/external network security you're authorized to assess.
Review network segmentation and firewall/ACL design for security: zone separation, ruleset hygiene, lateral-movement containment, and zero-trust / microsegmentation. Use to assess or design network architecture defensively (not active testing).
Assess the network protocols and services in use for security weaknesses — cleartext protocols, weak/outdated crypto and TLS, insecure or legacy services, and man-in-the-middle exposure. Use to review what's running on the network and how securely it communicates.
Discover an organization's public exposures — leaked credentials and secrets, exposed services and storage, source-code/config leaks, and breach data — from public sources. Use to find what's already exposed about a target (offense) or to reduce your own exposure (defense). Authorized scope.
Map a target organization's external footprint and attack surface from public sources — domains, subdomains, IP ranges, exposed services, technologies, and organizational details. Use at the start of an engagement (or for attack-surface management) to see what an attacker sees. Authorized scope, public sources.
Gather people- and organization-focused OSINT for an authorized social-engineering assessment — org structure, roles, contact patterns, and public footprint that inform realistic phishing/pretext scenarios. Use only within an authorized engagement; focus on assessing susceptibility and improving awareness.
Plan and run an objectives-based adversary-emulation engagement: select a relevant threat actor, build an ATT&CK-mapped emulation plan across the attack lifecycle, execute within rules of engagement, and assess detection/response. Use for full-scope red-team work. Strictly authorized engagements only.
Review or design the security of a CI/CD pipeline: shift-left scanning gates (SAST/SCA/secret/IaC), software supply-chain integrity (SBOM, pinning, signing/ provenance), and pipeline hardening (least-privilege runners, isolation, protected branches). Use to build security into the SDLC or assess a pipeline's controls.
Drive a security investigation from a lead or hypothesis to an evidence-backed conclusion — correlate telemetry across sources, enrich with intel, reconstruct a timeline, scope impact, and reach a defensible verdict. Use for a deeper analytical investigation (beyond single-alert triage), e.g. an escalated or complex case.
Review a system or architecture design for security — trust boundaries, control selection, secure-by-design principles, defense-in-depth, and security requirements — and produce prioritized design recommendations. Use when assessing or shaping an architecture/design (not testing a running system).
Plan and run a purple-team exercise: collaboratively emulate specific ATT&CK techniques and measure whether detection and response actually work, then close the gaps. Use to validate defensive coverage against real adversary behavior. Authorized environments only.
Triage a SIEM/EDR alert end-to-end — validate it's real, enrich and scope it, reach a consistent verdict, and decide escalate vs. close with documented rationale. Use when working a SOC alert queue and you need a repeatable, defensible triage.
Assess detection coverage against the MITRE ATT&CK matrix: which tactics/techniques are covered, partially covered, or blind, weighted by data-source availability and threat relevance. Use to find and prioritize detection gaps for a SOC/program.
Develop or review a detection rule (Sigma, YARA, KQL/SPL/EQL) for a specific behavior or threat, mapped to MITRE ATT&CK, with test cases and false-positive tuning. Use when building, porting, or reviewing detections from a TTP, IOC, or incident finding.
Run a hypothesis-driven threat hunt: form a hypothesis (often from ATT&CK or threat intel), query telemetry for evidence, analyze findings, and convert results into detections. Use to proactively search for adversary activity that existing alerts may miss.
Perform forensic triage on a host or artifacts — collect and analyze disk, memory, and log evidence with proper handling, then build an incident timeline. Use to investigate a compromised system or scope an incident. Preserve evidence integrity.