How to verify software provenance in a marketplace

Software provenance is verified at the distributor and in the installed file. Procurement compares the artefact with an independent, authenticated reference and defines who will stop its use. On 29 October 2026, malicious versions of an extension, an installed component that adds functions to a program, appeared in Cursor's marketplace.

The Cursor notice, updated on 30 October, identifies versions 2.1.312 and 2.1.313 of Anthropic.claude-code for Windows and macOS, available from approximately 2:27 a.m. to 1:35 p.m. Pacific time. The modified versions were made available in Cursor's marketplace but were not developed by Anthropic. The notice does not identify affected organisations, customers, or countries, and does not report a paid purchase. The case does not prove a buyer failed.

What should be gathered before evaluating the purchase?

The evaluation starts with the proposal, the available contract, the manufacturer and the delivery channel, as well as an inventory of the intended extensions. Procurement needs to bring engineering, security and finance together before signing, because each team is responsible for part of the approval and none can complete it alone.

The inventory should list the product, extension identifier, version, operating system, intended users and internal owner, so that security can locate installations when an alert concerns that package. For a managed workstation, or endpoint, the company must define who authorises installations and who restricts them.

Acceptance follows five steps.

1. Identify who sells and who distributes.
2. Check the identity and integrity of the artefact.
3. Agree on incident response with the parties involved.
4. Limit the authority granted on the machine.
5. Define and test shutdown.

Each step requires evidence.

Step 1: who sells and who distributes the software?

The software supply chain starts before the contract: the parties that make, sign and deliver the file may be different. Procurement records these identities and obtains confirmation of the authorised channel for each component, because the name on the proposal does not, by itself, identify the provenance of the package installed on the workstation.

In the comparison between direct purchase and a marketplace, the commercial route helps identify who is responsible for the proposal. On either route, the buyer confirms who is the contracting party, who issues the invoice and who delivers the extension. The commercial route does not replace a software provenance check.

Each answer requires a document or written confirmation before purchase.

The Brazilian Federal Revenue Service describes the NFS-e as a digital document that formalises the provision of services. It does not verify the bytes of the artefact. Finance and legal examine the document applicable to the transaction; the article on imports and invoices addresses the document trail separately.

Nexforce Marketplace offers a route for purchasing international software with local payment and centralised management. On both routes, procurement confirms billing, payment, the manufacturer and the channel. Local purchasing does not replace verification of the file.

Step 2: how do you verify software provenance in the artefact?

Software provenance verification compares the received artefact with an authenticated reference independent of the delivery channel, tied to the correct identifier, version and platform. When there is a verifiable signature, security must also examine who signed it and whether the chain of trust remains valid.

A hash is a digest calculated from the contents of a file, and verification of software extensions depends on a reference that does not come from the same channel. If the hash of the received artefact differs from the trusted reference, the installation does not pass acceptance. If it matches, the comparison indicates that the files match for that calculation, but it does not prove authorship when the file and reference came from the same compromised channel. The independent source must be authenticated. The check is repeated with every update, not just at installation.

A digital signature allows the team to check integrity and the identity associated with the signature. The team verifies the signer. It examines the chain of trust. It checks revocation according to the file format. Without a trusted hash or a verifiable signature, procurement records the gap as pending or for a formal exception. Security findings triage complements, but does not replace, software provenance verification.

In the case reported by Cursor, the published hashes identify malicious files and help with detection. They are not trusted reference hashes. The team must separate the material used to look for compromise from the authenticated reference used to accept a new installation.

Step 3: how do you agree on incident response in the contract?

The contract should make clear who gives notice, through which channel, and from what starting point the negotiated notification period is measured. Procurement and legal obtain these commitments before signing and confirm how the supplier will support investigation and remediation when a suspicious artefact reaches machines.

The negotiation calls for affected versions and platforms, the exposure window, indicators and updates. The deadline needs a defined starting point and recipient. The parties agree on evidence preservation, investigation support and remediation guidance. Legal assesses notifications and responsibilities applicable to the transaction, without assuming obligations from the Cursor case.

These are proposals, not attributed clauses. Total cost includes investigation and restoration, even when the proposal does not list them separately.

Step 4: how do you limit authority on the developer's machine?

The company should authorise an extension according to the access it needs, not its advertised function. Engineering and security need to examine access to repositories, local files, the terminal, the network and credentials, and distinguish the extension's permissions from those belonging to the user or the machine administrator.

An extension running in the user's context can reach resources accessible to that account; administrative access is a separate decision and should follow its own process. The inventory should record which components can start processes, change settings or remain active after the program closes. The team reviews the need for that access when the version or function changes.

In the Cursor notice, the code tried to add an SSH key controlled by the attacker, enable the local SSH service and open a reverse tunnel. Enabling the service required administrator privileges that the extension did not have on most hosts; on those hosts, that step failed. According to the notice, the key was added, persistence was installed and host data was sent. This does not prove remote access on every device. Nor does it prove credential theft.

Step 5: how do you define and test shutdown?

Shutdown must cover distribution and execution on machines already exposed. Before purchase, security and operations define who removes a package from the channel, who blocks execution on managed endpoints, and who isolates a device with evidence of compromise.

Procurement and legal record in the contract which shutdown measures are the supplier's responsibility and which belong to the channel, after confirming that division. Removing an item from the catalogue does not remove installed persistence. Cursor reports that it removed the versions, blocked distribution and rebuilt the marketplace; uninstalling the extension may not be enough. The company requires verifiable recovery instructions.

The test starts with the version inventory and confirms whether the teams can locate installations, block execution and record the responsible people. The test simulates the arrival of a new version before verification. Security preserves evidence before cleanup and verifies the return to use. The absence of an indicator does not prove that the machine is clean.

When there is evidence of malicious execution, the plan should allow isolation, investigation, removal of persistence and an assessment of whether to rebuild the device. The responsible team assesses credential and session rotation from a trusted system and records the result.

How do you verify that the purchase is ready for approval?

The purchase is ready when each requirement has evidence accepted by the competent team and a person responsible for the decision. Gaps remain pending or go through a formal exception, with risk, deadline, owner and compensating measures documented; commercial approval alone does not replace technical acceptance before installation.

The matrix sets out requirements for the buyer, not guarantees from a supplier, and organises security in software purchasing around verifiable evidence.

Approved means that the six controls have been accepted for the approved versions. Pending indicates missing evidence or a missing test. A formal exception requires a decision by the competent authority, a review date and compensating measures; it does not turn a missing verification into a completed one.

What mistakes should buyers avoid?

One mistake is treating a commercial document as a control that it does not perform. An invoice, a hash and removal from the catalogue answer different questions; the team needs to preserve that distinction in the record and review it when the software version changes.

The invoice documents the transaction to which it refers, while file integrity depends on a technical check. A hash copied from the same suspicious channel does not prove authorship. And removing an extension from the marketplace does not, by itself, clean the machines on which it has already run. These are distinct gaps, with different owners.

Frequently asked questions

An invoice does not authenticate an extension, and removing a package from the catalogue does not clean the devices on which it has already run. The purchase decision requires technical evidence. Without a trusted reference, acceptance should remain pending or go through a formal exception assessed by the competent authority.

Does the invoice prove the extension is authentic?

No. The NFS-e formalises the provision of services within the scope described by the Brazilian Federal Revenue Service; it does not verify the installed file. The buyer should ask the supplier to identify the channel and provide the applicable technical evidence, and ask finance to examine the transaction document.

Is a hash matching the one published by the channel enough?

Not when the file and hash come from the same channel that may have been compromised. The comparison requires an independent, authenticated reference for the correct version and platform. Without that reference or a verifiable signature, the decision remains pending or goes through a formal exception.

Does removal from the catalogue resolve the incident?

It can stop new deliveries through the channel, but does not guarantee removal of a key, process or persistence on endpoints. Security should investigate the exposed devices and follow the documented containment and recovery plan. The absence of an indicator alone does not prove the devices are clean either.

Who should approve the purchase?

Procurement coordinates the commercial decision, but engineering and security must accept the technical evidence and the shutdown test. Legal assesses the negotiated commitments and finance checks the transaction documentation. When there is a gap, the internal risk authority decides on the documented exception.

References and Further Reading

The following sources address different parts of the purchase decision: the Cursor notice describes the incident and its indicators, while the Brazilian Federal Revenue Service explains the documentary purpose of the NFS-e. Neither proves the integrity of the file. A signed contract does not replace technical evidence.

• Cursor: extension security notice
• Brazilian Federal Revenue Service: issuing a national-standard NFS-e

How do you make the next purchase operational?

Installation should not be authorised merely because the contract was signed or the invoice arrived. The next acquisition should have an authorised channel, evidence of software provenance and an owner for containment on record. Nexforce Marketplace can structure local purchasing; artefact verification and technical response still require their own owners and evidence.