Pull requests

Publishing a fix creates a branch, commits the patch, and opens a review request against the scanned branch. Older scans without a recorded branch use the repository default. If the target branch has changed since the patch was prepared, scan its current revision and prepare the patch again. GitHub requests start as drafts: review the changes, then mark the request ready before merging. Publication is the first moment Cefense writes anything to your repository.

Opening one

cf fix publish <finding-id>

You are asked to type the repository name to confirm, so there is no accidental pull request. In agent mode the same gate exists as an explicit --yes flag. The same action lives on the finding in the workspace.

What lands in the description

• What the finding is, its severity, and why it is dangerous in this repository.
• Where the finding is: the file and the line it was reported at.
• The explanation of what the patch does and why that closes the path, and a plain statement of what it does not do.
• The research behind the finding, where there is any.
• For a generated patch, that it was generated by a model. Recorded patch checks are reported separately with the proposal hash and base revision; repository CI, merge and a later scan are separate steps.

Merging

cf fix merge <finding-id>
cf fix merge <finding-id> --method squash
cf fix merge <finding-id> --no-delete-branch

--method takes merge, squash, or rebase, and defaults to squash. The branch is deleted after merging unless you keep it. Run cf fix merge with no argument and it offers the open pull requests to choose from, or merges straight away when there is only one.

Branch protection is respected

After the merge

Merging changes the code. It does not close the finding. Rescan, and let the next scan of the newer commit be what records it as resolved.

cf scan --wait
cf reproduced --severity critical,high

If the repository scans on push, the merge commit triggers that scan on its own. See Scan triggers.