Read-only analysis

Coldstart

Someone hands you a codebase you did not write. An acquisition. A system whose author left. A dependency nobody on the team has ever opened. Coldstart goes through all of it and comes back with a list of problems — and every entry points at one exact spot: which of the nine checks flagged it, the file, and the line number. You open the file, read the line, and decide.

Nothing on that list says “issues found” with no location attached, and there is no dashboard of vague warnings for somebody else to triage: a check that cannot name a file and a line is thrown out rather than passed to you. All nine checks are printed before a run starts. And it never runs your code, never connects out, and never writes inside the repository, which is what makes it safe to point at code you have no reason to trust. That is the only kind worth checking.

Tooling
Read-only
Internal / beta

Ask about Coldstart

What a run hands back, as the prototype draws it

9declared controls

4enforced refusals

51suite controls

MAP.md · FINDINGS.json · QUESTIONS.md · HANDOFF.md the pack

DELTA.md, only when two runs are compared second run

Findings that must carry a file and a line by rule

Secret-shaped values stored in the pack none

Interface study, drawn from the prototype’s own pack format — not a capture of a running build, and not an offer of a hosted one.

The files a run produces, and the promises that hold on every run rather than only on the good ones.

What you get

What it hands back

A run ends in files, not in a report you have to take on trust. Each one answers a different question, and none of them is allowed to invent an answer.

Always: MAP.md, FINDINGS.json, QUESTIONS.md and HANDOFF.md — what is in the repository, what each check found, what the checks could not answer, and what a reader needs in order to continue the work.
On a second run: DELTA.md, when two runs are compared with each other. The delta is the point of running twice, and it is described below.
Every finding: A check, a file and a line. If a check cannot name a file and a line, it is thrown out rather than reported, so nothing vague lands on the list for somebody else to chase later.
Where it is written: Outside the repository by default. An --out that resolves inside the code being read exits 2, and nothing is written into it.

The product

Four things it will not do

These are not features. They are the rules that decide what is allowed to become a finding — and they are the part of Coldstart that is hardest to copy.

No finding without a file and a line. If a check can point at a problem but not at a place, it is thrown out rather than passed on in a form somebody else will have to chase down.
No secret-shaped value in the report. This holds even for the check whose whole job is hunting secrets: it may report that something secret-shaped was found and where, but never the value, and the value is never stored.
No process started, no connection opened. Nothing in the repository is executed and nothing is called out to. The tool proves this by parsing its own source rather than promising it in a document, so the claim is checked rather than stated.
Nothing written into the repository. An --out resolving inside it exits 2, and the report defaults outside it. The code it reads is the code as it was handed over.

Delta packs

A second run reports what changed

Running the same controls twice answers a different question from running them once: not what is there, but what a change did to it.

A finding’s identity is (control, file, evidence) and never the line. Shift every line in a file by one and the delta reports “2 moved” rather than “2 resolved plus 2 discovered”.
The four states it reports are new, persisting, moved in line, and no longer reported.
A finding that stops being reported is called no_longer_reported, and it is never called fixed. The tool cannot see whether somebody repaired the code or hid it, so it does not claim to.
Two different targets are refused. A delta compares one repository with itself at two moments, not one repository with another.

The prototype

Two surfaces, on loopback

Coldstart ships two small surfaces for reading a run, and both are a local prototype rather than a service.

A customer form: what happened, what was expected, and an optional screenshot captured in the browser — the short account of a problem as the person who hit it would give it.
A tech-lead view: the same material arranged for somebody deciding what to do next.
Text carrying an e-mail address or a credential shape is refused, not redacted. A value that looks like a secret never enters the store, so there is nothing to redact afterwards.
A screenshot is stored with scanned_for_secrets: false, because an image cannot be checked the way text can. The record says so rather than implying the check happened.

Both surfaces are served locally on loopback by a server with no authentication, which is why they are a prototype and not an offer. There is no hosted version of this, nothing here is a sign-up, and no account exists to create.

Measured evidence

What happened on two packages it did not write

The first time it was pointed at somebody else’s code, it read two real third-party packages: pip, 430 files, and setuptools, 326 files. That run produced 106 findings, 56 of them HIGH.

106findings on the first scan of pip and setuptools — two packages written by other people.

56of those 106 were reported HIGH. That is the number the next paragraph is about.

6findings the same scans produce after the scanner’s own defects were fixed — all LOW on pip, and one MEDIUM plus five LOW on setuptools.

0high-severity claims left in that run, and 0 findings on a clean tree.

Spot-checking those findings found six defects, and all six were in the scanner itself. The two packages were healthy; the tool reading them was not. Fixing those defects is why the same scans now produce 6 findings on pip, all LOW, and 6 on setuptools — one MEDIUM and five LOW — with zero high-severity claims on either. That sequence is the honest history of the number rather than a footnote to it.

Its own suite: 51 controls, run offline. The suite checks the tool, including the assertions that it starts no process and opens no connection.
Shipped fixture: Yields 11 findings, four of them deliberately planted defects the run is expected to catch.
Clean tree: Yields 0 findings. A run that always finds something would be reporting its own noise.

The honest limits

What it has never been tested on

This section is the reason the numbers above can be believed. Everything here is a limit on what Coldstart has shown it can do.

It has never been pointed at a repository with a planted defect. Nobody has watched it find a problem that was deliberately hidden for it, so its usefulness is unproven rather than demonstrated. The fixture proves the controls can fire; it does not prove the tool is useful on a real codebase.
On two healthy packages the correct answer is “nothing worth doing”, and that is the answer it gives. pip and setuptools are not broken, and the twelve findings across both — none of them HIGH — are the honest size of the result. A tool that found something alarming in healthy code would be reporting itself.
It fixes nothing. It is read-only analysis: it does not edit the target, run the target’s tests, install its dependencies, or hold any credential. Everything it can tell you is a statement about a file and a line in the code as it was handed over.
It is internal and in beta. No hosted version exists, there is nothing to install from this page, and no date is being offered for one.

Read that together with the measured evidence and the shape is clear: the strongest thing Coldstart has shown is that it can be corrected. Whether it finds anything worth a human’s attention in an unfamiliar repository is still open.

Questions about Coldstart

What it would make of your repository, what a run looks like on real code, or why a check was thrown out rather than reported — ask.

Ask about Coldstart