Dependency Governance Policy Compliance Check Prompt

This prompt is for platform engineers and architects who need to automate the enforcement of dependency governance policies across a codebase. The job-to-be-done is to take a set of declared rules—such as allowed licenses, approved vendor lists, version constraints, and internal module boundaries—and produce a structured compliance report that can be consumed by a CI/CD pipeline. The ideal user is someone responsible for maintaining the build health and architectural integrity of a multi-team codebase, where manual review of every dependency change is no longer feasible.

Use this prompt when you have a machine-readable dependency manifest (e.g., a package-lock.json, go.sum, or Pipfile.lock) and a corresponding governance policy document. The prompt expects both as inputs. It is designed to work in a gated check workflow: a pull request triggers the check, the prompt evaluates the proposed dependency changes against the policy, and the output determines whether the build proceeds or is blocked. Do not use this prompt for ad-hoc library research, for evaluating the quality of a library's implementation, or for making architectural decisions about which library to use. It is strictly a compliance check against pre-defined rules.

This prompt is not a replacement for a full software composition analysis (SCA) tool. It does not scan for known vulnerabilities (CVEs) unless that is explicitly part of the provided policy. It also does not resolve transitive dependency conflicts or suggest alternative libraries. Its scope is bounded to answering the question: 'Does this dependency change violate our written governance policy?' If you need a broader security audit, use a dedicated SCA tool and then feed its output into this prompt as additional context. Always require human review for any policy violation that is flagged as a BLOCKER before merging, and ensure the output is logged as an audit artifact.

This template is designed to be the core instruction set you send to a model when you need to audit a software project's dependencies against a defined governance policy. The prompt accepts a dependency manifest, a policy document, and optional context about the project's risk profile. It forces the model to reason step-by-step, ground every violation in a specific policy clause, and produce a machine-readable JSON report suitable for direct integration into a CI/CD pipeline. The square-bracket placeholders allow you to swap in different manifests, policies, and output schemas without rewriting the core logic.

markdownCopy
You are a dependency governance auditor. Your task is to check the provided [DEPENDENCY_MANIFEST] against the rules defined in [GOVERNANCE_POLICY]. You must produce a compliance report in the exact JSON format specified in [OUTPUT_SCHEMA].

# INPUTS
- **Dependency Manifest:** [DEPENDENCY_MANIFEST]
- **Governance Policy:** [GOVERNANCE_POLICY]
- **Project Context:** [PROJECT_CONTEXT]
- **Risk Level:** [RISK_LEVEL]

# PROCEDURE
1. Parse the dependency manifest to extract every direct and transitive dependency, including its version and declared license.
2. For each dependency, check it against every rule in the governance policy. A violation occurs if a dependency's attributes (name, version range, license, source) match a disallowed pattern or fail to match a required pattern.
3. For each violation, you must cite the exact policy clause ID and the specific attribute that caused the violation.
4. If the policy references an allowed list, any dependency not on that list is a violation unless explicitly covered by an exception rule.
5. Classify the severity of each violation based on the [RISK_LEVEL] input: 'low' for non-production or internal tools, 'medium' for production services, 'high' for security-sensitive or customer-facing systems.

# CONSTRAINTS
- Do not hallucinate policy rules. If a rule is ambiguous, flag it as 'needs_clarification' in the report.
- If the license field is empty or 'UNKNOWN', treat it as a violation of any rule requiring license transparency.
- Ignore devDependencies unless the policy explicitly includes them.
- For version constraints, treat a missing version lock (e.g., a range like '^1.0.0') as a violation if the policy requires pinned versions.

# OUTPUT
Produce a single JSON object conforming to this schema:
[OUTPUT_SCHEMA]

To adapt this template, start by replacing the [DEPENDENCY_MANIFEST] placeholder with a parsed representation of your project's dependencies, such as the output of pip freeze, a package-lock.json file, or a CycloneDX SBOM. The [GOVERNANCE_POLICY] should be a structured text document containing your organization's rules, ideally with clause IDs for traceability. For the [OUTPUT_SCHEMA], define a strict JSON schema that your downstream systems can validate, including fields for dependency_name, violation_type, policy_clause, and severity. Before deploying this prompt into a CI/CD pipeline, run it against a golden dataset of known-clean and known-violating manifests to verify that the model correctly identifies violations without producing false positives from ambiguous license identifiers or dev-only dependencies.

This prompt is designed to be embedded in a pre-commit hook, pull-request check, or CI/CD pipeline stage that gates dependency changes. The harness should invoke the LLM with a structured request containing the dependency manifest (e.g., package.json, requirements.txt, Cargo.toml), the governance policy document, and the expected output schema. Because dependency governance failures can block releases or introduce security risks, the harness must treat the LLM output as advisory until it passes deterministic validation against the declared policy rules.

The implementation should follow a validate-then-enforce pattern. First, parse the LLM's JSON output and run it through a schema validator that checks for required fields (dependency_name, current_version, policy_rule, status, evidence). Next, cross-reference each violation claim against the actual manifest file to ensure the dependency and version exist—this prevents hallucinated violations. For high-risk environments, add a deterministic policy engine (e.g., Open Policy Agent or a custom rule evaluator) that independently checks the same rules and flags any discrepancy between the LLM's output and the engine's result. Discrepancies should trigger a retry with the discrepancy details injected into the retry prompt as [PREVIOUS_ERRORS].

Log every invocation with the prompt version, model used, input manifest hash, policy version, raw LLM response, validation result, and final pass/fail status. This audit trail is essential for governance workflows where you must prove why a dependency was allowed or blocked. For CI/CD integration, emit the final compliance report as a machine-readable artifact (JSON or SARIF) that your pipeline can consume. If the prompt fails validation after a configured number of retries (recommend 2), escalate to a human reviewer via a PR comment or ticket rather than silently passing or failing the build. Avoid using this prompt as the sole gate for production deployments without deterministic backup checks.