Before granting a vendor its first private repository, decide which repository, revision and processing configuration you are prepared to expose. Trace that source through acquisition, model calls, logs, findings, support, backups and deletion to establish the limits of the grant. For each copy or transfer, ask what data moves, where it goes, who can read it, why it is needed, and how long it remains. Verify the answers against permission screens, architecture and data-flow documents, contractual terms, and a restricted pilot using a synthetic repository. A claim such as “encrypted,” “temporary,” or “zero retention” is incomplete until it names the exact service and data path. The answer changes with the integration: a vendor that reads only a customer-produced report has a different exposure surface from one that clones private repositories.
NIST's supplier due-diligence guide frames assessment as research into pertinent information about a supplier or product for an informed decision. For source-scanning software, that means reviewing the actual workflow the organization intends to enable, rather than assigning one score to every vendor or assuming a certification answers every data-flow question.
Illustrative review: a repository scanning pilot
Illustrative procurement case, not a vendor or customer result: Northstar wants a security service, called Vendor R here, to review one private application repository. Vendor R asks for a GitHub App installation with repository Contents read permission and offers a “zero retention” description. GitHub's installation flow shows the requested permissions and lets an installer choose all repositories or selected repositories. Northstar chooses one synthetic pilot repository and asks what happens after the App receives the source.
The vendor's answer is a sequence, not a slogan: installation token obtains files; a worker holds a task-local copy; selected ranges may go to a model service; a finding with a short excerpt may persist; error telemetry goes to a log provider; backups retain findings for a stated interval; authorized support staff can inspect a finding after a customer request. “Zero retention” might apply to one model request while findings and logs remain stored. Northstar records each scope separately and seeks evidence for the version and region it would actually buy.
| Data stage | Question to put to Vendor R | Evidence Northstar should receive |
|---|---|---|
| Repository grant | Which permissions, repositories, branches and events are necessary? | Installation permission list and a least-scope setup path |
| Acquisition | Is a full clone, selected file fetch, or customer-uploaded artifact used? | Data-flow diagram and connector behavior |
| Processing | Where are files and derived indexes held, and which job can read them? | Region, isolation boundary, work-area and cleanup design |
| External processing | Do prompts, excerpts, telemetry or artifacts cross to another service or region? | Exact subprocessors, model route, payload class and retention setting |
| Durable output | Which snippets, embeddings, reports and audit records persist? | Data inventory and access matrix |
| Operational copies | Can logs, traces, crash reports, tickets or support exports include source? | Event schema, redaction controls, retention and reader list |
| End of access | What happens on uninstall, contract end, deletion request and backup expiry? | Deletion workflow, backup schedule and revocation procedure |
The table is a request list, not evidence that Vendor R implements any particular control. A reviewer fills the final column from documentation, a restricted demonstration, and contract terms, then records what remains unverified.
Decide whether this repository may be the first private-source input
The broad vendor assessment establishes facts. The CTO's next job is narrower: decide whether Vendor R may process repository billing-core under one proposed configuration. In this synthetic case, the repository contains proprietary source and internal architecture, and the proposed private evaluation snapshot has been checked for credentials and customer datasets. The earlier synthetic repository is a separate, deliberately authored fixture. That preparation reduces avoidable exposure; it does not make the private source public or harmless.
Three answers remain unresolved. The normal worker route is documented, but cancellation traces may contain source. The vendor names an analysis region without showing the effective model route. Support can view findings, but its documented grant does not distinguish finding metadata from raw prompt access.
| Unresolved answer | Why it changes this authorization | Decision now |
|---|---|---|
| Cancellation traces | Source may reach an operational store with different readers/retention | Blocks private-source grant until capture schema and failure-path handling are evidenced |
| Effective model route | Named storage region does not identify every processing destination | Blocks this configuration until model/API/route and retention setting are identified |
| Support access | Finding help may expand to raw-source inspection | Require a narrowly described access process and applicable contractual commitments; raw-source support remains disabled unless separately authorized |
The team can continue with its synthetic repository while collecting these answers. It should not treat elapsed pilot time or a successful scan as permission to switch the connector to billing-core.
Evaluate the evidence that changes the memo
Vendor R supplies a versioned failure-event schema that excludes request bodies and nested exception causes, plus a restricted demonstration record covering normal failure and cancellation. The customer can observe those paths but cannot inspect every internal backup. The memo records demonstrated behavior for the exercised route and vendor/assessment evidence for unseen copies separately.
For model processing, the vendor supplies the proposed endpoint, model, API, region and effective retention configuration, including failure behavior if that route is unavailable. The buyer checks the applicable provider documentation. For example, Amazon Bedrock retention is a configuration-specific question; quoting a provider default does not prove a vendor's setting or account-wide behavior. A silent fallback would change the authorization and must not be assumed acceptable.
For support, the proposed contract/process limits the normal case to finding metadata under a customer-approved, time-bounded request. Raw source or prompts require a new named approval and disposition record. This is an illustrative purchasing condition, not an interpretation that any particular legal wording guarantees protection. Procurement and privacy specialists must assess the actual agreement.
Encryption evidence is useful but cannot replace the reader map. If a service role can decrypt stored source under its KMS key policy, the vendor has an authorized plaintext path. The memo should say who can use it, rather than calling server-managed encryption vendor-unreadable.
Filled first-access authorization memo
Decision: conditionally approve one private-source evaluation only after the named evidence and contract conditions below are accepted by their owners. This article does not itself grant access. Subject: billing-core, one pinned revision, selected-repository Contents-read integration, proposed processing configuration R3. Purpose: evaluate review usefulness on the agreed source scope. Prerequisites: accepted failure/cancellation telemetry evidence; exact model route and retention configuration; support access conditions accepted by procurement/security. Allowed data: approved source revision and expected findings; no production credentials or customer datasets. Operational owner: platform controls repository selection and can stop new reads. Review owner: security records outcomes and residual copy limits. Expiry/change trigger: end of the agreed evaluation or any permission, model route, subprocessor, retention or support-scope change, whichever occurs first.
The distinction between a condition and an observation matters. “Vendor promised source-free logs” is a contractual or declarative fact. “Marker absent from the cancellation trace supplied for R3” is a bounded observed result. Neither becomes “no internal source copy exists.” The approver can accept a documented residual uncertainty, but should not accidentally erase it from the evidence column.
Compare requested access with the approved source snapshot
The memo names one pinned revision, but the connector grant may allow the vendor to read other revisions or historical content from the selected repository. Distinguish the source the vendor promises to process from the source its credentials could fetch. A repository-selection screen establishes a repository boundary; it does not by itself establish a commit-only disclosure boundary. Northstar should ask how the vendor selects the approved revision, records acquisitions and prevents a background or retry job from reading a newer head.
If commit-only disclosure is a strict requirement and the integration cannot enforce it, the team can consider an owner-prepared snapshot or a separate repository containing only approved material, where the service supports that input. That choice has a tradeoff: it may not exercise the same connection lifecycle or history-aware features as a normal repository integration. Record the difference in the pilot's conclusions. A restricted input is useful only if the team knows which buying questions it can answer.
For billing-core, the acquisition receipt should identify the permitted repository and revision without exposing private filenames in a broad procurement tracker. The security owner can retain the detailed manifest in a restricted record. The business memo needs enough information to distinguish the approved subject from another repository, and to notice a route or configuration change. It does not need a pasted directory tree or source-containing screenshot.
Define what would stop the evaluation mid-run
A useful authorization includes observable stop conditions. In Northstar's example, the connector requesting additional repository permissions, an unexpected model route, source appearing in routine diagnostic output, or an unexplained support-access event would prompt the owner to pause further private processing and investigate. These are proposed conditions for this fictional pilot, not claims that a vendor has violated them.
The response should match the observation. A failed scan with a documented source-free error does not necessarily justify disconnecting the entire service. An unexpected request for repository writes changes the permission decision and should be explained before acceptance. A suspected source-bearing log requires restricting access to that copy and assessing its destinations, even if future repository reads have already stopped. Uninstalling alone would leave the handling of downloaded material unresolved.
Give the platform owner a contact and a concrete stopping mechanism, and give the security owner responsibility for the evidence and disposition requests. If an integration cannot cancel an active task immediately, record what the stop action actually does: prevent new acquisitions, prevent new analysis requests, or merely stop scheduling. The vendor's documented behavior and observed pilot evidence should support that distinction.
At the end of the evaluation, compare what was authorized with what occurred. List source acquired, processing configuration used, retained output classes, any exceptions and their owners. A successful finding demonstration answers the usefulness question; this reconciliation answers whether the pilot stayed within its approved exposure. Both belong in the purchasing decision, and neither should substitute for the other.
Make the stop decision executable
Before access begins, platform records how to stop new repository reads and how to request disposal of active work copies and retained outputs. Uninstalling an integration cannot recall bytes already fetched. Each data class needs its own disposition: task copy, finding excerpt, operational event, support attachment and backup. Follow vendor deletion review for that separate mechanism.
If Vendor R cannot resolve the model route or source-bearing failure traces, the concrete decision stays “synthetic evaluation only.” If it supplies adequate evidence, the approved private grant stays limited to the memo's exact repository and configuration. A general vendor approval in the broader procurement review must not silently expand this first-source decision.
For the next step, fill the stage table for one proposed integration and request the missing evidence before granting private-repository access. The guide to keeping source out of security logs gives a concrete telemetry review, while temporary tenant credential review covers data-access authority behind a multi-tenant service.