Plugin compliance reporting becomes useful when another reviewer can reproduce the decision. A plugin risk report should show what was checked, a compliance plugin audit should record who checked it and when, a plugin compliance reporting template should keep evidence consistent, and evidence for plugin approval should point to source data rather than a confident sentence. This guide turns those requirements into a report that security, engineering, procurement, and audit teams can all read.
What a plugin risk report must answer
A report does not need to copy every repository field. It needs to answer the questions that change an install decision and preserve enough context for the next review.
- Identity: exact package name, publisher or owner, repository, registry source, and the version reviewed.
- Purpose: the business or engineering task the plugin performs, plus the system where it will run.
- Access: files, secrets, network destinations, child processes, and runtime privileges the plugin can reach.
- Health: current DSH Quality score, grade, maintenance recency, documentation coverage, and dependency condition.
- Findings: install-script warnings, missing bundle declarations, unresolved advisories, or unexplained ownership changes.
- Decision: approve, approve with conditions, defer, or reject, with an owner and a review date.
A score supports a decision. It does not replace the reviewer, the operating context, or the evidence file.
Evidence for plugin approval
Evidence should be a small packet that another person can inspect without recreating the entire audit. Capture stable identifiers and dated observations; avoid relying on a screenshot alone when a text value or commit reference exists.
| Evidence | Record | Reason |
|---|---|---|
| Plugin identity | Package, owner, repository URL, reviewed version | Prevents approval from drifting to a similarly named package |
| Source state | Commit SHA, release tag, package integrity or lockfile entry | Ties findings to the code that was actually assessed |
| Quality signals | DSH score, grade, last push, docs and npm health | Shows the measurable basis for the initial filter |
| Security findings | Install scripts, permissions, network behavior, advisories | Records the risks that need acceptance or remediation |
| Decision record | Reviewer, approver, conditions, expiry date | Makes ownership and the next review explicit |
For score definitions, link the packet to /blog/dsh-quality-score-decoded. For identity checks, use the process in /blog/how-to-verify-dsh-plugin-authenticity. Both pages already exist, so the report can stay short while its method remains reviewable.
A plugin compliance reporting template
Use the same headings for every plugin. Consistency lets an auditor compare decisions without learning a new document structure each time.
- Request: requester, intended use, environment, data classification, and requested install date.
- Plugin: name, owner, source, version, commit, license, and supported runtime.
- Assessment: DSH score and grade, maintenance status, documentation status, dependency status, and scanner findings.
- Access review: filesystem scope, environment variables, network access, subprocesses, and update mechanism.
- Decision: status, conditions, compensating controls, approver, expiry, and the event that triggers re-review.
- Attachments: lockfile excerpt, scanner output, relevant changelog, issue references, and test notes.
A conditional approval should be specific. Write 'approved only in the isolated build runner with outbound network blocked' rather than 'approved with caution.' The first instruction can be enforced and tested; the second cannot.
Run the compliance plugin audit
The audit works best as a short sequence with a stop point at each stage. A failed identity check should stop the process before anyone spends time reviewing documentation or license text.
| Stage | Action | Stop condition |
|---|---|---|
| 1. Verify | Match owner, package, repository, version, and release source | Identity or ownership cannot be confirmed |
| 2. Score | Read the current quality grade and each component | A hard security warning is present |
| 3. Inspect | Review install scripts, permissions, dependencies, and update behavior | Requested access exceeds the stated purpose |
| 4. Test | Install the pinned version in an isolated environment | Observed behavior differs from documentation |
| 5. Decide | Record conditions, owner, expiry, and review trigger | No team accepts the residual risk |
Teams that want this check in pull requests can follow /blog/ci-cd-plugin-scanning. The human review around the automated gate is covered in /blog/dsh-plugin-review-process, while /blog/setting-up-a-plugin-allowlist-for-your-dev-team turns approved entries into an enforceable list.
Review dates and change triggers
Calendar reviews catch slow drift, but event-based reviews catch the changes most likely to alter risk. Put both in the decision record.
- Review on a fixed cadence for plugins with stable ownership and routine updates.
- Review immediately after an ownership transfer, registry move, package rename, or signing change.
- Review after a new install script, broader permissions, a major dependency change, or a score drop across a grade boundary.
- Review before moving the plugin from a developer workstation into CI, production, or an environment with secrets.
- Close the approval when the plugin is removed; do not leave unused entries permanently active on the allowlist.
The team policy behind these triggers is explained in /blog/plugin-supply-chain-security-team-enforcement. Link that policy from the report so a reviewer can tell whether a condition is local to one plugin or required across the organization.
FAQ
- Is an A grade enough for approval? No. It is a strong first filter, but access, environment, data sensitivity, and the exact reviewed version still belong in the decision.
- How long should evidence be retained? Follow the retention period that applies to the system where the plugin runs, and keep it at least until the approval expires or is replaced.
- Do development-only plugins need a report? Yes when they can read source code, credentials, build output, or the network. Development status does not remove access.
- What if a plugin has no registry package? Record the repository and commit SHA, document the install method, and treat future commits as unapproved until reviewed.
Start the report from the live plugin index at dshquality.com /. Then use /blog/dsh-quality-score-decoded for score evidence, /blog/how-to-verify-dsh-plugin-authenticity for identity, and /blog for the rest of the review library. A short report with verifiable references is more useful than a long report built on memory.