The scan and fix loop

When the user has asked for the whole cycle rather than one finding, this is the shape it should take, and the rules that keep it safe.

The loop

cf org list --agent
cf scan --repo acme/api --org acme --wait --agent
cf reproduced --repo acme/api --org acme --severity critical,high --agent
cf reproduced show <finding-id> --repo acme/api --org acme --agent
cf fix generate <finding-id> --org acme --wait --agent
cf proof run <finding-id> --org acme --wait --agent
cf fix publish <finding-id> --org acme --yes --agent
cf fix merge <finding-id> --org acme --yes --agent
cf scan --repo acme/api --org acme --wait --agent

--org can be dropped if the account belongs to exactly one organization, or if CEFENSE_ORG is already set for the session. Otherwise the first command fails with organization_required.

The branch it runs against

By default Cefense scans the repository's default branch as the provider has it, so an agent's own changes have to land before they are analysed. To scan somewhere else, pass --branch, and read that branch's findings by naming it too.

A prompt that sets it up properly

Scan this repository with Cefense. For every Critical or High finding, read the
full detail including the data flow, tell me whether you think it is real and
why, and propose the smallest safe fix. Show me each diff before opening
anything. Do not merge.

The important part is the last two sentences. They set the boundary explicitly, which is what makes the agent's later behaviour predictable.

Rules for running it unattended

• Settle the organization before the loop starts. Run cf org list --agent first. It gives you the slug to pass and the role you hold, so you learn that you cannot publish now rather than five findings in.
• Get consent once, for the loop, and say what it includes. Fix and merge the critical findings in acme/api is consent to merge. Have a look at the findings is not.
• Still read every diff. Speed is not permission to stop judging. A patch that narrows the input instead of fixing the sink should be reported, not merged.
• One finding at a time. Generate, publish, merge, and confirm before starting the next. Batching means a bad patch is discovered after five have landed.
• Stop on the first refusal. pull_request_blocked and pull_request_conflicted mean a human set a rule. Report and wait.
• Rescan after merging, not before. Finding ids belong to a scan, so list again after a rescan rather than reusing old ids.

Guardrails that are not optional

• Never invent a finding id, a severity, a CVE, or an exploit path. All of it comes from the JSON.
• Never ask for a token or write credentials to a file. The CLI keeps its token in the operating system keychain.
• Never change scan settings without asking. They are the user's policy.
• If something is not in the JSON, say so instead of filling the gap.