When
After M1–M8 are fully built and we have the big-picture view of kshield in action. Not before.
Current state
remediation.py already exists and is wired into the single-file /api/v1/scan path, but it only has real logic for one finding type: Broken Access Control. The generated patch is hardcoded and wrong in most cases — it always inserts @app.get('/unverified-access-fix', dependencies=[Depends(AuthenticationGuard)]) regardless of the route's actual HTTP method or path, and AuthenticationGuard doesn't exist anywhere in the codebase. Every other finding type just returns "Review your code logic manually." with no patch./api/v1/apply-patch (in actions.py) already applies that patch directly to disk via git apply. Given the patch above is templated/wrong, this endpoint currently ships a broken auto-apply feature for its one supported case.- The new repo-wide
/api/v1/audit path (M1–M6) does not call remediation at all — none of its findings carry a remediation field.
Proposed direction — all three tiers, scoped by finding type
| Tier |
What |
Candidate finding types |
| Explain only |
Clear description of why + what a correct fix looks like, no generated code |
AI Structural Hallucination, Syntax Violation |
| Suggest a diff, never auto-apply |
Patch shown for human review, not applied automatically |
Broken Access Control, Possible Typosquat, Undeclared Dependency |
| Auto-apply candidate |
Only where mechanically unambiguous |
TBD — likely none of the current finding types qualify without a human in the loop |
A concrete improvement available once we get here
For Broken Access Control specifically: instead of inserting a fake guard, use graph_builder.py's route.guard_names to find a route elsewhere in the same repo that already has a real guard, and suggest applying that same guard with the flagged route's actual method/path. Contextually correct instead of templated.
Decisions to make when this is picked up
- Fix or retire the existing
/apply-patch disk-write endpoint — it currently ships a broken patch for its only supported case.
- Whether the audit path's findings need remediation output in the same milestone, or as a follow-up.
Filed by request — implementation deliberately deferred until all milestones are complete.
When
After M1–M8 are fully built and we have the big-picture view of kshield in action. Not before.
Current state
remediation.pyalready exists and is wired into the single-file/api/v1/scanpath, but it only has real logic for one finding type: Broken Access Control. The generated patch is hardcoded and wrong in most cases — it always inserts@app.get('/unverified-access-fix', dependencies=[Depends(AuthenticationGuard)])regardless of the route's actual HTTP method or path, andAuthenticationGuarddoesn't exist anywhere in the codebase. Every other finding type just returns"Review your code logic manually."with no patch./api/v1/apply-patch(inactions.py) already applies that patch directly to disk viagit apply. Given the patch above is templated/wrong, this endpoint currently ships a broken auto-apply feature for its one supported case./api/v1/auditpath (M1–M6) does not call remediation at all — none of its findings carry aremediationfield.Proposed direction — all three tiers, scoped by finding type
A concrete improvement available once we get here
For Broken Access Control specifically: instead of inserting a fake guard, use
graph_builder.py'sroute.guard_namesto find a route elsewhere in the same repo that already has a real guard, and suggest applying that same guard with the flagged route's actual method/path. Contextually correct instead of templated.Decisions to make when this is picked up
/apply-patchdisk-write endpoint — it currently ships a broken patch for its only supported case.Filed by request — implementation deliberately deferred until all milestones are complete.