Give Winfunc access to the repositories you want to review, then describe what matters in your application.
1
Sign in with GitHub
Open the Winfunc app and use the GitHub account that received your invitation. Access is currently invite-only.
2
Add repositories
Open Repositories and select Add repositories. Choose the GitHub account or organization and the repositories to include in the GitHub App installation. An organization owner may need to approve the installation.
3
Check the repository list
Return to Repositories. If a repository is missing, select Sync and check that it is included in the GitHub App installation.
4
Set your review rules
Open the repository, then Rules. Use Focus rules for what Winfunc should review and Reporting rules for how it should document findings. Select Save rules.
5
Arrange the first audit
Contact the Winfunc team to initiate a baseline audit. Self-service incremental scans require a previous completed scan on the permitted branch.
Useful context includes roles, tenant boundaries, sensitive operations, and the controls your team expects to enforce.
You’re done when your repository is visible in Winfunc, its review rules are saved, and the first audit is arranged.
Review the branch, scope, and credit estimate before starting an audit. Follow the run through to its findings.
1
Confirm the branch and guidance
In the repository, open Scans and select Run scan. Confirm the permitted Branch. Notes describe the run in history; Review guidance gives the analysis additional context.
2
Review the estimate
Select Estimate. Check the effective scan type, commit, baseline, changed files and lines, estimated credits, and reservation. Self-service scans are Incremental and compare against a previous completed scan. If the estimate cannot start, resolve the displayed reason first.
3
Start and follow the scan
Select Start scan. Follow the active run and return to History for completed runs. Keep the scan revision with your review so later changes do not get confused with the audited code.
4
Set a schedule
Use Schedule for a single future date and time. For recurring scans, open Cadence, select Set cadence, choose the interval and branch, enable it, and select Save cadence.
Self-service runs and schedules require an enabled repository, scan authority, a completed baseline on the permitted branch, and sufficient credits. Branch and change-set limits can apply. Contact Winfunc for an initial audit or a larger change set. A saved schedule does not mean a run has completed.
You’re done when a completed scan has a recorded revision, status, and findings you can review.
Understand the reported issue, the code path behind it, and what was actually validated.
1
Open the finding
In the repository, select Vulnerabilities and open a finding. Start with the report, severity, CVSS score, affected code, and scan version.
2
Follow the code path
Inspect the Source and Sink and the Data flow when available. Use the trace to understand how the input reaches the reported operation and which controls were considered.
3
Check the evidence status
Read Validation and its recorded result. Inspect PoC and Patch when those sections are present. Keep reproduced behavior separate from impact inferred from code.
Model confidence is an assessment, not a reproduced result. Evidence sections can be absent, and a scan with no findings is not a guarantee of safety.
You’re done when you can explain the finding, its reviewed revision, and the limits of its supporting evidence.
Record your team's decision, ask for more context, and hand off evidence that an engineer can review.
1
Record the decision
Use the finding's status control to choose Pending, Validating, Accepted, Won't Fix, or Resolved. Keep the decision consistent with the evidence and your team's review process.
2
Keep context with the finding
Use Notes for team discussion and decisions. Use Scan guidance for feedback that should inform future scans. In Triager, mention a finding with @ to ask a question about it.
3
Share a reviewable report
Use the export menu for Preview report, Print view, Download .md, or Copy markdown. Use Copy fix prompt or Download .patch when available. The browser's print dialog can save a PDF.
Triage status records the team's workflow. Read the validation result separately to understand what Winfunc checked.
You’re done when the finding has a clear team decision and enough context for the next reviewer.
Prepare a patch pull request, let your engineers review it, and check the updated code after it lands.
1
Request an autofix
Open the finding and select Autofix. If it is disabled, ask a repository administrator to enable autofix. Follow the job status, then select View PR when a pull request is available.
2
Review and test the change
In GitHub, review the diff and run your team's tests. Your engineers decide whether to approve and merge the patch.
3
Validate after the fix lands
Once the fix reaches the default branch, select Validate on the finding. In Validate patch, select Start validation. Confirm the validated commit and read the verdict, remaining risks, and prior runs.
Finding-level validation checks the default branch. A valid patch verdict marks the finding Resolved. To check fixes on an open pull request, use the PR review workflow.
You’re done when the patch has been reviewed and the finding has a validation result tied to the updated code.
Review eligible changes before merge and re-check the final fix on the pull request's latest commit.
1
Check that PR reviews are enabled
Open PR reviews in the repository. This section appears when PR security reviews are enabled. Review the selection criteria and the daily and monthly allowance.
2
Read the initial review
Eligible pull requests are reviewed automatically through the connected GitHub App. Open the review and check its head commit and reported findings.
3
Push final fixes, then re-review
After the fixes are complete and pushed to the pull request, select Re-review fixes. Read the new verdict against the latest head commit.
The current allowance includes one initial review and one re-review per selected PR. A clean review means no findings were reported in that review's scope.
You’re done when you have a security review for the change and a verdict on the final fix before merge.
Use a hypothesis scan when you want to investigate one application-specific guarantee.
1
Write a bounded question
Open Hypothesis scans and select New hypothesis scan. In Hypothesis, describe the expected control and the part of the application to review. For example: does the export workflow enforce the current user's organization?
2
Review and start
Check the displayed branch, available allowance, and credit reservation, then select Run hypothesis scan.
3
Read the investigation
Follow Active scan and return to Recent scans when it completes. Review the resulting findings and the evidence for and against your question.
Hypothesis scans must be enabled for your organization and repository. Allowance depends on your plan or engagement.
You’re done when your question has a recorded investigation and findings to review within its stated scope.
Give reviewers repository access, send useful alerts to Slack, and read scan results from an MCP client.
1
Grant repository access
As a repository administrator, open Settings, then Team access. Enter the exact GitHub username in Grant access, confirm the matched user, then select Add. Repository access is all-or-nothing; removing access revokes it immediately.
2
Connect Slack alerts
In repository Settings, open Slack alerts. Add the Incoming webhook URL, enable Send alerts after scans, select Send test, and Save. Keep the webhook private.
3
Create an MCP key
In global Settings, open MCP access and select Create key. Follow the panel's client setup instructions and store the key privately. This connection provides read-only access to scans and findings. Delete the key to revoke access.
Slack sends one summary after a completed scan when critical or high code findings are present. Contact the team to discuss enterprise identity, model, and hosting configuration.
You’re done when your reviewers have the right repository access and your connected tools can receive or read results.
