[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71GGYNHHCBYJKBJAB4WYFRP":3,"skill-same:01M71GGYNHHCBYJKBJAB4WYFRP":84},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":31,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":14,"repositoryHtmlUrl":60,"repositoryHomepageUrl":6,"ownerHtmlUrl":61,"ownerBlogUrl":6,"ownerDescription":62,"updatedAt":63,"install":64,"resources":77},"01M71GGYNHHCBYJKBJAB4WYFRP","sca-SKILL.md",null,">\n  This skill covers implementing Software Composition Analysis (SCA) using Snyk to detect vulnerable open-source dependencies in CI\u002FCD pipelines. It addresses scanning package manifests and lockfiles, automated fix pull request generation, license compliance checking, continuous monitoring of deployed applications, and integration with GitHub, GitLab, and Jenkins pipelines.","DCx7C5\u002Fai-marketplace","DCx7C5","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42419559?v=4","01M71C01G2AZV3NTNGWAWSHJPP","DC","01M71C01GQW6G50S2BYMS7PP3E",0,"MIT","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fvuln\u002Fsca\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"sca SKILL md","skill md","SCA","license compliance","pull","source","addresses","software","CI\u002FCD","request","scanning","gitlab","monitoring","analysis","manifests","open","implementing","ci","fix","Composition","2026-11-10 10:12:30",false,"---\nname: sca-SKILL.md\ndescription: \">\\n  This skill covers implementing Software Composition Analysis (SCA)\\\n  \\ using Snyk to detect vulnerable open-source dependencies in CI\u002FCD pipelines. It\\\n  \\ addresses scanning package manifests and lockfiles, automated fix pull request\\\n  \\ generation, license compliance checking, continuous monitoring of deployed applications,\\\n  \\ and integration with GitHub, GitLab, and Jenkins pipelines.\"\n---\n# Performing SCA Dependency Scanning with Snyk\n\n## When to Use\n\n- When applications use open-source packages that may contain known vulnerabilities\n- When compliance requires tracking and remediating vulnerable dependencies (PCI DSS, SOC 2)\n- When needing automated fix PRs for vulnerable dependencies in CI\u002FCD\n- When license compliance requires visibility into open-source license obligations\n- When continuous monitoring is needed for newly disclosed vulnerabilities in deployed dependencies\n\n**Do not use** for scanning proprietary application code for logic vulnerabilities (use SAST), for runtime vulnerability detection (use DAST), or for container OS package scanning alone (use Trivy for a free alternative).\n\n## Prerequisites\n\n- Snyk account (free tier covers up to 200 tests per month for open source)\n- Snyk CLI installed or Snyk GitHub\u002FGitLab integration configured\n- SNYK_TOKEN environment variable set with API authentication token\n- Project with supported package manifests: package.json, requirements.txt, pom.xml, go.mod, Gemfile, etc.\n\n## Workflow\n\n### Step 1: Install and Authenticate Snyk CLI\n\n```bash\n# Install Snyk CLI\nnpm install -g snyk\n\n# Authenticate with Snyk\nsnyk auth $SNYK_TOKEN\n\n# Test the connection\nsnyk test --json | jq '.summary'\n```\n\n### Step 2: Scan Dependencies in CI\u002FCD Pipeline\n\n```yaml\n# .github\u002Fworkflows\u002Fdependency-scan.yml\nname: Dependency Security Scan\n\non:\n  push:\n    branches: [main]\n  pull_request:\n    branches: [main]\n  schedule:\n    - cron: '0 8 * * 1'  # Weekly Monday 8am\n\njobs:\n  snyk-scan:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v4\n\n      - name: Setup Node.js\n        uses: actions\u002Fsetup-node@v4\n        with:\n          node-version: '20'\n\n      - name: Install dependencies\n        run: npm ci\n\n      - name: Run Snyk to check for vulnerabilities\n        uses: snyk\u002Factions\u002Fnode@master\n        env:\n          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}\n        with:\n          args: >\n            --severity-threshold=high\n            --fail-on=upgradable\n            --json-file-output=snyk-results.json\n\n      - name: Upload results to Snyk\n        if: always()\n        uses: snyk\u002Factions\u002Fnode@master\n        env:\n          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}\n        with:\n          command: monitor\n          args: --project-name=${{ github.repository }}\n\n      - name: Upload SARIF\n        if: always()\n        run: |\n          npx snyk-to-html -i snyk-results.json -o snyk-report.html\n```\n\n### Step 3: Configure Snyk for Multiple Languages\n\n```bash\n# Python project scanning\nsnyk test --file=requirements.txt --severity-threshold=high --json > snyk-python.json\n\n# Java\u002FMaven project\nsnyk test --file=pom.xml --severity-threshold=medium --json > snyk-java.json\n\n# Go module scanning\nsnyk test --file=go.mod --severity-threshold=high --json > snyk-go.json\n\n# Docker image dependency scanning\nsnyk container test myapp:latest --severity-threshold=high --json > snyk-container.json\n\n# Monorepo: scan all projects\nsnyk test --all-projects --severity-threshold=high --json > snyk-all.json\n\n# IaC scanning (bonus)\nsnyk iac test terraform\u002F --severity-threshold=medium --json > snyk-iac.json\n```\n\n### Step 4: Configure Snyk Policies for Organization\n\n```yaml\n# .snyk policy file\nignore:\n  SNYK-JS-LODASH-1018905:\n    - '*':\n        reason: \"Prototype pollution in lodash. Not exploitable in our usage - no user input reaches affected function.\"\n        expires: 2026-06-01T00:00:00.000Z\n        created: 2026-02-23T00:00:00.000Z\n\n  SNYK-PYTHON-REQUESTS-6241864:\n    - '*':\n        reason: \"SSRF in requests redirect handling. Mitigated by allowlist at proxy layer.\"\n        expires: 2026-04-01T00:00:00.000Z\n\npatch: {}\n\n# Severity threshold for CI failures\nfailOnSeverity: high\n```\n\n### Step 5: Enable Automated Fix Pull Requests\n\n```bash\n# Snyk fix: generate fix PRs for vulnerable dependencies\nsnyk fix --dry-run  # Preview changes\n\n# Apply fixes locally\nsnyk fix\n\n# Enable auto-fix PRs via Snyk dashboard:\n# 1. Navigate to Organization Settings > Integrations > GitHub\n# 2. Enable \"Automatic fix pull requests\"\n# 3. Set \"Fix only direct dependencies\" or \"Fix direct and transitive\"\n# 4. Configure branch target (main or develop)\n```\n\n### Step 6: License Compliance Scanning\n\n```bash\n# Check license compliance\nsnyk test --json | jq '.licensesPolicy'\n\n# Snyk license policy configuration via organization settings:\n# - Approved licenses: MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC\n# - Restricted licenses: GPL-3.0, AGPL-3.0 (copyleft risk)\n# - Unknown licenses: Flag for manual review\n```\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| SCA | Software Composition Analysis — identifies vulnerabilities and license risks in open-source dependencies |\n| Transitive Dependency | A dependency of a direct dependency, often invisible to developers but still a vulnerability vector |\n| Fix PR | Automated pull request generated by Snyk that upgrades a vulnerable dependency to a patched version |\n| Snyk Monitor | Continuous monitoring mode that watches deployed projects for newly disclosed vulnerabilities |\n| Exploit Maturity | Snyk's assessment of whether a vulnerability has known exploits, proof-of-concept, or no known exploit |\n| Reachable Vulnerability | A vulnerability in a function that is actually called by the application code, not just present in the dependency |\n| License Policy | Organization-level rules defining which open-source licenses are approved, restricted, or require review |\n\n## Tools & Systems\n\n- **Snyk Open Source**: SCA tool for scanning dependencies across 10+ language ecosystems\n- **Snyk CLI**: Command-line interface for local and CI\u002FCD scanning of dependencies\n- **Snyk Advisor**: Package health scoring tool evaluating maintenance, popularity, and security signals\n- **OWASP Dependency-Check**: Free alternative SCA tool using NVD data for vulnerability matching\n- **npm audit \u002F pip-audit**: Language-specific built-in audit tools for basic vulnerability checking\n\n## Common Scenarios\n\n### Scenario: Triaging a Critical Transitive Dependency Vulnerability\n\n**Context**: Snyk reports a critical RCE vulnerability in a transitive dependency (log4j in a Java application). The direct dependency has not released a patch.\n\n**Approach**:\n1. Use `snyk test --json` and examine the dependency path to identify which direct dependency pulls in the vulnerable transitive\n2. Check exploit maturity: if \"Mature\" or \"Proof of Concept\", prioritize immediately\n3. If no direct fix exists, use Snyk's patch mechanism or override the transitive version in the build config\n4. For Maven: add `\u003CdependencyManagement>` section to force the safe version of the transitive dependency\n5. For npm: add an `overrides` section in package.json to pin the safe version\n6. Add a Snyk ignore with expiration date if no patch is available yet\n7. Monitor the direct dependency for a release that updates the transitive\n\n**Pitfalls**: Ignoring transitive vulnerabilities because \"we don't use that function directly\" is risky. Attackers can chain vulnerabilities across dependency boundaries. Version overrides can break API compatibility between the direct and transitive dependency.\n\n## Output Format\n\n```\nSnyk Dependency Scan Report\n=============================\nProject: org\u002Fweb-application\nManifest: package.json\nDependencies: 342 (47 direct, 295 transitive)\nScan Date: 2026-02-23\n\nVULNERABILITY SUMMARY:\n  Critical: 1  (1 fixable)\n  High: 4      (3 fixable)\n  Medium: 12   (8 fixable)\n  Low: 23      (15 fixable)\n\nCRITICAL:\n  SNYK-JS-EXPRESS-1234567\n    Package: express@4.17.1 (direct)\n    Severity: Critical (CVSS 9.8)\n    Exploit: Mature\n    Fix: Upgrade to express@4.21.0\n    Path: express@4.17.1\n\nHIGH:\n  SNYK-JS-JSONWEBTOKEN-5678901\n    Package: jsonwebtoken@8.5.1 (transitive)\n    Severity: High (CVSS 7.6)\n    Exploit: Proof of Concept\n    Fix: Upgrade passport@0.7.0 (which upgrades jsonwebtoken)\n    Path: passport@0.6.0 > jsonwebtoken@8.5.1\n\nLICENSE ISSUES:\n  [RESTRICTED] GPL-3.0: some-package@1.2.3 (transitive via other-pkg)\n\nQUALITY GATE: FAILED (1 Critical with fix available)\n```\n\n\n---\n\n## CyberSecSuite Integration\n\n```bash\n# Open a case before starting investigation\nmcp__cybersec__case_open --title \"sca\" --type investigation\n\n# Persist findings to PostgreSQL\nmcp__cybersec__add_finding --title \"...\" --severity high --description \"...\"\n\n# Log IOCs\nmcp__cybersec__add_ioc --type domain --value \"...\" --confidence 0.9\n\n# Map to MITRE\nmcp__cybersec__suggest_mitre --description \"...\"\n```\n\n**Agent:** `@cybersec-agent` → delegates to appropriate specialist\n","# Performing SCA Dependency Scanning with Snyk\n\n## When to Use\n\n- When applications use open-source packages that may contain known vulnerabilities\n- When compliance requires tracking and remediating vulnerable dependencies (PCI DSS, SOC 2)\n- When needing automated fix PRs for vulnerable dependencies in CI\u002FCD\n- When license compliance requires visibility into open-source license obligations\n- When continuous monitoring is needed for newly disclosed vulnerabilities in deployed dependencies\n\n**Do not use** for scanning proprietary application code for logic vulnerabilities (use SAST), for runtime vulnerability detection (use DAST), or for container OS package scanning alone (use Trivy for a free alternative).\n\n## Prerequisites\n\n- Snyk account (free tier covers up to 200 tests per month for open source)\n- Snyk CLI installed or Snyk GitHub\u002FGitLab integration configured\n- SNYK_TOKEN environment variable set with API authentication token\n- Project with supported package manifests: package.json, requirements.txt, pom.xml, go.mod, Gemfile, etc.\n\n## Workflow\n\n### Step 1: Install and Authenticate Snyk CLI\n\n```bash\n# Install Snyk CLI\nnpm install -g snyk\n\n# Authenticate with Snyk\nsnyk auth $SNYK_TOKEN\n\n# Test the connection\nsnyk test --json | jq '.summary'\n```\n\n### Step 2: Scan Dependencies in CI\u002FCD Pipeline\n\n```yaml\n# .github\u002Fworkflows\u002Fdependency-scan.yml\nname: Dependency Security Scan\n\non:\n  push:\n    branches: [main]\n  pull_request:\n    branches: [main]\n  schedule:\n    - cron: '0 8 * * 1'  # Weekly Monday 8am\n\njobs:\n  snyk-scan:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\u002Fcheckout@v4\n\n      - name: Setup Node.js\n        uses: actions\u002Fsetup-node@v4\n        with:\n          node-version: '20'\n\n      - name: Install dependencies\n        run: npm ci\n\n      - name: Run Snyk to check for vulnerabilities\n        uses: snyk\u002Factions\u002Fnode@master\n        env:\n          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}\n        with:\n          args: >\n            --severity-threshold=high\n            --fail-on=upgradable\n            --json-file-output=snyk-results.json\n\n      - name: Upload results to Snyk\n        if: always()\n        uses: snyk\u002Factions\u002Fnode@master\n        env:\n          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}\n        with:\n          command: monitor\n          args: --project-name=${{ github.repository }}\n\n      - name: Upload SARIF\n        if: always()\n        run: |\n          npx snyk-to-html -i snyk-results.json -o snyk-report.html\n```\n\n### Step 3: Configure Snyk for Multiple Languages\n\n```bash\n# Python project scanning\nsnyk test --file=requirements.txt --severity-threshold=high --json > snyk-python.json\n\n# Java\u002FMaven project\nsnyk test --file=pom.xml --severity-threshold=medium --json > snyk-java.json\n\n# Go module scanning\nsnyk test --file=go.mod --severity-threshold=high --json > snyk-go.json\n\n# Docker image dependency scanning\nsnyk container test myapp:latest --severity-threshold=high --json > snyk-container.json\n\n# Monorepo: scan all projects\nsnyk test --all-projects --severity-threshold=high --json > snyk-all.json\n\n# IaC scanning (bonus)\nsnyk iac test terraform\u002F --severity-threshold=medium --json > snyk-iac.json\n```\n\n### Step 4: Configure Snyk Policies for Organization\n\n```yaml\n# .snyk policy file\nignore:\n  SNYK-JS-LODASH-1018905:\n    - '*':\n        reason: \"Prototype pollution in lodash. Not exploitable in our usage - no user input reaches affected function.\"\n        expires: 2026-06-01T00:00:00.000Z\n        created: 2026-02-23T00:00:00.000Z\n\n  SNYK-PYTHON-REQUESTS-6241864:\n    - '*':\n        reason: \"SSRF in requests redirect handling. Mitigated by allowlist at proxy layer.\"\n        expires: 2026-04-01T00:00:00.000Z\n\npatch: {}\n\n# Severity threshold for CI failures\nfailOnSeverity: high\n```\n\n### Step 5: Enable Automated Fix Pull Requests\n\n```bash\n# Snyk fix: generate fix PRs for vulnerable dependencies\nsnyk fix --dry-run  # Preview changes\n\n# Apply fixes locally\nsnyk fix\n\n# Enable auto-fix PRs via Snyk dashboard:\n# 1. Navigate to Organization Settings > Integrations > GitHub\n# 2. Enable \"Automatic fix pull requests\"\n# 3. Set \"Fix only direct dependencies\" or \"Fix direct and transitive\"\n# 4. Configure branch target (main or develop)\n```\n\n### Step 6: License Compliance Scanning\n\n```bash\n# Check license compliance\nsnyk test --json | jq '.licensesPolicy'\n\n# Snyk license policy configuration via organization settings:\n# - Approved licenses: MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC\n# - Restricted licenses: GPL-3.0, AGPL-3.0 (copyleft risk)\n# - Unknown licenses: Flag for manual review\n```\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| SCA | Software Composition Analysis — identifies vulnerabilities and license risks in open-source dependencies |\n| Transitive Dependency | A dependency of a direct dependency, often invisible to developers but still a vulnerability vector |\n| Fix PR | Automated pull request generated by Snyk that upgrades a vulnerable dependency to a patched version |\n| Snyk Monitor | Continuous monitoring mode that watches deployed projects for newly disclosed vulnerabilities |\n| Exploit Maturity | Snyk's assessment of whether a vulnerability has known exploits, proof-of-concept, or no known exploit |\n| Reachable Vulnerability | A vulnerability in a function that is actually called by the application code, not just present in the dependency |\n| License Policy | Organization-level rules defining which open-source licenses are approved, restricted, or require review |\n\n## Tools & Systems\n\n- **Snyk Open Source**: SCA tool for scanning dependencies across 10+ language ecosystems\n- **Snyk CLI**: Command-line interface for local and CI\u002FCD scanning of dependencies\n- **Snyk Advisor**: Package health scoring tool evaluating maintenance, popularity, and security signals\n- **OWASP Dependency-Check**: Free alternative SCA tool using NVD data for vulnerability matching\n- **npm audit \u002F pip-audit**: Language-specific built-in audit tools for basic vulnerability checking\n\n## Common Scenarios\n\n### Scenario: Triaging a Critical Transitive Dependency Vulnerability\n\n**Context**: Snyk reports a critical RCE vulnerability in a transitive dependency (log4j in a Java application). The direct dependency has not released a patch.\n\n**Approach**:\n1. Use `snyk test --json` and examine the dependency path to identify which direct dependency pulls in the vulnerable transitive\n2. Check exploit maturity: if \"Mature\" or \"Proof of Concept\", prioritize immediately\n3. If no direct fix exists, use Snyk's patch mechanism or override the transitive version in the build config\n4. For Maven: add `\u003CdependencyManagement>` section to force the safe version of the transitive dependency\n5. For npm: add an `overrides` section in package.json to pin the safe version\n6. Add a Snyk ignore with expiration date if no patch is available yet\n7. Monitor the direct dependency for a release that updates the transitive\n\n**Pitfalls**: Ignoring transitive vulnerabilities because \"we don't use that function directly\" is risky. Attackers can chain vulnerabilities across dependency boundaries. Version overrides can break API compatibility between the direct and transitive dependency.\n\n## Output Format\n\n```\nSnyk Dependency Scan Report\n=============================\nProject: org\u002Fweb-application\nManifest: package.json\nDependencies: 342 (47 direct, 295 transitive)\nScan Date: 2026-02-23\n\nVULNERABILITY SUMMARY:\n  Critical: 1  (1 fixable)\n  High: 4      (3 fixable)\n  Medium: 12   (8 fixable)\n  Low: 23      (15 fixable)\n\nCRITICAL:\n  SNYK-JS-EXPRESS-1234567\n    Package: express@4.17.1 (direct)\n    Severity: Critical (CVSS 9.8)\n    Exploit: Mature\n    Fix: Upgrade to express@4.21.0\n    Path: express@4.17.1\n\nHIGH:\n  SNYK-JS-JSONWEBTOKEN-5678901\n    Package: jsonwebtoken@8.5.1 (transitive)\n    Severity: High (CVSS 7.6)\n    Exploit: Proof of Concept\n    Fix: Upgrade passport@0.7.0 (which upgrades jsonwebtoken)\n    Path: passport@0.6.0 > jsonwebtoken@8.5.1\n\nLICENSE ISSUES:\n  [RESTRICTED] GPL-3.0: some-package@1.2.3 (transitive via other-pkg)\n\nQUALITY GATE: FAILED (1 Critical with fix available)\n```\n\n\n---\n\n## CyberSecSuite Integration\n\n```bash\n# Open a case before starting investigation\nmcp__cybersec__case_open --title \"sca\" --type investigation\n\n# Persist findings to PostgreSQL\nmcp__cybersec__add_finding --title \"...\" --severity high --description \"...\"\n\n# Log IOCs\nmcp__cybersec__add_ioc --type domain --value \"...\" --confidence 0.9\n\n# Map to MITRE\nmcp__cybersec__suggest_mitre --description \"...\"\n```\n\n**Agent:** `@cybersec-agent` → delegates to appropriate specialist\n",{"name":5,"description":7},"main","a91f1293287ffa9f4f1b8f486cd6e835a1568c84","skills\u002Fvuln\u002Fsca","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace","https:\u002F\u002Fgithub.com\u002FDCx7C5","#Python","2026-09-01 11:21:00",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add DCx7C5\u002Fai-marketplace --skill sca-SKILL.md",{"tool":70,"command":71},"bunx","bunx skills add DCx7C5\u002Fai-marketplace --skill sca-SKILL.md",{"tool":73,"command":74},"pnpm","pnpm dlx skills add DCx7C5\u002Fai-marketplace --skill sca-SKILL.md","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fvuln\u002Fsca\u002FSKILL.md",true,[78],{"path":79,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"index.json","REFERENCE","参考文档",778,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fvuln\u002Fsca\u002Findex.json",[85,111,133,154,176,192],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":52},"01M71HAPZ01KQ30RKTB0FFSQ05","services-wmi-persistence-detect","Detect WMI event subscription persistence by enumerating ActiveScriptEventConsumer, CommandLineEventConsumer, and permanent subscriptions in the WMI repository.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fservices\u002Fwmi\u002Fpersistence\u002Fdetect\u002FSKILL.md",[],[92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110],"services","detect","services wmi persistence detect","wmi","persistence","de","cm","process","activescript","event","subscriptions","commandline-consumer","repository","subscription","event-subscription","t1546.003","forensics","cybersecurity","process-forensics",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":52},"01M71HAK6JTTTS229T17WJMMCG","services-wmi-exec-exploit","Perform lateral movement across Windows networks using WMI-based remote execution techniques including Impacket wmiexec.py, CrackMapExec, and native WMI commands for stealthy post-exploitation during red team engagements.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fservices\u002Fwmi\u002Fexec\u002Fexploit\u002FSKILL.md",[],[118,92,119,95,120,121,122,109,123,45,124,125,126,127,97,128,129,130,131,132],"exploit","services wmi exec exploit","exec","remote","traffic","Bash","team","across","crackmapexec","native","command","lateral movement","read","lateral-movement","Impacket",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":52},"01M71HAG6MHKNQV8KDZKMT4886","registry-artifact-extract","Extract and analyze Windows Registry hives to uncover user activity, installed software, autostart entries, and evidence of system compromise.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fregistry\u002Fartifact\u002Fextract\u002FSKILL.md",[],[140,141,142,143,144,145,109,123,146,45,147,148,97,130,39,149,150,151,152,153],"artifact","registry","registry artifact extract","extract","evidence-collection","artifact-analysis","collection","analyze","uncover","activity","digital-forensics","windows-registry","regripper","sonnet",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":160,"publishedAt":52},"01M71HACR4A8XTWTTSXK4124AA","processes-token-impersonate-detect","Detect Windows token impersonation and privilege abuse including SeImpersonatePrivilege exploitation via Potato attacks and token stealing techniques.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fprocesses\u002Ftoken\u002Fimpersonate\u002Fdetect\u002FSKILL.md",[],[93,161,162,163,164,165,166,98,167,109,110,168,169,170,171,172,173,174,175,97],"processes token impersonate detect","token","processes","attacks","windows","escalation","techniques","privilege-escalation","seimpersonate","token-impersonation","printspoofer","exploitation","potato","impersonation","via",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":182,"publishedAt":52},"01M71HAABSB4Z6QFSXEG00R4RK","processes-thread-injection-detect","Detect Windows thread injection techniques including CreateRemoteThread, QueueUserAPC, NtCreateThreadEx, and thread hijacking via process memory analysis.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fprocesses\u002Fthread\u002Finjection\u002Fdetect\u002FSKILL.md",[],[183,184,93,185,163,165,186,98,187,167,109,110,45,188,189,190,191,175,97,99],"thread","processes thread injection detect","injection","memory","process-injection","api","apc-injection","thread-injection","nt-api",{"skillNo":193,"name":194,"nameZh":6,"description":195,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":196,"categories":197,"keywords":198,"publishedAt":52},"01M71HA7H311V5G14WMX58HQSS","processes-hollow-technique-detect","Detect process hollowing (RunPE) by identifying processes with mismatched image paths between PEB and VAD tree, or unmapped PE headers in memory.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fprocesses\u002Fhollow\u002Ftechnique\u002Fdetect\u002FSKILL.md",[],[199,93,163,200,186,98,201,202,109,110,203,204,205,206,207,208,97,99,209,210],"processes hollow technique detect","tree","memory-forensics","process-hollow","peb","runpe","image","pe-header","in memory","with","mismatched","headers"]