ワンクリックでManusで任意のスキルを実行

$pwd:

sbom-analyzer

Name: Sbom Analyzer
Author: snyk

// Software Bill of Materials (SBOM) security analysis for vulnerability assessment and third-party risk management. Validates SBOMs from vendors or generates SBOMs for internal projects. Use this skill when: - User asks to analyze an SBOM file - User mentions "third-party risk" or "vendor security" - User needs to validate a supplier's SBOM - User wants to check SBOM for vulnerabilities - User asks about CycloneDX or SPDX formats

Manusで実行

$ git log --oneline --stat

stars:40

forks:23

updated:2026年3月19日 15:41

ファイルエクスプローラー

2 ファイル

SKILL.md

readonly

related-skills.json

同じリポジトリ

snyk-fix.md

from "snyk/studio-recipes"

Complete security remediation workflow. Scans code for vulnerabilities using Snyk, fixes them, validates the fix, and optionally creates a PR. Supports both single-issue and batch mode for multiple vulnerabilities. Use this skill when: - User asks to fix security vulnerabilities - User mentions "snyk fix", "security fix", or "remediate vulnerabilities" - User wants to fix a specific CVE, Snyk ID, or vulnerability type (XSS, SQL injection, path traversal, etc.) - User wants to upgrade a vulnerable dependency - User asks to "fix all" vulnerabilities or "fix all high/critical" issues (batch mode)

2026-05-1540

ai-inventory.md

from "snyk/studio-recipes"

Generate and analyze AI Bill of Materials (AIBOM) for Python projects using AI/ML components. Identifies AI models, datasets, tools, and frameworks for security and compliance tracking. Use this skill when: - User asks to scan for AI components - User wants to know what AI models a project uses - User mentions "AI BOM", "AI inventory", or "ML security" - User is working with Python AI/ML projects (PyTorch, TensorFlow, HuggingFace) - User needs AI component compliance documentation

2026-03-1940

container-security.md

from "snyk/studio-recipes"

Comprehensive container image security scanning and remediation. Analyzes Docker images for OS package vulnerabilities, application dependencies, and Dockerfile best practices. Use when: - User asks to scan a Docker image or container - User mentions "container security" or "image vulnerabilities" - User wants to secure a Dockerfile - User asks about base image security - Agent is working with Docker, Kubernetes, or container deployments

2026-03-1940

drift-detector.md

from "snyk/studio-recipes"

Detect infrastructure drift between Terraform state and actual cloud resources. Identifies unmanaged resources, manual changes, and configuration drift. Use when: - User asks to check for infrastructure drift - User wants to find unmanaged cloud resources - User mentions "drift detection" or "Terraform drift" - User asks to compare cloud state to IaC - User wants to audit infrastructure changes

2026-03-1940

iac-security.md

from "snyk/studio-recipes"

Infrastructure as Code security scanning for Terraform, Kubernetes, CloudFormation, and Azure ARM. Detects misconfigurations, security risks, and compliance violations before deployment. Use when: - User asks to scan Terraform files or modules - User mentions "infrastructure security" or "IaC scan" - User is working with Kubernetes manifests - User asks about CloudFormation or ARM template security - Agent is generating or modifying infrastructure code

2026-03-1940

secure-at-inception.md

from "snyk/studio-recipes"

Proactive security scanning for newly generated or modified code. Intelligently detects changes, runs appropriate scans (SAST, SCA, IaC), filters to only NEW issues, and prevents vulnerabilities at the source. Use this skill when: - Agent generates new code files - Agent modifies existing code - User asks to "scan for security issues" or "check my changes" - Before committing changes - User mentions "secure at inception", "proactive scan", or "security check"

2026-03-1940

package.json

"author": "snyk"

"repository": "snyk/studio-recipes"

GitHub リポジトリを開く Creator のリポジトリを見る

$ install --global

$ download --local

Manusで実行

$ useful --forSOC

情報セキュリティアナリストコンピュータ・数学職15-1212L4

name	sbom-analyzer
description	Software Bill of Materials (SBOM) security analysis for vulnerability assessment and third-party risk management. Validates SBOMs from vendors or generates SBOMs for internal projects. Use this skill when: - User asks to analyze an SBOM file - User mentions "third-party risk" or "vendor security" - User needs to validate a supplier's SBOM - User wants to check SBOM for vulnerabilities - User asks about CycloneDX or SPDX formats
allowed-tools	mcp_snyk_snyk_sbom_scan Read Write Bash Grep
license	Apache-2.0
compatibility	Requires Snyk MCP server connection and authenticated Snyk account. SBOM must be in CycloneDX (1.4-1.6) or SPDX (2.3) JSON format. Components must include Package URLs (purls) for vulnerability identification.
metadata	{"author":"Snyk","version":"1.0.0"}

SBOM Security Analyzer

Analyze Software Bill of Materials to identify vulnerabilities in declared components for third-party risk management and compliance workflows.

Core Principle: Know what's in your software supply chain.

Quick Start

1. Receive or locate SBOM file (CycloneDX or SPDX)
2. Validate SBOM format and completeness
3. Run mcp_snyk_snyk_sbom_scan for vulnerability analysis
4. Generate risk report with prioritized findings
5. Provide remediation guidance

Supported SBOM Formats

Format	Versions	File Extension
CycloneDX	1.4, 1.5, 1.6	`.json`
SPDX	2.3	`.json`

Note: mcp_snyk_snyk_sbom_scan requires Package URLs (purls) in the SBOM for component identification.

Phase 1: SBOM Validation

Goal: Ensure the SBOM is valid and complete before analysis.

Step 1.1: Identify SBOM Format

Check the file structure:

CycloneDX Indicators:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "components": [...]
}

SPDX Indicators:

{
  "spdxVersion": "SPDX-2.3",
  "SPDXID": "SPDXRef-DOCUMENT",
  "packages": [...]
}

Step 1.2: Validate Completeness

Check for required elements:

Element	CycloneDX	SPDX	Required
Format version	`specVersion`	`spdxVersion`	Yes
Component list	`components`	`packages`	Yes
Package URLs	`purl` in components	`externalRefs`	Yes*
Licenses	`licenses`	`licenseConcluded`	Recommended
Checksums	`hashes`	`checksums`	Recommended

* Package URLs are required for Snyk to identify vulnerabilities.

Step 1.3: Report Validation Issues

If SBOM is incomplete, produce a report in this format:

## SBOM Validation Results

**File**: supplier-sbom.json
**Format**: CycloneDX 1.5

### Issues Found
| Issue | Severity | Count |
|-------|----------|-------|
| Missing purl | Error | 15 components |
| Missing license | Warning | 8 components |
| Missing checksum | Info | 23 components |

### Components Without purl (Cannot Scan)
- component-a (no package URL)
- component-b (no package URL)

**Recommendation**: Request updated SBOM from supplier with package URLs.

Phase 2: Security Scan

Goal: Identify vulnerabilities in SBOM components.

Step 2.1: Run SBOM Scan

Call the tool directly:

mcp_snyk_snyk_sbom_scan(file="path/to/sbom.json", severity_threshold="medium")

Step 2.2: Organization-Scoped Scan

To apply org-specific policies:

mcp_snyk_snyk_sbom_scan(file="path/to/sbom.json", org="<org-id>", severity_threshold="high")

Phase 3: Risk Analysis

Goal: Generate a comprehensive risk report from scan results.

Produce a single consolidated report covering summary, critical findings, and an overall risk score:

## SBOM Security Analysis

### Overview
| Metric | Value |
|--------|-------|
| Total Components | 156 |
| Components Scanned | 141 |
| Components Skipped | 15 (missing purl) |
| Vulnerable Components | 23 |
| Total Vulnerabilities | 47 |

### Severity Breakdown
| Severity | Count |
|----------|-------|
| Critical | 3 |
| High | 12 |
| Medium | 18 |
| Low | 14 |

### Critical Vulnerabilities
| Component | Version | CVE | CVSS | Exploited |
|-----------|---------|-----|------|-----------|
| log4j-core | 2.14.1 | CVE-2021-44228 | 10.0 | Yes |
| spring-core | 5.3.17 | CVE-2022-22965 | 9.8 | Yes |
| jackson-databind | 2.9.10 | CVE-2020-36518 | 9.8 | No |

### Risk Score: 78/100 (High Risk)
- ⚠️ 2 vulnerabilities with known exploits
- ⚠️ 3 critical severity issues
- ✓ Components from untrusted sources: 0

**Recommendation**: Do not integrate this software until critical vulnerabilities are addressed.

Phase 4: Remediation Guidance

Goal: Provide actionable upgrade recommendations and vendor communication.

Step 4.1: Upgrade Recommendations

## Recommended Actions

### Priority 1: Critical (Must Fix)
| Component | Current | Fixed Version | Notes |
|-----------|---------|---------------|-------|
| log4j-core | 2.14.1 | 2.17.1+ | Log4Shell |
| spring-core | 5.3.17 | 5.3.18+ | Spring4Shell |

### Priority 2: High (Should Fix)
| Component | Current | Fixed Version | Notes |
|-----------|---------|---------------|-------|
| lodash | 4.17.15 | 4.17.21 | Prototype pollution |
| axios | 0.21.1 | 1.6.0+ | SSRF vulnerability |

### Priority 3: Medium (Plan to Fix)
| Component | Current | Fixed Version | Notes |
|-----------|---------|---------------|-------|
| minimist | 1.2.5 | 1.2.8+ | Prototype pollution |

Step 4.2: Vendor Communication

Draft a message to the vendor using this template (populate with actual findings):

Subject: Security Vulnerabilities in Software SBOM

Dear [Vendor],

During our security review of [Product Name], we identified the following
vulnerabilities in the provided SBOM:

**Critical Issues (Require Immediate Action)**:
1. [Component] [Version] - [CVE] ([Name])
2. [Component] [Version] - [CVE] ([Name])

**Request**:
1. Provide updated software with patched versions
2. Provide updated SBOM reflecting the changes
3. Confirm expected remediation timeline

We require resolution of critical issues before proceeding with integration.

Regards,
[Your Name]

SBOM Generation (Internal Projects)

To generate an SBOM for your own project using the Snyk CLI, then scan it:

# Generate CycloneDX SBOM
snyk sbom --format=cyclonedx1.5+json > sbom.json

# Generate SPDX SBOM
snyk sbom --format=spdx2.3+json > sbom.json

Then scan the generated SBOM:

mcp_snyk_snyk_sbom_scan(file="sbom.json")

Error Handling

Invalid SBOM Format

Error: Unable to parse SBOM file

Solutions:
1. Verify file is valid JSON
2. Check SBOM format (CycloneDX/SPDX)
3. Validate against schema
4. Request corrected SBOM from source

Missing Package URLs

Warning: X components missing purl - cannot scan

Solutions:
1. Request updated SBOM with purls
2. Manually add purls if components are known
3. Document risk of unscanned components

Unsupported Version

Error: SBOM version not supported

Supported versions:
- CycloneDX: 1.4, 1.5, 1.6
- SPDX: 2.3

Convert SBOM to supported version if possible.

Constraints

Requires purls: Components without package URLs cannot be scanned
JSON only: XML format not currently supported
Version limits: Only specific CycloneDX/SPDX versions supported
Network required: Vulnerability database lookup needs connectivity
Point-in-time: SBOM reflects a specific version — rescan on updates

sbom-analyzer

このリポジトリの他の Skills

このリポジトリの他の Skills

SBOM Security Analyzer

Quick Start

Supported SBOM Formats

Phase 1: SBOM Validation

Step 1.1: Identify SBOM Format

Step 1.2: Validate Completeness

Step 1.3: Report Validation Issues

Phase 2: Security Scan

Step 2.1: Run SBOM Scan

Step 2.2: Organization-Scoped Scan

Phase 3: Risk Analysis

Phase 4: Remediation Guidance

Step 4.1: Upgrade Recommendations

Step 4.2: Vendor Communication

SBOM Generation (Internal Projects)

Error Handling

Invalid SBOM Format

Missing Package URLs

Unsupported Version

Constraints

SBOM Security Analyzer

Quick Start

Supported SBOM Formats

Phase 1: SBOM Validation

Step 1.1: Identify SBOM Format

Step 1.2: Validate Completeness

Step 1.3: Report Validation Issues

Phase 2: Security Scan

Step 2.1: Run SBOM Scan

Step 2.2: Organization-Scoped Scan

Phase 3: Risk Analysis

Phase 4: Remediation Guidance

Step 4.1: Upgrade Recommendations

Step 4.2: Vendor Communication

SBOM Generation (Internal Projects)

Error Handling

Invalid SBOM Format

Missing Package URLs

Unsupported Version

Constraints