[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AFH62H37MSN353Q4TXPR24":3,"skill-same:01M6AFH62H37MSN353Q4TXPR24":114},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":67,"commitSha":68,"skillDirectory":69,"forksCount":70,"repositoryHtmlUrl":71,"repositoryHomepageUrl":72,"ownerHtmlUrl":73,"ownerBlogUrl":74,"ownerDescription":75,"updatedAt":76,"install":77,"resources":90},"01M6AFH62H37MSN353Q4TXPR24","managing-third-party-vendor-risk",null,"Build and run a third-party\u002Fvendor risk management (TPRM) program aligned to NIST SP 800-161 C-SCRM: inventory and tier vendors, issue SIG\u002FCAIQ questionnaires, review SOC 2\u002FISO 27001 evidence, set contractual right-to-audit clauses, monitor vendors continuously, and offboard securely. Use when assessing a new vendor, standing up a vendor-risk program, tiering a portfolio, reviewing a SOC 2\u002FCAIQ, or writing security terms into a contract.","mukul975\u002FAnthropic-Cybersecurity-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADJPMYWG1E5GM1FWBE3128",35925,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fmanaging-third-party-vendor-risk\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"managing third party vendor risk","risk","t1195","caiq","soc2","nist-800-161","c-scrm","supply-chain-risk","tprm","vendor-risk-management","third-party-risk","writing","continuous-monitoring","t1078","SET","risk-management","soc","monitoring","cybersecurity","review","2026-11-10 10:12:30",false,"---\nname: managing-third-party-vendor-risk\ndescription: >-\n  Build and run a third-party\u002Fvendor risk management (TPRM) program aligned to NIST SP\n  800-161 C-SCRM: inventory and tier vendors, issue SIG\u002FCAIQ questionnaires, review\n  SOC 2\u002FISO 27001 evidence, set contractual right-to-audit clauses, monitor vendors\n  continuously, and offboard securely. Use when assessing a new vendor, standing up a\n  vendor-risk program, tiering a portfolio, reviewing a SOC 2\u002FCAIQ, or writing security\n  terms into a contract.\ndomain: cybersecurity\nsubdomain: compliance-governance\ntags:\n- third-party-risk\n- vendor-risk-management\n- tprm\n- supply-chain-risk\n- c-scrm\n- nist-800-161\n- soc2\n- caiq\n- continuous-monitoring\n- governance\nversion: \"1.0\"\nauthor: andrewibrah\nlicense: Apache-2.0\nnist_csf:\n- GV.SC-01\n- GV.SC-04\n- GV.SC-06\n- GV.SC-07\n- ID.RA-05\n- GV.OC-03\nmitre_attack:\n- T1199\n- T1195\n- T1078\n- T1190\n- T1567\n---\n\n# Managing Third-Party Vendor Risk\n\n## When to Use\n\n- When assessing a **new vendor** before onboarding, especially one that will handle sensitive data, connect to your network, or be embedded in a critical process.\n- When **standing up or maturing** a third-party risk management (TPRM) program and you need a repeatable tiering + assessment workflow.\n- When **tiering an existing vendor portfolio** so effort matches risk.\n- When **reviewing vendor evidence** — a SOC 2 Type II report, ISO 27001 certificate, CAIQ, or pen-test summary — and you need to know what to look for.\n- When writing **security and privacy requirements into a contract \u002F DPA**, including breach-notification SLAs and right-to-audit.\n- When a vendor (or their subcontractor) suffers a **breach** and you must assess exposure.\n- When managing **software supply-chain** and **Nth-party** (fourth-party and beyond) risk.\n\n## Prerequisites\n\n- A **vendor inventory** (who you use, for what, and what data\u002Faccess each has).\n- A defined **risk-tiering model** (criteria and thresholds) agreed with the business.\n- Access to standardized **questionnaires** (Shared Assessments **SIG**, CSA **CAIQ**) and a way to collect evidence.\n- Clarity on your own **regulatory obligations** that flow down to vendors (e.g., HIPAA BAAs, CMMC flowdown, GDPR processor terms, PCI).\n- Stakeholders identified: procurement, legal, security, data owner, and the business sponsor.\n\n## Workflow\n\n### 1. Inventory and classify vendors\nCatalog every third party and capture: data sensitivity handled, type of access (network, physical, none), business criticality, and regulatory scope. You cannot manage what you have not inventoried — shadow vendors are a common blind spot.\n\n### 2. Tier by inherent risk\nScore each vendor on inherent-risk factors (data sensitivity, access, criticality, regulatory scope, spend\u002Fconcentration) and assign a **tier** (e.g., Critical \u002F High \u002F Moderate \u002F Low). The tier drives **how deep** the assessment goes and **how often** you reassess. A payroll processor with PII and system access is not the same risk as a stock-photo subscription.\n\n### 3. Run tier-appropriate due diligence\n- **Critical\u002FHigh:** full **SIG** (or SIG Core), request **SOC 2 Type II** and\u002For **ISO 27001**, recent **pen-test** summary, and evidence of an incident-response capability. Consider an assessor call.\n- **Moderate:** **SIG Lite** or **CAIQ**, plus key attestations.\n- **Low:** lightweight questionnaire \u002F self-attestation.\n\n### 4. Review evidence critically\nDon't just collect — **read**:\n- **SOC 2 Type II:** check scope, the Trust Services Criteria covered, the audit **period** (not just the date), and especially the **exceptions\u002Fdeviations** and any qualified opinion. A clean cover page can hide noted exceptions.\n- **ISO 27001:** confirm the **scope statement** and the Statement of Applicability actually cover the service you're buying.\n- **CAIQ:** look for \"no\" answers and CCM domains left blank.\n- **Pen-test:** age, scope, and whether highs\u002Fcriticals were remediated.\n\n### 5. Identify gaps and decide\nCompare findings against your control requirements. For each gap: accept, require remediation (with a date), add a compensating control on your side, or walk away. Record the **residual risk** and a risk-owner decision.\n\n### 6. Codify in the contract \u002F DPA\nBake requirements into the agreement: security control obligations, **breach-notification timeline**, data-handling and return\u002Fdestruction terms, **right-to-audit \u002F right to assessment evidence**, subcontractor (Nth-party) flowdown, and liability\u002Finsurance. Contracts are where TPRM gets teeth.\n\n### 7. Monitor continuously\nTiering is not a one-time gate. For higher tiers: periodic reassessment, **security-ratings** feeds, breach\u002Fnews monitoring, certificate-expiry tracking, and watching for material changes (acquisition, region change, new subprocessors). Re-tier on change.\n\n### 8. Manage Nth-party and concentration risk\nMap critical **fourth parties** (your vendor's key subprocessors) and watch for **concentration** (many vendors riding on the same upstream provider) — a single upstream outage or breach can hit your whole portfolio at once.\n\n### 9. Offboard securely\nOn termination: revoke access and credentials, confirm **data return or certified destruction**, remove integrations\u002FAPI keys, and update the inventory. Un-offboarded vendors are standing risk.\n\n## Key Concepts\n\n| Concept | Definition |\n|---|---|\n| Inherent risk | Risk a vendor poses before controls — drives tiering. |\n| Residual risk | Risk remaining after the vendor's (and your) controls. |\n| Vendor tier | Risk band (Critical\u002FHigh\u002FModerate\u002FLow) setting assessment depth and cadence. |\n| SIG | Shared Assessments Standardized Information Gathering questionnaire (full \u002F Lite \u002F Core). |\n| CAIQ | CSA Consensus Assessments Initiative Questionnaire (maps to the Cloud Controls Matrix). |\n| SOC 2 Type II | Attestation on control design **and** operating effectiveness over a period. |\n| Right to audit | Contractual right to assess the vendor or obtain assessment evidence. |\n| Nth-party \u002F fourth-party | Your vendor's vendors (and beyond) — indirect supply-chain risk. |\n| Concentration risk | Many vendors depending on the same upstream provider. |\n| C-SCRM | Cybersecurity Supply Chain Risk Management (NIST SP 800-161). |\n\n## Tools & Systems\n\n- **NIST SP 800-161 Rev 1** — Cybersecurity Supply Chain Risk Management practices.\n- **NIST CSF 2.0 — GV.SC** — the supply-chain risk-management category (program backbone).\n- **Shared Assessments SIG** and **CSA CAIQ \u002F STAR registry** — standardized questionnaires.\n- **SOC 2 \u002F ISO 27001 \u002F PCI AOC \u002F pen-test reports** — vendor evidence.\n- **Security-ratings services** (e.g., BitSight\u002FSecurityScorecard-style) — continuous external signal.\n- **TPRM platforms** — OneTrust, ProcessUnity, Prevalent, ServiceNow VRM, etc., to manage the workflow and inventory.\n- **GDPR DPA \u002F HIPAA BAA \u002F CMMC flowdown** — regulatory contract instruments.\n\n## Common Scenarios\n\n- **New SaaS onboarding.** Tier it, send the right questionnaire, read the SOC 2 exceptions, set contract terms, then approve with documented residual risk.\n- **Portfolio has 400 vendors, no tiers.** Tier first; concentrate assessment effort on the Critical\u002FHigh tail rather than spreading thin.\n- **Vendor breach in the news.** Pull the vendor record, assess data\u002Faccess exposure, invoke the breach-notification clause, and require a post-incident report.\n- **Auditor asks for your TPRM program.** Show the tiering model, the assessment cadence, and evidence of continuous monitoring mapped to GV.SC.\n- **Critical fourth party identified.** Document the dependency and the concentration risk; build a contingency for that upstream provider.\n\n## Output Format\n\nProduce a **Vendor Risk Assessment** using `assets\u002Ftemplate.md`, containing:\n\n1. **Vendor profile** — service, data handled, access type, business criticality, regulatory scope.\n2. **Inherent-risk tier** — score and resulting tier, with rationale.\n3. **Due-diligence performed** — questionnaire used and evidence collected (SOC 2 period, ISO scope, pen-test age).\n4. **Findings** — gaps with severity, including notable SOC 2 exceptions.\n5. **Decision & residual risk** — approve\u002Fconditional\u002Freject, with risk-owner sign-off.\n6. **Contractual requirements** — security terms, breach SLA, right-to-audit, subprocessor flowdown.\n7. **Monitoring & reassessment plan** — cadence, signals watched, re-tier triggers.\n8. **Nth-party notes** — critical subprocessors and concentration risk.\n\nUse `scripts\u002Fprocess.py` to compute a vendor's inherent-risk tier from a profile JSON, set the assessment depth and reassessment cadence, and flag missing evidence for the assigned tier.\n","# Managing Third-Party Vendor Risk\n\n## When to Use\n\n- When assessing a **new vendor** before onboarding, especially one that will handle sensitive data, connect to your network, or be embedded in a critical process.\n- When **standing up or maturing** a third-party risk management (TPRM) program and you need a repeatable tiering + assessment workflow.\n- When **tiering an existing vendor portfolio** so effort matches risk.\n- When **reviewing vendor evidence** — a SOC 2 Type II report, ISO 27001 certificate, CAIQ, or pen-test summary — and you need to know what to look for.\n- When writing **security and privacy requirements into a contract \u002F DPA**, including breach-notification SLAs and right-to-audit.\n- When a vendor (or their subcontractor) suffers a **breach** and you must assess exposure.\n- When managing **software supply-chain** and **Nth-party** (fourth-party and beyond) risk.\n\n## Prerequisites\n\n- A **vendor inventory** (who you use, for what, and what data\u002Faccess each has).\n- A defined **risk-tiering model** (criteria and thresholds) agreed with the business.\n- Access to standardized **questionnaires** (Shared Assessments **SIG**, CSA **CAIQ**) and a way to collect evidence.\n- Clarity on your own **regulatory obligations** that flow down to vendors (e.g., HIPAA BAAs, CMMC flowdown, GDPR processor terms, PCI).\n- Stakeholders identified: procurement, legal, security, data owner, and the business sponsor.\n\n## Workflow\n\n### 1. Inventory and classify vendors\nCatalog every third party and capture: data sensitivity handled, type of access (network, physical, none), business criticality, and regulatory scope. You cannot manage what you have not inventoried — shadow vendors are a common blind spot.\n\n### 2. Tier by inherent risk\nScore each vendor on inherent-risk factors (data sensitivity, access, criticality, regulatory scope, spend\u002Fconcentration) and assign a **tier** (e.g., Critical \u002F High \u002F Moderate \u002F Low). The tier drives **how deep** the assessment goes and **how often** you reassess. A payroll processor with PII and system access is not the same risk as a stock-photo subscription.\n\n### 3. Run tier-appropriate due diligence\n- **Critical\u002FHigh:** full **SIG** (or SIG Core), request **SOC 2 Type II** and\u002For **ISO 27001**, recent **pen-test** summary, and evidence of an incident-response capability. Consider an assessor call.\n- **Moderate:** **SIG Lite** or **CAIQ**, plus key attestations.\n- **Low:** lightweight questionnaire \u002F self-attestation.\n\n### 4. Review evidence critically\nDon't just collect — **read**:\n- **SOC 2 Type II:** check scope, the Trust Services Criteria covered, the audit **period** (not just the date), and especially the **exceptions\u002Fdeviations** and any qualified opinion. A clean cover page can hide noted exceptions.\n- **ISO 27001:** confirm the **scope statement** and the Statement of Applicability actually cover the service you're buying.\n- **CAIQ:** look for \"no\" answers and CCM domains left blank.\n- **Pen-test:** age, scope, and whether highs\u002Fcriticals were remediated.\n\n### 5. Identify gaps and decide\nCompare findings against your control requirements. For each gap: accept, require remediation (with a date), add a compensating control on your side, or walk away. Record the **residual risk** and a risk-owner decision.\n\n### 6. Codify in the contract \u002F DPA\nBake requirements into the agreement: security control obligations, **breach-notification timeline**, data-handling and return\u002Fdestruction terms, **right-to-audit \u002F right to assessment evidence**, subcontractor (Nth-party) flowdown, and liability\u002Finsurance. Contracts are where TPRM gets teeth.\n\n### 7. Monitor continuously\nTiering is not a one-time gate. For higher tiers: periodic reassessment, **security-ratings** feeds, breach\u002Fnews monitoring, certificate-expiry tracking, and watching for material changes (acquisition, region change, new subprocessors). Re-tier on change.\n\n### 8. Manage Nth-party and concentration risk\nMap critical **fourth parties** (your vendor's key subprocessors) and watch for **concentration** (many vendors riding on the same upstream provider) — a single upstream outage or breach can hit your whole portfolio at once.\n\n### 9. Offboard securely\nOn termination: revoke access and credentials, confirm **data return or certified destruction**, remove integrations\u002FAPI keys, and update the inventory. Un-offboarded vendors are standing risk.\n\n## Key Concepts\n\n| Concept | Definition |\n|---|---|\n| Inherent risk | Risk a vendor poses before controls — drives tiering. |\n| Residual risk | Risk remaining after the vendor's (and your) controls. |\n| Vendor tier | Risk band (Critical\u002FHigh\u002FModerate\u002FLow) setting assessment depth and cadence. |\n| SIG | Shared Assessments Standardized Information Gathering questionnaire (full \u002F Lite \u002F Core). |\n| CAIQ | CSA Consensus Assessments Initiative Questionnaire (maps to the Cloud Controls Matrix). |\n| SOC 2 Type II | Attestation on control design **and** operating effectiveness over a period. |\n| Right to audit | Contractual right to assess the vendor or obtain assessment evidence. |\n| Nth-party \u002F fourth-party | Your vendor's vendors (and beyond) — indirect supply-chain risk. |\n| Concentration risk | Many vendors depending on the same upstream provider. |\n| C-SCRM | Cybersecurity Supply Chain Risk Management (NIST SP 800-161). |\n\n## Tools & Systems\n\n- **NIST SP 800-161 Rev 1** — Cybersecurity Supply Chain Risk Management practices.\n- **NIST CSF 2.0 — GV.SC** — the supply-chain risk-management category (program backbone).\n- **Shared Assessments SIG** and **CSA CAIQ \u002F STAR registry** — standardized questionnaires.\n- **SOC 2 \u002F ISO 27001 \u002F PCI AOC \u002F pen-test reports** — vendor evidence.\n- **Security-ratings services** (e.g., BitSight\u002FSecurityScorecard-style) — continuous external signal.\n- **TPRM platforms** — OneTrust, ProcessUnity, Prevalent, ServiceNow VRM, etc., to manage the workflow and inventory.\n- **GDPR DPA \u002F HIPAA BAA \u002F CMMC flowdown** — regulatory contract instruments.\n\n## Common Scenarios\n\n- **New SaaS onboarding.** Tier it, send the right questionnaire, read the SOC 2 exceptions, set contract terms, then approve with documented residual risk.\n- **Portfolio has 400 vendors, no tiers.** Tier first; concentrate assessment effort on the Critical\u002FHigh tail rather than spreading thin.\n- **Vendor breach in the news.** Pull the vendor record, assess data\u002Faccess exposure, invoke the breach-notification clause, and require a post-incident report.\n- **Auditor asks for your TPRM program.** Show the tiering model, the assessment cadence, and evidence of continuous monitoring mapped to GV.SC.\n- **Critical fourth party identified.** Document the dependency and the concentration risk; build a contingency for that upstream provider.\n\n## Output Format\n\nProduce a **Vendor Risk Assessment** using `assets\u002Ftemplate.md`, containing:\n\n1. **Vendor profile** — service, data handled, access type, business criticality, regulatory scope.\n2. **Inherent-risk tier** — score and resulting tier, with rationale.\n3. **Due-diligence performed** — questionnaire used and evidence collected (SOC 2 period, ISO scope, pen-test age).\n4. **Findings** — gaps with severity, including notable SOC 2 exceptions.\n5. **Decision & residual risk** — approve\u002Fconditional\u002Freject, with risk-owner sign-off.\n6. **Contractual requirements** — security terms, breach SLA, right-to-audit, subprocessor flowdown.\n7. **Monitoring & reassessment plan** — cadence, signals watched, re-tier triggers.\n8. **Nth-party notes** — critical subprocessors and concentration risk.\n\nUse `scripts\u002Fprocess.py` to compute a vendor's inherent-risk tier from a profile JSON, set the assessment depth and reassessment cadence, and flag missing evidence for the assigned tier.\n",{"name":5,"tags":49,"author":51,"domain":42,"license":15,"version":52,"nist_csf":53,"subdomain":60,"description":7,"mitre_attack":61},[34,33,32,31,30,29,28,27,36,50],"governance","andrewibrah","1.0",[54,55,56,57,58,59],"GV.SC-01","GV.SC-04","GV.SC-06","GV.SC-07","ID.RA-05","GV.OC-03","compliance-governance",[62,63,64,65,66],"T1199","T1195","T1078","T1190","T1567","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Fmanaging-third-party-vendor-risk",4384,"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":78,"prompt":88,"zipAvailable":89},[79,82,85],{"tool":80,"command":81},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill managing-third-party-vendor-risk",{"tool":83,"command":84},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill managing-third-party-vendor-risk",{"tool":86,"command":87},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill managing-third-party-vendor-risk","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fmanaging-third-party-vendor-risk\u002FSKILL.md",true,[91,97,102,108],{"path":92,"resourceType":93,"resourceTypeDesc":94,"sizeBytes":95,"sourceHtmlUrl":96},"assets\u002Ftemplate.md","ASSET","资产文件",3136,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fmanaging-third-party-vendor-risk\u002Fassets\u002Ftemplate.md",{"path":98,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":100,"sourceHtmlUrl":101},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fmanaging-third-party-vendor-risk\u002FLICENSE",{"path":103,"resourceType":104,"resourceTypeDesc":105,"sizeBytes":106,"sourceHtmlUrl":107},"references\u002Fstandards.md","REFERENCE","参考文档",4424,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fmanaging-third-party-vendor-risk\u002Freferences\u002Fstandards.md",{"path":109,"resourceType":110,"resourceTypeDesc":111,"sizeBytes":112,"sourceHtmlUrl":113},"scripts\u002Fprocess.py","SCRIPT","脚本",8656,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fmanaging-third-party-vendor-risk\u002Fscripts\u002Fprocess.py",[115,145,169,196,221,246],{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":126,"publishedAt":44},"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",[121],{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[127,128,129,130,131,42,132,133,134,135,136,137,138,139,140,26,141,142,143,144],"sigstore","provenance","slsa","verifying build provenance with slsa sigstore","security","incident response","identity","pr","code","artifacts","ci","supply-chain","pipeline","supply-chain-security","attestation","code-signing","cosign","keyless",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":152,"publishedAt":44},"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",[151],{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},[153,141,154,155,131,156,42,134,157,158,159,160,161,162,163,164,165,166,167,168],"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":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":179,"publishedAt":44},"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",[175,178],{"categoryNo":176,"categoryName":177,"taxonomyType":124,"taxonomyTypeDesc":125},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},[163,180,181,182,183,42,184,185,157,186,187,188,189,190,191,37,192,193,194,195],"backup","recovery","validating backup integrity for recovery","testing","infrastructure","validation","compliance","hash-verification","incident-response","ransomware","cryptocurrency","detection","t1490","immutable","disaster-recovery","restore-testing",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":200,"categories":201,"keywords":203,"publishedAt":44},"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",[202],{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},[204,205,206,42,207,208,209,210,211,212,213,214,215,216,217,38,160,218,219,220],"windows","kape","triaging windows with kape","registry","browser","logs","windows-forensics","dfir","mft","mftecmd","data","prefetch","eric-zimmerman","digital-forensics","collection","pecmd","artifact-collection",{"skillNo":222,"name":223,"nameZh":6,"description":224,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":225,"categories":226,"keywords":228,"publishedAt":44},"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",[227],{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},[229,230,231,42,232,233,234,235,39,236,237,238,239,240,25,241,242,243,244,245],"vulnerabilities","framework","triaging vulnerabilities with ssvc framework","status","planning","CISA","vulnerability-management","nessus","qualys","openvas","cvss","remediation","vulnerability","api","prioritization","ssvc","decision-tree",{"skillNo":247,"name":248,"nameZh":6,"description":249,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":250,"categories":251,"keywords":253,"publishedAt":44},"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",[252],{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},[131,254,42,255,256,257,40,258,259,260,261,37,262,192,263,264,265,266,267,268],"triaging security incident","siem","file","ioc","NIST-800-61","NIST","severity","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]