All features Continuous codebase security
Security workflow
Available nowKeep security review inside the pull request lifecycle.
Winfunc evaluates pull requests against repository-owned review criteria, scans the immutable base and head revisions, and keeps investigation inside the changed-file scope. Findings can be published with location, impact, and remediation context, then checked again through an explicit re-review after the code changes.
Continuous codebase securityAvailable now
01Code change
02finding and triage
03reviewed fix
The problem
Security work should end in a decision, not another queue.
Point-in-time reviews fall behind fast release cycles, while noisy checks on every diff become easy to ignore. Teams need bounded review of security-relevant changes, findings anchored to the code under review, and a way to verify a fix without silently expanding scope.
WorkflowCode change → finding and triage → reviewed fix
How it works
From scope to an engineering decision.
Connect a supported repository, define the branches or pull-request workflow to review, provide application context and policies, and agree on which findings or changes should require human attention.
- 01Scope
Select security-relevant changes using repository review criteria
- 02Investigate
Review the immutable diff with repository and application context
- 03Investigate
Publish supported findings against changed lines with remediation context
- 04Review
Re-review the updated code and require affirmative evidence of a fix
Review-ready output
What your team gets.
Evidence, impact, and remediation context
An explicit fixed or still-present re-review
Built for handoff
Evidence your team can inspect.
Keep the reviewed scope, supporting evidence, uncertainty, and next action together so security and engineering can make the same decision from the same context.
Measure the workflow
Track selected versus skipped reviews, supported findings, time from finding to decision, publication failures, and the share of re-reviewed findings fixed before merge.
A recorded selection decision and the exact base and head revisions
Findings anchored to lines in the reviewed pull-request diff
Impact, evidence, and suggested remediation in the review context
A separate delivery state when publishing a GitHub comment fails
Re-review verdicts that distinguish fixed from still present
Why it matters
Focus deep review on the changes that matter and give developers a verifiable path from finding to fix.
Scope & limits
Review is bounded to supported repositories, exact revisions, changed files, and configured criteria. Re-review is explicit; engineers decide what ships.