Branches and commits

Findings belong to a scan, and a scan ran on one branch at one commit. That single fact explains most of how branches and history behave.

Branches

Push and scheduled triggers act on the default branch. Any other branch has to be scanned by name, and read by name.

cf branches
cf scan --branch release/2.4 --wait
cf reproduced --branch release/2.4

cf branches lists every branch the provider shows, each with the last scan of that branch: its id, its status, the finding count, and when it ran. A branch with no scan id has never been scanned.

Without --branch, you get the newest scan of the repository, whichever branch it ran on. --scan <id> reads one scan directly, which is what to use when you already have an id from cf branches or cf commits.

The scanned commit history

cf commits
cf commits --limit 50
cf reproduced --scan <scan-id>

One row per scanned commit, newest first, each with its SHA, message, author, timestamp, its scan id, and the deltas that scan produced: how many findings it introduced, how many it resolved, and how many were suppressed.

Those numbers come from reconciliation, so they are a record of what the scans actually reproduced rather than a diff inferred after the fact. That is what makes this the honest answer to when did this get introduced and did my fix close anything.

Proving a fix worked

cf fix merge <finding-id>
cf scan --wait
cf commits --limit 1

Merge, rescan, and read the history. The merge commit's row is where the finding is recorded as resolved. Until that scan runs, all you have is a merged patch and a hope.