Review the artifact you will run, not just the repository

A repository review can be thorough and still leave an important question unanswered: is the package being installed the artifact that was reviewed?

An MCP integration often runs with access to useful local files or downstream credentials. Its installation path therefore belongs in the security review. Source, dependencies, build workflow, package contents and deployment configuration form a chain of evidence. A reassuring repository name at the beginning of that chain does not identify everything that executes at the end.

The goal is to make approval attach to a concrete artifact and a known operating boundary. That is more useful than collecting badges whose relationship to the installed code is unclear.

Identify the release before assessing it

Record the exact package name, version, source repository and source revision used for evaluation. For a container, record the image digest as well as the readable tag. For a locally built package, retain the build inputs and a digest of the resulting artifact.

Give each identifier a clear purpose. A version is convenient for people. A commit identifies source. An artifact digest identifies bytes. A build run connects a particular procedure to its output. Do not replace one with another merely because all four look like release metadata.

If a registry package points at a repository you cannot access, document that gap. It may be private rather than missing, but the public review path still does not work for someone without permission. Decide what evidence is required before the integration can receive production credentials.

Look inside the package

Inspect the published archive in a disposable review environment without executing its installation scripts. Compare its entry points, bundled files and runtime dependencies with the expected release. Check whether generated code, vendored components or native binaries are included even though they are not obvious in the source tree.

Read installation hooks and startup commands as code. A package can perform work before the MCP server has initialized, so restricting the tool list does not necessarily restrict installation behavior. A dependency classified as development-only can still affect a build that produces production code.

Do not assume an archive is harmless because its README matches the repository. The useful question is what code the selected installation and launch commands will run, under which identity, and with which files and network destinations available.

What provenance can establish

Npm's provenance documentation describes a verifiable link between a package and its source/build information. It explicitly distinguishes that link from a guarantee that the package contains no malicious code.

Use provenance to answer identity questions: which source and build produced this artifact, and does that match the release you intended to approve? Then evaluate the code and operating permissions separately. Authentic authorship does not make a dangerous operation appropriate for your environment.

The same distinction applies to signatures. Successful verification establishes facts about a signature under the configured trust policy. It does not prove every dependency was reviewed, every test was meaningful or every declared permission is necessary.

Build a release record that survives an incident

A small release manifest can tie together the evidence without becoming a new standards claim:

{
  "release": "example-integration-1.4.2",
  "source_revision": "<reviewed commit>",
  "artifact_digest": "<recorded SHA-256>",
  "dependency_lock_digest": "<recorded SHA-256>",
  "build_run": "<controlled build reference>",
  "configuration_revision": "<approved configuration>",
  "review": "<change review reference>"
}

Keep actual credentials out of this record. A reference to the credential configuration is enough to locate the authorized secret through the proper operational process.

Store the manifest where responders can retrieve it independently of the running integration. If the only record of the deployed version is an endpoint served by the suspected process, you have made investigation depend on the component being investigated.

Constrain the build path

Review who can modify the release workflow and which jobs can access publishing credentials. Build untrusted contributions in an environment that does not hand them production secrets. Give jobs the minimum permissions needed for their specific work.

GitHub's secure-use guidance discusses minimal token permissions, protecting secrets and risks from untrusted workflow input. Apply those controls to the actual release path rather than assuming that a passing CI badge covers publishing.

Pin third-party build actions to reviewed immutable revisions where your workflow supports that approach. Keep the readable version nearby for maintainers, but ensure the machine uses the identifier you reviewed. Record dependency changes explicitly; a lockfile supports repeatability but does not establish that its resolved dependencies are safe.

Update without turning caution into stagnation

A frozen dependency set is easier to identify, but it can remain vulnerable indefinitely if nobody owns updates. Establish a cadence and an urgent path for relevant advisories. Evaluate whether an affected dependency is present in the executed artifact and whether the vulnerable behavior is reachable in your use case.

Avoid two shortcuts. “The scanner found a CVE” is not a complete impact analysis. “We do not call that function directly” is not proof the function cannot be reached through a dependency. Keep the conclusion tied to the artifact, configuration and evidence reviewed.

For an upgrade, compare package contents and runtime behavior as well as version numbers. Re-run connection tests, permission-denial cases and representative tool workflows. If a patch changes installation hooks or downstream access, treat that as an operating change even when the version label suggests a small update.

Decide what evidence changes the approval

Write a short policy for situations the team will actually encounter:

End a release by checking the running artifact against the approved manifest. A successful upload or deployment command is only an intermediate event. The operational outcome is that the intended code, with the intended configuration, is executing in the intended place.

That traceable chain makes routine updates clearer and incident response faster. It also gives “reviewed” a concrete meaning beyond the fact that someone once read a repository with a familiar name.