Package risk review

Produce a decision about the exact package artifact under review, supported by observations and explicit evidence gaps. Select the relevant branch: dependency selection, release anomaly, incident exposure, or changed risk report. A suspicious signal prioritizes investigation; it does not by itself establish maliciousness or execution.

For services accepting document, image, audio/video or archive uploads, apply the upload processing audit baseline. Trace intake through delayed or optional processing and actual native dependencies; include its chain inventory, control assessment and unresolved edges in the review output. This applies even when the upload handler only stores bytes.

Establish identity before comparing

Resolve the registry, namespace, package name, version, distribution URL, integrity digest, platform variant, and observation time. Retain both the requested dependency name and the resolved artifact. For generated or unfamiliar names, verify existence and intended upstream through independent project documentation or a trusted manifest. Check similar spellings and namespace confusion without installing candidates to discover what they do. For scoped or internal-looking names, resolve which registry the name actually resolves from and whether an unclaimed lookalike name could be registered publicly (dependency confusion).

Keep publisher identity scoped to its registry and account ID. Separate current maintainers, the account that published this release, repository owners, signing identities, and provenance builders. Display names and public emails are attributes, not stable identity keys. When stable account IDs are unavailable, preserve the registry-qualified handle with that limitation.

Cross-registry name or email matches support a proposed identity link with cited reasons and counterevidence. They never merge accounts automatically. Verified organization control or an authenticated upstream statement can strengthen a link; copied metadata and self-asserted links carry less weight. Signed provenance establishes the supported origin claims, not that the code is benign.

Complete this step when each compared artifact and publisher is distinguishable, or explicitly report the unresolved identity that limits the review.

Measure release and publisher changes

Choose a baseline that answers the question: the last approved release, the immediate predecessor, or a stated historical window. Record why it was selected. Inspect available metadata and saved artifact contents first. Registry metadata reads are the passive default. Fetching artifact bytes, installing, executing lifecycle scripts, running the package, writing files, and submitting artifacts to providers are active work: each requires a durable approval record, and artifact bytes obtained through an approved fetch must be stored via the Evidence Interface (src/server/evidence/artifact-service.ts) and compared by digest before any content review.

When a reviewed tarball is available, diff the lifecycle scripts: extract scripts (preinstall, postinstall, prepare, and friends) from the baseline and reviewed package.json, and treat any newly added or changed install-time script as the highest-signal supply-chain check. Registry metadata enumeration respects rate limits; cache responses and preserve raw registry JSON responses as cited Artifacts.

Measurement	Definition and comparison
Publisher prior releases	Count releases attributable to this registry account before the reviewed release within a stated UTC window; record distinct packages separately. Identify pagination limits, attribution gaps, deleted releases, and coverage.
Publisher first seen	Record earliest observed activity globally within this registry separately from earliest activity on this package. Neither date proves account creation.
Time to first release	Measure elapsed time from verified account creation to its first attributable release only when both timestamps are available. Otherwise record the observable interval with a different name, or mark unknown.
Artifact size change	Compare bytes for the same artifact representation and platform. Record baseline/current bytes, absolute delta, and relative delta only with a nonzero baseline. Distinguish compressed and unpacked size.
Dependency changes	Count and list direct additions/removals separately from transitive changes. Preserve version, source and lockfile differences; compare equivalent platforms and dependency modes.
New transitive publishers	Enumerate newly introduced registry-qualified publisher accounts in the resolved dependency closure. Record unresolved release attribution separately; current maintainer lists do not prove who published an old artifact.

Missing or truncated history is unknown, not zero prior activity. A genuinely new account can publish legitimate software. An established account can be compromised. Combine these measurements with changes to publish access, lifecycle scripts, bundled executables, network destinations, repository correspondence, and the behavior relevant to the target.

Look for a release explanation in the declared upstream channels. Record which channels and time window were checked. An absent announcement is a review signal; it is not evidence that the release is unauthorized. Discriminate explanations with the cheapest authorized check, such as comparing the artifact to its stated source revision or verifying the publishing principal through available records.

Select the disposition for this work

• Dependency selection: confirm the intended upstream and exact artifact; compare viable candidates against the user's requirements and observed risks. Recommend a choice, a hold for a specific unresolved check, or an alternative. Popularity and a clean scanner result are insufficient acceptance criteria alone.
• Release anomaly: identify which measured changes explain the concern and which benign explanations remain. Preserve the previous approved artifact identity; propose a review or rollback decision without silently changing dependencies.
• Incident exposure: distinguish a declared dependency, resolution, download, installation, loading, execution, and observed outbound behavior. Correlate lockfiles, artifact digests and target timelines. Inspect relevant repository/editor/lifecycle hooks for persistence if evidence points there. Removing the package alone does not establish cleanup. Dynamic analysis belongs to Detonation in a Workspace Container (GLOSSARY), and containment and credential rotation are separately authorized actions.
• Risk change: compare provider snapshots as described below. A supported worsening warrants prompt review of the affected artifact and deployment exposure; it does not establish compromise.

Compare provider risk evidence

Use Snyk, Socket, Wiz, VirusTotal, or another provider only through capabilities actually available to the agent and authorized for the data. Discover the connector's supported lookup inputs and returned fields; do not invent endpoints, scores, or package support. Prefer exact digest or package/version lookups where supported. A repository-, name-, URL-, or organization-level result has a different scope and must remain labeled as such. Check whether a package-health result covers only the latest release and whether dependency scores include the transitive graph. Connected tenant inventory and public advisories are different kinds of evidence.

Prefer an existing report lookup before artifact submission. A hash lookup discloses the queried hash but not file bytes. Manifest scans and file uploads disclose additional data and need explicit authorization for that disclosure; private scanning must be verified rather than assumed. An unavailable provider, absent report or zero detections is not proof that an artifact is benign.

Preserve each raw report as an Artifact. Record provider, retrieval and analysis times, report ID, queried identity, matched artifact identity, match precision, score system, scale and direction, model/ruleset version when exposed, and coverage. Keep malware detections, vulnerability severity, maintainer signals, and aggregate package risk distinct.

Compute a numeric change only for comparable system, scale, direction, model/version, coverage, and artifact match. For release-to-release comparison, label the distinct artifact digests and hold other dimensions constant. If a version or scale is unknown, retain separate snapshots and describe the reported change without asserting a calibrated trend. Provider disagreement requires inspecting the underlying observations. Never average unrelated provider numbers or invent a universal risk score or urgency threshold. Explain urgency using the changed evidence, reachable deployment, and potential impact.

Treat worsening comparable risk and newly reported malware as urgent review triggers. Hold a proposed new dependency or upgrade while the material concern remains unresolved, state the changed evidence, and preserve the prior approved choice. Do not silently upgrade, auto-remove deployed software or rotate credentials. A lack of prior score does not reduce the importance of new malware evidence.

Record and finish

Use security-observation-intake for evidence classification. Recall existing observations for the Target before duplicating work, then use the Investigation Graph tool's current record_observation contract:

• Put query identity, reviewed release and baseline identity in inputJson, which becomes the observation's input.
• Put observed publisher identities, resolved dependencies and provider results in outputJson, which becomes output. Keep large inventories, raw provider reports, and raw registry API responses in cited Artifacts.
• Use measurements for known numeric values with names and units, and baselines/sample counts where meaningful. Omit unavailable numbers; preserve their unknown status and reason in metadata.
• Use scores only for actual provider numeric scores, labeled by system and supplied version. Keep categorical-only results in output. Store scale, direction, model version, report identity and matching limitations in metadataJson rather than inventing schema fields.
• Use metadataJson, which becomes metadata, for registry-qualified account identities, first-seen timestamp semantics, history coverage, comparison window, measurement methods and uncertainty. These are observation metadata, not new global publisher entities.
• Cite the exact evidence, link the Target, record the observation time, and select supported concept IDs through the Security Knowledge tool. Confidence describes confidence in the recorded observation, not a manufactured probability of maliciousness.

Finish with the artifact and observation IDs, exact package/release identity, disposition, decisive measurements, unknowns, and one next authorized check if unresolved. Keep proposed identity links and maliciousness explanations as assertions until corroborated. A finding requires evidence of the stated security consequence; a provider alert or release anomaly can remain a useful observation without becoming one.