sap-dependency-security

# SAP Dependency Security

## Related Skills

- **sap-hana-cli**: For dependency-aware database tooling workflows and upgrade guidance
- **sap-cap-capire**: For CAP dependency-safe runtime and service configuration guidance
- **sap-fiori-tools**: For secure UI5/Fiori dependency strategy when tooling touches frontend packages
- **sapui5**: For SAPUI5/OpenUI5 frontend dependency and MCP tooling review
- **sap-datasphere**: For tenant-connected Datasphere MCP and CLI dependency review
- **sap-sac-scripting**: For source-pinned SAC MCP setup and local install records

Manage SAP dependency security and upgrades with supply chain protection, compatibility analysis, staged rollout, and comprehensive testing across all major package managers.

## When to Use This Skill

- Upgrading major framework or library versions
- Configuring supply chain attack prevention (cooldown, script blocking, lockfile hardening)
- Setting up secure package manager configuration
- Resolving dependency conflicts or peer dependency issues
- Planning incremental upgrade paths with testing
- Automating dependency updates with Renovate, Dependabot, or Snyk
- Auditing dependencies for vulnerabilities
- Setting up CI/CD dependency security workflows
- Pinning or reviewing SAP MCP servers in `.mcp.json`
- Reviewing SAP CAP, UI5/Fiori, HANA, Datasphere, SAC, SAP Cloud SDK, BTP/CF/mbt, or ABAP/gCTS dependency workflows

## Common Issues

| Issue | Recommended response |
|-------|----------------------|
| Floating MCP package or `@latest` in `.mcp.json` | Replace with an exact version or approved source commit and run `npm run validate:mcp-security`. |
| Lockfile changed unexpectedly | Review package manager config, block lifecycle scripts, and regenerate only after dependency intent is clear. |
| Dependency is too new for cooldown policy | Hold the upgrade unless a documented security exception justifies immediate adoption. |
| Tenant-connected tool changed source | Verify the source URL, commit, and build steps before using credentials. |

## Two Modes of Operation

**Interactive** — Walk through setup questions to generate tailored config. Use for fresh setup.

**Default** — Apply recommended defaults immediately: 7-day cooldown, block all scripts, frozen-lockfile, lockfile-lint, Dependabot with cooldown. Customization optional.

**SAP Development Mode** — Use a stricter SAP posture: 14-day cooldown, exact pins for MCP servers and executable tooling, no floating `@latest`, source commit pins for local MCP servers, and manual review for tenant-connected tools.

## SAP Development Mode

Use SAP Development Mode when dependency work touches SAP projects, SAP BTP deployment tooling, SAP SDKs, or any MCP server shipped by this repository.

Core rules:

1. **Default to 14-day cooldown** for SAP enterprise projects. Record explicit exceptions in the SAP MCP inventory or project review notes.
2. **Treat MCP servers as executable dependencies**. In `.mcp.json`, use exact npm pins such as `@ui5/mcp-server@0.2.11`, never `@latest` or bare package names.
3. **Pin local-source MCPs by commit**. SAC uses the trusted `secondsky/sap_analytics_cloud_mcp` fork and must record commit `2020235505d98111c2889598ab2217c1619b6943`.
4. **Keep runtime authorization separate**. This skill covers package/source/executable trust; use the relevant SAP skill for tenant role design and business authorization.
5. **Validate MCP drift** with `npm run validate:mcp-security` after any `.mcp.json` or SAP MCP inventory change.

Load `references/sap-dependency-risk-matrix.md` for SAP stack coverage and `references/sap-mcp-security.md` for MCP update workflow and SAC source-install policy. Use `references/sap-mcp-inventory.json` as the machine-readable approved MCP package/source list.

## Interactive Setup Flow

When the user wants tailored configuration, walk through these decisions. Skip this section entirely if using default mode.

### Tier 1: Required Decisions

Always ask these 3 questions before generating any config:

**1. Package Manager**

"Which package manager does this project use?"

| Answer | Generates |
|--------|-----------|
| npm | `.npmrc` |
| Bun | `bunfig.toml` |
| pnpm | `pnpm-workspace.yaml` |
| Yarn | `.yarnrc.yml` |
| Deno | `deno.json` config |

**2. Cooldown Period**

"How many days should newly published packages age before install? This prevents supply chain attacks where malicious packages are discovered and unpublished within days."

| Option | Days | Use Case |
|--------|------|----------|
| Aggressive | 3 | Catches most typosquatting |
| Recommended | 7 | Good balance for most projects |
| Conservative | 14 | Critical/production systems |
| Paranoid | 21 | Matches Snyk's built-in default |
| Custom | N | User specifies |

**3. Post-Install Script Policy**

"How should lifecycle scripts (postinstall, preinstall) be handled? These are the #1 attack vector for supply chain attacks."

| Option | Behavior |
|--------|----------|
| Block all (recommended) | `--ignore-scripts` + allow-git=none |
| Allowlist | Block by default, allow specific trusted packages |
| Review only | Warn but don't block |

### Tier 2: Security Tooling (Offer as Batch)

"Which of these security features would you like to configure? Select any that apply."

**4. CI/CD Automation Tool**

| Answer | Generates |
|--------|-----------|
| Dependabot | `.github/dependabot.yml` with cooldown |
| Renovate | `renovate.json` with minimumReleaseAge |
| Snyk | No config needed (21-day cooldown built-in) |
| None | Skip |

**5. Automerge Policy**

| Option | Behavior |
|--------|----------|
| None | All updates require manual review |
| Minor+Patch only | Auto-merge safe updates, review majors |
| All with approval | Auto-merge after team approval |

**6. Update Schedule**

| Option | Config Value |
|--------|-------------|
| Daily | `"daily"` |
| Weekly (default) | `"weekly"` |
| Biweekly | `"biweekly"` |
| Monthly | `"monthly"` |

**7. Install-Time Security Tooling**

"Whi