# Diet Assess Risk

> Deep-dive security risk analysis for a dependency flagged by uzomuzo diet

- Skill: `future-architect/diet-assess-risk` (Agent Skill)
- Install (CLI): `npx skillmds@latest add future-architect/diet-assess-risk`
- Raw SKILL.md: https://api.skillmd.com/api/skills/future-architect/diet-assess-risk/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: future-architect (https://skillmd.com/u/future-architect)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/future-architect/diet-assess-risk

---


# Diet Risk Assessment: $ARGUMENTS

Analyze the security risk of keeping a dependency identified by `uzomuzo diet`. This command performs deep data-flow analysis that diet's automated scoring cannot do.

**When to use**: After `uzomuzo diet` flags a dependency as EOL/Stalled/Archived with non-trivial source coupling. Trivial (0 imports) dependencies don't need this -- just remove them.

**Relationship to diet skills**:
- `uzomuzo diet` tells you **what** to remove and **how hard** (automated, broad)
- `/diet-assess-risk` tells you **how dangerous it is to keep** (LLM-powered, deep) -- **this skill**
- `/diet-evaluate-removal` tells you **whether removal is worth it** and **how to replace** (LLM-powered, per-dep)
- `/diet-remove` **executes the removal** (issue or PR)

Do NOT assess replacement options or removal feasibility here -- that is `/diet-evaluate-removal`'s job. This skill answers one question: **"If we keep this dependency unchanged for the next 12 months, what is the realistic security exposure?"**

## Phase 0: Input normalization

Determine input mode and normalize to a diet entry before analysis.

### Mode A: Diet JSON available

Extract the target dependency's entry from the diet JSON:

```bash
uzomuzo diet --sbom bom.json --source . --format json | jq '.dependencies[] | select(.name == "TARGET")'
```

Or read from a saved diet JSON file. All fields are available.

### Mode B: PURL only (no diet JSON)

Run `uzomuzo scan <purl>` to get health signals. Mark coupling fields (`import_file_count`, `call_site_count`, `api_breadth`, `symbols`, `import_files`) as "unavailable". Proceed with Phase 1 Steps 1-2 and Phase 3 only. Skip Phase 1 Steps 3-4 (no coupling data to filter) and Phase 2 (no source code). When classifying threat profile in Step 2, treat absent `import_file_count` as "assume > 0" (conservative — do not default to SUPPLY-CHAIN-ONLY). In the verdict, omit the "Security-relevant coupling" line and note "Source coupling data unavailable" in Limitations.

### Mode C: "top N"

Sort diet entries by `health_risk * (1 - coupling_effort)` descending (both fields are 0.0-1.0 normalized). This prioritizes dependencies that are both unhealthy and actionable — high health risk combined with lower coupling effort gives the best risk-reduction ROI. Run Phase 0-3 for each of the top N entries (N is user-specified, default 5), then produce the summary table.

### Early exits

- If `is_unused` is `true`: **Stop.** Report "Unused dependency -- no data flow risk. Remove it." No further analysis needed.
- If `lifecycle` is `Active` and `has_vulnerabilities` is `false`: **Stop.** Report "Maintained, no known vulnerabilities. No immediate risk." This skill is for unhealthy dependencies.

## Phase 1: Threat surface inventory

This phase uses **only diet JSON fields** -- no code reading. It classifies the threat surface and produces scoping decisions for Phase 2.

### Step 1: Record diet facts

Extract the full diet entry. These fields will appear verbatim in the verdict's "Diet Facts" section:

| Field | JSON key | Use |
|-------|----------|-----|
| Identity | `purl`, `name`, `version`, `ecosystem` | Package identification |
| Ranking | `rank`, `priority_score`, `overall_score` | Diet's automated ranking (`rank` is position among all deps) |
| Health | `health_risk`, `lifecycle`, `has_vulnerabilities`, `vulnerability_count`, `max_cvss_score` | Maintenance and vulnerability status |
| Graph | `graph_impact`, `exclusive_transitive`, `total_transitive` | Blast radius |
| Coupling | `coupling_effort`, `difficulty`, `import_file_count`, `call_site_count`, `api_breadth` | Integration depth |
| Coupling detail | `symbols`, `import_files` | Specific APIs used and files importing them (Phase 2 starting points) |
| Persistence | `stays_as_indirect`, `indirect_via` | Whether risk is eliminable |
| Import style | `has_blank_import`, `has_dot_import`, `has_wildcard_import` | Coupling accuracy caveats |
| Scope | `scope` | `"tool"` deps have different risk profile (build-time only); absent for normal deps |

Note: Fields with `omitempty` in the JSON schema (`has_vulnerabilities`, `vulnerability_count`, `max_cvss_score`, `overall_score`, `scope`, `indirect_via`, `import_files`) may be absent from the JSON. Treat absent booleans as `false` and absent numbers as `0`.

### Step 2: Classify threat profile

Assign a threat profile based on diet data:

| Profile | Criteria | Phase 2 strategy |
|---------|----------|-----------------|
| **CRITICAL-EXPOSURE** | `has_vulnerabilities=true` AND `lifecycle` in {EOL-Confirmed, EOL-Effective, EOL-Scheduled, Archived, Stalled} AND `import_file_count > 0` | Full Phase 2 on all security-critical files |
| **LATENT-RISK** | `lifecycle` in {EOL-Confirmed, EOL-Effective, EOL-Scheduled, Archived, Stalled} AND `import_file_count > 0` AND `has_vulnerabilities=false` | Phase 2 on security-critical files only |
| **SUPPLY-CHAIN-ONLY** | `import_file_count = 0` OR `is_unused = true` | Skip Phase 2 -- risk is graph/supply-chain, not data flow |
| **MONITORING** | `lifecycle` is Active, Legacy-Safe, or Review Needed, but `has_vulnerabilities=true` | Phase 2 optional -- assess known CVE impact |
| **LOW-RISK** | Any combination not matching above (e.g., `Legacy-Safe` or `Review Needed` with no vulns) | Produce minimal assessment noting the dependency is healthy or benign |

Lifecycle values produced by diet: `Active`, `Stalled`, `Legacy-Safe`, `EOL-Confirmed`, `EOL-Effective`, `EOL-Scheduled`, `Archived`, `Review Needed`.

### Step 3: Scope Phase 2 targets

Filter `symbols[]` and `import_files[]` to identify security-relevant subsets.

**Security-relevant symbol patterns** (language-neutral, case-insensitive substring match):

```
Auth, Cred, Secret, Token, Key, Encrypt, Decrypt, Sign, Verify, Cert,
TLS, SSL, Hash, Password, Session, Cookie, Policy, ACL, Permission,
Role, Assume, Identity, Provider, IAM, STS,
Connect, Dial, Transport, Listen, Serve, Client, Request, Response,
SQL, Query, Exec, Database, Store, Cache, Write, Put, Delete,
Marshal, Unmarshal, Decode, Encode, Parse, Deserialize
```

**Security-critical file path patterns** (substring match on `import_files[]`):

```
auth/, credential/, secret/, crypto/, security/, acl/, policy/,
logical/, secrets/, iam/, rotation/, roles/, permission/,
transport/, client/, server/, handler/, middleware/, gateway/,
storage/, database/, physical/, cache/, session/, login/,
api/, endpoint/, route/, grpc/, http/
```

These patterns are **heuristics for prioritization, not hard filters**. A file that matches no pattern is not "safe" — it is merely lower priority. Any file in `import_files[]` could contain security-relevant code regardless of its path name.

Record:
- **Priority 1 (high-confidence security)**: files matching path patterns above
- **Priority 2 (remaining)**: all other files in `import_files[]`

When the security-relevant subset exceeds 50% of `api_breadth`, the dependency is likely an infrastructure/security SDK where nearly the entire API is security-relevant. In that case, treat all symbols as in-scope (do not filter by name) and rely solely on file prioritization for Phase 2 ordering.

### Step 4: Note coupling accuracy caveats

If any of these flags are set, note them -- they affect Phase 2 accuracy:

| Flag | Implication |
|------|------------|
| `has_dot_import` | Symbols used without package prefix -- `symbols[]` may be **undercounted**. Actual API surface is likely broader. |
| `has_wildcard_import` | Same: `from x import *` / `import static x.*` means undercounted symbols. |
| `has_blank_import` | Side-effect-only import (Go `import _ "pkg"`, JS `import 'pkg'`). Only `init()` / module side effects execute. Check what they do, but data flow is limited. |

If `scope` is `"tool"`: This is a build-time/tooling dependency (e.g., Go `tool` directive). It does not execute at runtime. Supply chain risk applies (compromised tool could inject malicious code at build time), but runtime data flow risk is absent.

## Phase 2: Targeted code inspection

**Skip this phase entirely if:**
- Threat profile is SUPPLY-CHAIN-ONLY
- No source code is available (Mode B input)
- `import_file_count` is 0

For each skip case, add a "Limitations" note to the verdict explaining what could not be assessed and why.

### Scoping strategy

Read files in priority order (Priority 1 first, then Priority 2). **Stop when you have enough evidence to construct credible attack scenarios for both Scenario A and Scenario B** (see Step 3 below). You have enough evidence when you can answer all four questions in Step 2 (Data IN, Data OUT, Security boundary, Failure mode) for at least the most security-critical call sites.

**Reading order:**
1. Priority 1 files (from Phase 1 Step 3) — read these first
2. Priority 2 files — read in order until you have enough evidence, or all files are read
3. For any files not read, produce a statistical summary: "N files in auth paths, M in infrastructure, K in tests"

**Stopping criteria — you have enough evidence when:**
- You can name the concrete data types flowing IN and OUT of the dependency
- You can describe at least one realistic attack scenario grounded in observed data flows
- Reading more files would add volume but not change the risk verdict

If you stop before reading all files, record which files were read and which were not in the verdict's "Limitations" section. This is not a failure — it is an explicit scope decision.

### Step 1: Classify import sites by security impact

For each file read, classify it:

- **Security-critical**: handles auth, credentials, secrets, crypto, storage of sensitive data, network transport, policy/ACL decisions
- **Infrastructure**: config loading, logging, metrics, CLI argument parsing, build tooling
- **Peripheral**: tests, documentation, examples, code generation, benchmarks

### Step 2: Trace data flows at security-critical sites

For each security-critical import location, determine:

1. **Data IN**: What data is passed TO this dependency? (credentials, secrets, user input, config values, plaintext?)
2. **Data OUT**: What data comes FROM this dependency? (connections, sessions, decoded secrets, query results?)
3. **Security boundary**: Is there encryption, validation, or auth gating around the call site?
4. **Failure mode**: If this dependency silently returned wrong data, what would break? Would anyone notice?

Quote specific file paths and line numbers. Do not speculate -- if you cannot determine something from the code, say "undetermined from static analysis."

### Step 3: Construct attack scenarios

Build scenarios from the actual data flows observed in Step 2, not from generic templates.

**Scenario A -- Unpatched vulnerability**:
- Does the dependency have known CVEs? (check `has_vulnerabilities`, `vulnerability_count`, `max_cvss_score` from diet)
- If known CVEs exist: What specific data flows are exposed by them?
- If no known CVEs: Given the data flows observed, what category of vulnerability (RCE, data leak, auth bypass, DoS) would have the highest impact if discovered?

**Scenario B -- Supply chain compromise**:
- If this package **exfiltrated data via IN flows**: What could an attacker steal? (Based on actual Data IN from Step 2)
- If this package **altered OUT flows**: What would break? What would be silent?
- Is the attack **detectable?** A crash is detectable. Subtly wrong auth decisions or silently leaked credentials are not.

### Step 4: Identify mitigating factors

These factors affect **risk severity** (how dangerous is keeping this dependency), not removal feasibility (how hard is it to remove). Removal planning belongs in `/diet-evaluate-removal`.

For each applicable factor, cite the evidence from the code:

- Upstream encryption before data reaches this package
- Downstream validation after data leaves this package
- Package pinned by lockfile integrity (go.sum, package-lock.json, pip --require-hashes)
- Package is small and auditable (check `api_breadth` -- under 10 is auditable)
- Usage is behind a build tag / feature flag that limits exposure
- Test-only usage (files in `*_test.go`, `test/`, `__tests__/`, `tests/`)
- `scope: "tool"` -- build-time only, no runtime exposure

## Phase 3: Risk verdict

### Single dependency verdict

```
### {package_name} -- Risk: {CRITICAL|HIGH|MEDIUM|LOW}

#### Diet Facts (from automated analysis)

| Metric | Value |
|--------|-------|
| PURL | `{purl}` ({name} {version}, {ecosystem}) |
| Rank | #{rank} of {summary.total_direct} direct deps |
| Lifecycle | {lifecycle} ([registry link]) |
| Known CVEs | {vulnerability_count} {(max CVSS: {max_cvss_score}) if present, else "(CVSS unavailable)"} |
| Priority / Overall | {priority_score} / {overall_score} |
| Difficulty | {difficulty} (coupling_effort: {coupling_effort}) |
| Coupling | {import_file_count} files, {call_site_count} calls, {api_breadth} APIs |
| Graph impact | {graph_impact} (exclusive: {exclusive_transitive}, total: {total_transitive}) |
| Health risk | {health_risk} |
| Stays as indirect | {stays_as_indirect} {-- via {indirect_via} if true} |
| Import caveats | {list any true flags: has_dot_import, has_wildcard_import, has_blank_import} *(omit row if all false)* |
| Scope | {scope} *(omit row if absent)* |

#### New Findings (from this assessment)

**Threat profile**: {CRITICAL-EXPOSURE | LATENT-RISK | SUPPLY-CHAIN-ONLY | MONITORING | LOW-RISK}

**Files inspected**: {N} of {import_file_count} files read ({M} Priority 1, {K} Priority 2)

**Data flow summary**:

| Direction | Data type | Security relevance |
|-----------|-----------|-------------------|
| IN | {concrete data observed} | {impact if compromised} |
| OUT | {concrete data observed} | {impact if tampered} |

**Scenario A (Unpatched vulnerability)**: {concrete scenario based on observed data flows}

**Scenario B (Supply chain compromise)**: {concrete scenario -- what could be stolen or altered}

**Mitigating factors**:
- {factor with code evidence}

**Limitations**: {what could not be assessed -- e.g., "51+ files; sampled 10 security-critical files only"}

**Verdict**: {1-2 sentence risk summary}
**Recommended posture**: {one of the following}
```

#### Posture definitions

| Posture | Meaning |
|---------|---------|
| **Remove urgently** | Active exploitation risk or critical data exposure. Run `/diet-remove` now. |
| **Plan removal** | Significant risk that grows over time. Run `/diet-evaluate-removal` to plan. |
| **Monitor** | Low current risk but degrading health. Re-assess quarterly. |
| **Accept with documentation** | Risk is understood and mitigated. Document the decision and rationale. |

### Multiple dependencies summary table (top N mode)

After individual verdicts, produce a summary:

| Package | Lifecycle | Diet Priority | Difficulty | Threat Profile | Risk | CVEs | Posture |
|---------|-----------|--------------|------------|---------------|------|------|---------|

## Primary Source Links

The verdict MUST include verifiable primary source links. Never claim "EOL", "Archived", or "has CVEs" without evidence.

### Required links

| Claim | Required link |
|-------|--------------|
| Lifecycle status | Package registry page (see PURL-to-URL table below) |
| Known CVEs | NVD (`nvd.nist.gov/vuln/detail/<CVE>`), GitHub Advisory (`github.com/advisories/<GHSA>`), or OSV (`osv.dev/vulnerability/<ID>`) |
| Scorecard | `https://scorecard.dev/viewer/?uri=github.com/<org>/<repo>` |
| Repository archived | GitHub repo URL (shows archived banner) |
| Last commit date | `https://github.com/<org>/<repo>/commits/<branch>` |

### PURL-to-registry URL

| Ecosystem | URL pattern |
|-----------|-------------|
| `pkg:npm` | `https://www.npmjs.com/package/<name>` |
| `pkg:golang` | `https://pkg.go.dev/<namespace/name>` |
| `pkg:pypi` | `https://pypi.org/project/<name>` |
| `pkg:maven` | `https://central.sonatype.com/artifact/<namespace>/<name>` |

## Language-specific reference

The core analysis (Phases 0-3) is language-neutral. Use this table for language-specific details:

| Aspect | Go | Python | JavaScript/TypeScript | Java |
|--------|-----|--------|----------------------|------|
| Build constraints | `//go:build` tags | N/A | N/A | Maven profiles |
| Side-effect imports | `import _ "pkg"` | `try/except ImportError` | `import 'pkg'` (no binding), `require('pkg')` | Static initializer blocks |
| Wildcard imports | `import . "pkg"` | `from x import *` | N/A (namespace `import * as ns` -- symbols tracked via `ns.` prefix) | `import static x.*` |
| Lockfile integrity | `go.sum` hash verification | `pip --require-hashes` | `package-lock.json` integrity field | `maven-enforcer-plugin` |
| Vulnerability scanner | `govulncheck` | `pip-audit`, `safety` | `npm audit` | `dependency-check`, OWASP |
| Test file patterns | `*_test.go` | `test_*.py`, `tests/` | `*.test.js`, `__tests__/` | `*Test.java`, `src/test/` |

## Important rules

- **Start from diet's output.** Do not re-discover what diet already computed. The `symbols[]` and `import_files[]` fields are your starting points for Phase 2.
- **Read in priority order, stop when you have enough.** Phase 1 Step 3 gives you the reading order. Stop when you can construct credible attack scenarios — not when you hit an arbitrary file count.
- **Be precise.** Quote specific file paths and line numbers. "The auth module uses this" is too vague.
- **Do not speculate.** If you cannot determine something from the code, say "undetermined from static analysis."
- **Do not overstate risk.** If data is encrypted before reaching the package, the supply chain scenario changes. Say so.
- **Focus on silent attacks.** Crashes are detectable. Subtle behavior changes (wrong auth decisions, leaked credentials, altered responses) are the real threat.
- **Do not assess replacement options.** That is `/diet-evaluate-removal`'s job. This skill assesses the risk of the status quo.
- **Always include primary source links.** Every lifecycle claim, CVE reference, and scorecard score must have a clickable URL.
- **State limitations explicitly.** If you sampled 10 of 51 files, or skipped Phase 2 because no source was available, say so in the verdict.
- **`stays_as_indirect` matters.** If the dependency remains as an indirect dep after removal, note that removing direct usage reduces but does not eliminate the risk.