Dependency Health and Risk Audit Prompt

This prompt is designed for build engineers, security teams, and platform engineers who need to assess the risk profile of third-party dependencies before an upgrade, during a security review, or as part of a recurring supply-chain audit. It produces a structured dependency risk matrix by reasoning over a provided software bill of materials (SBOM), package manifest, or lockfile. The prompt is most effective when the model has access to current vulnerability data, release histories, and license information through tools or a pre-assembled context block. It is not a replacement for a full software composition analysis (SCA) tool, but it adds a layer of qualitative risk reasoning and prioritization that raw tool output often lacks.

Use this prompt when you need a human-readable risk assessment that explains why a dependency is risky, not just that it has a CVE. It excels at correlating multiple weak signals—such as a lagging version combined with low maintainer activity and a restrictive license—into a single risk narrative. The prompt is also useful for generating remediation plans, comparing upgrade paths, and preparing evidence for audit or compliance review. It requires a structured input block containing package names, current versions, and ideally recent release histories or vulnerability data. Without this context, the model will hallucinate version numbers and CVE details.

Do not use this prompt as a real-time vulnerability scanner or as the sole gate for production deployments. It cannot replace a deterministic SCA tool that cross-references live CVE databases. The prompt is also unsuitable for assessing proprietary or internal packages where no public registry data exists. For high-risk environments, always pair the output with a human review step and ground findings against a trusted vulnerability database. The next section provides the copy-ready prompt template you can adapt for your own dependency audit workflows.

This prompt template is designed to be pasted directly into your AI harness after you have assembled the required dependency data, vulnerability feeds, and license policies into the [DEPENDENCY_CONTEXT] block. It instructs the model to produce a structured risk matrix rather than freeform commentary, ensuring the output can be parsed, validated, and ingested by downstream security dashboards or ticketing systems. The template assumes you have already resolved package identifiers to a canonical format and enriched each dependency with the latest available metadata from your registries and CVE databases.

textCopy
You are a dependency risk auditor. Analyze the provided dependency inventory and produce a structured risk matrix.

[DEPENDENCY_CONTEXT]

[OUTPUT_SCHEMA]
{
  "dependencies": [
    {
      "package": "string",
      "current_version": "string",
      "latest_version": "string",
      "version_lag_severity": "low | medium | high | critical",
      "version_lag_rationale": "string",
      "maintainer_activity": "active | low | dormant",
      "maintainer_evidence": "string",
      "known_vulnerabilities": [
        {
          "cve_id": "string",
          "cvss_score": number,
          "exploitability": "low | medium | high",
          "fixed_in_version": "string | null",
          "summary": "string"
        }
      ],
      "license_identifier": "string",
      "license_risk": "compatible | review_required | prohibited",
      "license_risk_detail": "string",
      "overall_risk_score": number,
      "remediation_priority": "immediate | short_term | medium_term | low",
      "remediation_notes": "string"
    }
  ],
  "summary": {
    "total_dependencies": number,
    "critical_risk_count": number,
    "high_risk_count": number,
    "top_three_risks": ["string"],
    "audit_timestamp": "string"
  }
}

[CONSTRAINTS]
1. Assign version_lag_severity based on the gap between current_version and latest_version, considering major vs minor vs patch differences.
2. Mark maintainer_activity as dormant if no commits or releases in the last 12 months.
3. Only include known_vulnerabilities with a CVSS score of 4.0 or above unless the exploitability is high.
4. Classify license_risk as prohibited if the license appears in [PROHIBITED_LICENSES].
5. Calculate overall_risk_score as a weighted sum: version_lag (0.25), max CVSS (0.40), maintainer_activity (0.20), license_risk (0.15). Normalize to 0-100.
6. Set remediation_priority to immediate if overall_risk_score > 80 or any vulnerability has exploitability=high and no fixed version.
7. If any field cannot be determined from the provided context, use null and note the gap in the relevant rationale or evidence field.
8. Do not invent CVE IDs, version numbers, or license identifiers not present in [DEPENDENCY_CONTEXT].

To adapt this template, replace [DEPENDENCY_CONTEXT] with a structured block containing your dependency inventory, vulnerability feed results, and license policy data. The [OUTPUT_SCHEMA] block is included inline so the model sees the exact JSON contract it must satisfy. If your organization uses a different risk-weighting formula, adjust the calculation rules in constraint 5. If you maintain a custom list of prohibited licenses, supply it as [PROHIBITED_LICENSES] and reference it in constraint 4. Before running this in production, validate the output against the schema and spot-check a sample of risk scores against manual assessments to calibrate the weighting formula.

This prompt is designed to be wired into an automated pipeline, not run as a one-off chat. The harness is responsible for assembling the [DEPENDENCY_CONTEXT] block from multiple data sources before invoking the model. A typical pipeline fetches the project's direct and transitive dependency manifest from the package manager lockfile, queries a vulnerability database for each package-version pair, pulls maintainer activity metrics from the registry API, and resolves license metadata from the package manifest or a license database. The harness must deduplicate, normalize, and timestamp all fetched data so the model receives a consistent snapshot rather than stale or conflicting information.

Data assembly steps: (1) Parse the lockfile to extract the full dependency graph with resolved versions. (2) For each dependency, query an advisory database for known CVEs and record severity, vector, and fix availability. (3) Fetch registry metadata: last publish date, maintainer count, recent commit frequency, and open issue count. (4) Resolve license identifiers against an SPDX license list and flag copyleft, unknown, or incompatible licenses. (5) Pack all results into the [DEPENDENCY_CONTEXT] placeholder as structured JSON or a formatted table. The model should never be asked to fetch this data itself—the harness owns data freshness and completeness.

Validation and retry logic: After the model returns the risk matrix, run a structural validator that checks required fields per dependency: risk score, version lag category, vulnerability count, maintainer risk flag, and license risk flag. If any dependency is missing required fields or scores fall outside the 0–100 range, retry with a repair prompt that includes the validation errors. Limit retries to two attempts before flagging the dependency for manual review. For high-risk findings where the model reports a critical CVE or an abandoned maintainer, route the output to a human reviewer before it appears in any dashboard or report.

Model choice and tool use: This task benefits from models with strong structured output capabilities and large context windows to hold the full dependency snapshot. If the dependency list exceeds the context window, split by dependency group and run parallel audits, then merge results in a post-processing step. Do not give the model tools to query external APIs during the audit—the harness pre-fetches all evidence to keep the audit deterministic and auditable. Log every model invocation with the input snapshot hash, model version, and output for traceability.

What to avoid: Do not let the model hallucinate CVE IDs or version numbers when the fetched data is incomplete. If a dependency has no advisory data, the harness should explicitly mark it as "no known advisories" rather than leaving the field empty. Do not treat the model's risk score as a security verdict—it is a prioritization signal that must be combined with your organization's threat model and deployment context before action. Always version your dependency snapshot so audit results can be reproduced and compared over time.