[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AG17D1PHD061D323SGT2KD":3,"skill-same:01M6AG17D1PHD061D323SGT2KD":133},{"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":74,"commitSha":75,"skillDirectory":76,"forksCount":77,"repositoryHtmlUrl":78,"repositoryHomepageUrl":79,"ownerHtmlUrl":80,"ownerBlogUrl":81,"ownerDescription":82,"updatedAt":83,"install":84,"resources":97},"01M6AG17D1PHD061D323SGT2KD","performing-sca-dependency-scanning-with-snyk",null,"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.","mukul975\u002FAnthropic-Cybersecurity-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADJPMYWG1E5GM1FWBE3128",35990,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fperforming-sca-dependency-scanning-with-snyk\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],"performing sca dependency scanning with snyk","SCA","dependency scanning","ci","Composition","analysis","applications","t1195","t1059","dependency-scanning","devsecops","monitoring","license compliance","package","license","pull","gitlab","pr","secure","cybersecurity","2026-11-10 10:12:30",false,"---\nname: performing-sca-dependency-scanning-with-snyk\ndescription: 'This skill covers implementing Software Composition Analysis (SCA) using\n  Snyk to detect vulnerable open-source dependencies in CI\u002FCD pipelines. It addresses\n  scanning package manifests and lockfiles, automated fix pull request generation,\n  license compliance checking, continuous monitoring of deployed applications, and\n  integration with GitHub, GitLab, and Jenkins pipelines.\n\n  '\ndomain: cybersecurity\nsubdomain: devsecops\ntags:\n- devsecops\n- cicd\n- sca\n- snyk\n- dependency-scanning\n- secure-sdlc\nversion: 1.0.0\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- PR.PS-01\n- GV.SC-07\n- ID.IM-04\n- PR.PS-04\nmitre_attack:\n- T1195\n- T1554\n- T1059.004\n---\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\nversion: v1.25.0\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","# 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\nversion: v1.25.0\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",{"name":5,"tags":57,"author":62,"domain":51,"license":15,"version":63,"nist_csf":64,"subdomain":42,"description":69,"mitre_attack":70},[42,58,59,60,41,61],"cicd","sca","snyk","secure-sdlc","mahipal","1.0.0",[65,66,67,68],"PR.PS-01","GV.SC-07","ID.IM-04","PR.PS-04","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.\n",[71,72,73],"T1195","T1554","T1059.004","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Fperforming-sca-dependency-scanning-with-snyk",4395,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills","https:\u002F\u002Fmahipal.engineer\u002FAnthropic-Cybersecurity-Skills\u002F","https:\u002F\u002Fgithub.com\u002Fmukul975","Mahipal.engineer","🔐 Cybersecurity | 💻 Dev | 📷 Street Photographer\r\n🎓 MSc | 📚 Research & AI Security","2026-08-31 12:32:44",{"source":8,"skillName":5,"commands":85,"prompt":95,"zipAvailable":96},[86,89,92],{"tool":87,"command":88},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill performing-sca-dependency-scanning-with-snyk",{"tool":90,"command":91},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill performing-sca-dependency-scanning-with-snyk",{"tool":93,"command":94},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill performing-sca-dependency-scanning-with-snyk","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fperforming-sca-dependency-scanning-with-snyk\u002FSKILL.md",true,[98,104,109,115,119,123,129],{"path":99,"resourceType":100,"resourceTypeDesc":101,"sizeBytes":102,"sourceHtmlUrl":103},"assets\u002Ftemplate.md","ASSET","资产文件",3041,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fperforming-sca-dependency-scanning-with-snyk\u002Fassets\u002Ftemplate.md",{"path":105,"resourceType":105,"resourceTypeDesc":106,"sizeBytes":107,"sourceHtmlUrl":108},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fperforming-sca-dependency-scanning-with-snyk\u002FLICENSE",{"path":110,"resourceType":111,"resourceTypeDesc":112,"sizeBytes":113,"sourceHtmlUrl":114},"references\u002Fapi-reference.md","REFERENCE","参考文档",2345,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fperforming-sca-dependency-scanning-with-snyk\u002Freferences\u002Fapi-reference.md",{"path":116,"resourceType":111,"resourceTypeDesc":112,"sizeBytes":117,"sourceHtmlUrl":118},"references\u002Fstandards.md",2724,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fperforming-sca-dependency-scanning-with-snyk\u002Freferences\u002Fstandards.md",{"path":120,"resourceType":111,"resourceTypeDesc":112,"sizeBytes":121,"sourceHtmlUrl":122},"references\u002Fworkflows.md",3893,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fperforming-sca-dependency-scanning-with-snyk\u002Freferences\u002Fworkflows.md",{"path":124,"resourceType":125,"resourceTypeDesc":126,"sizeBytes":127,"sourceHtmlUrl":128},"scripts\u002Fagent.py","SCRIPT","脚本",6455,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fperforming-sca-dependency-scanning-with-snyk\u002Fscripts\u002Fagent.py",{"path":130,"resourceType":125,"resourceTypeDesc":126,"sizeBytes":131,"sourceHtmlUrl":132},"scripts\u002Fprocess.py",9026,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fperforming-sca-dependency-scanning-with-snyk\u002Fscripts\u002Fprocess.py",[134,158,182,210,236,263],{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":141,"publishedAt":52},"01M6AGDM3HJXTKXX15ZZ0ZVCJ3","verifying-build-provenance-with-slsa-sigstore","Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI\u002FCD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fverifying-build-provenance-with-slsa-sigstore\u002FSKILL.md",[140],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[142,143,144,145,146,51,147,148,49,149,150,35,151,152,153,39,154,155,156,157],"sigstore","provenance","slsa","verifying build provenance with slsa sigstore","security","incident response","identity","code","artifacts","supply-chain","pipeline","supply-chain-security","attestation","code-signing","cosign","keyless",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":165,"publishedAt":52},"01M6AGDGBPWYVZ2F11GFKJ4HZ9","validating-tpm-measured-boot-attestation","Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote\u002Ftpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware\u002Fkernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-tpm-measured-boot-attestation\u002FSKILL.md",[164],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[166,154,167,168,146,169,51,49,170,171,172,173,174,175,176,177,178,179,180,181],"boot","TPM","validating tpm measured boot attestation","policy","verification","ZeRO","firmware","Tools","measured-boot","PCR","integrity","secrets","remote-attestation","tpm2-tools","integrity-verification","trusted-computing",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":192,"publishedAt":52},"01M6AGDCW0Y4FXZ3362GT1941M","validating-backup-integrity-for-recovery","Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable\u002Fair-gapped backups for silent corruption or tampering.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-backup-integrity-for-recovery\u002FSKILL.md",[188,191],{"categoryNo":189,"categoryName":190,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[176,193,194,195,196,51,197,198,170,199,200,201,202,203,204,205,206,207,208,209],"backup","recovery","validating backup integrity for recovery","testing","infrastructure","validation","compliance","hash-verification","incident-response","ransomware","cryptocurrency","detection","t1078","t1490","immutable","disaster-recovery","restore-testing",{"skillNo":211,"name":212,"nameZh":6,"description":213,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":214,"categories":215,"keywords":217,"publishedAt":52},"01M6AGD9GBG2KZ336AE763J3WH","triaging-windows-with-kape","Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment\u002Ftriage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-windows-with-kape\u002FSKILL.md",[216],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[218,219,220,51,221,222,223,224,225,226,227,228,229,230,231,232,173,233,234,235],"windows","kape","triaging windows with kape","registry","browser","logs","windows-forensics","dfir","mft","mftecmd","data","prefetch","eric-zimmerman","digital-forensics","SET","collection","pecmd","artifact-collection",{"skillNo":237,"name":238,"nameZh":6,"description":239,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":240,"categories":241,"keywords":243,"publishedAt":52},"01M6AGD5PW5J4EVZM958WD74ZQ","triaging-vulnerabilities-with-ssvc-framework","Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track\u002FTrack*\u002FAttend\u002FAct decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-vulnerabilities-with-ssvc-framework\u002FSKILL.md",[242],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[244,245,246,51,247,248,249,250,251,252,253,254,255,256,257,258,259,260,261,262],"vulnerabilities","framework","triaging vulnerabilities with ssvc framework","status","planning","CISA","vulnerability-management","risk-management","nessus","qualys","openvas","cvss","remediation","risk","vulnerability","api","prioritization","ssvc","decision-tree",{"skillNo":264,"name":265,"nameZh":6,"description":266,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":267,"categories":268,"keywords":270,"publishedAt":52},"01M6AGD24TTQQM4CXG69E3B9TJ","triaging-security-incident","Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM\u002FEDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-security-incident\u002FSKILL.md",[269],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[146,271,51,272,273,274,275,276,277,278,279,205,280,206,37,281,282,283,284,285],"triaging security incident","siem","file","ioc","soc","NIST-800-61","NIST","severity","edr","execution","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]