Resources
Finding → Fix Spec → PR
Intent-preserving remediation is a three-step workflow: capture a security finding, write a fix spec that states what must not change, then open a pull request that implements only that spec. The goal is a shipped fix developers will actually merge.
Most AppSec programs are strong at discovery and weak at change. Scanners accumulate CVEs; agents and MCP servers accumulate over-privileged tools. UnitOne is built around a reviewable path from finding to merge, for application code, CI/CD, AI agents, and MCP servers.
The workflow
- 1
Finding: name the issue in context
Record the vulnerability or unsafe pattern with the repository, workflow, agent, or MCP server where it lives. Include the sink or tool, the reachable path, and the business function it sits in. A CVE ID without context is not enough to preserve intent.
- 2
Fix spec: constrain the change
Write what will change and what must stay true. Example constraints: public API shape, error codes, timeout behavior, which tool an agent may still call, and which identities keep access. Call out tests to run and files that are out of scope so the patch cannot 'clean up' unrelated code.
- 3
Implement the smallest behavior-preserving patch
Prefer dependency bumps with compatibility checks, config tightening, or local guardrails over refactors. For agents, reduce tool scope or add policy rather than rewriting the workflow. For MCP servers, disable or wrap a dangerous tool instead of forking the protocol.
- 4
PR: make the fix reviewable
Open a pull request that cites the finding and the spec, shows a focused diff, and runs existing CI. Reviewers should be able to answer: does this remove the issue, and does it still do what the code or agent was for? No silent writes to main, no undocumented binary patches.
- 5
Verify and close the loop
Re-scan the same path, keep the advisory or ticket linked, and record the merge SHA. If a CRA or customer clock is running, the PR plus spec is the evidence that a corrective measure exists — not a slide that says 'remediated.'
Frequently asked questions
- What is intent-preserving remediation?
- Intent-preserving remediation is the practice of fixing a security issue while keeping the behavior developers meant to ship. The output is not a speculative rewrite; it is a constrained change, explained in a fix spec, and proposed as a pull request that existing review and CI still gate.
- How is a fix spec different from a scanner finding?
- A finding says what is wrong. A fix spec says what will change, what must not change, which tests prove it, and which files or configs are in scope. Without a spec, automated patches guess — and that is when business logic breaks and developers revert the change.
- Why land remediations as pull requests?
- PRs keep security work inside the same approval, CI, and rollback path as product work. They create a reviewable diff, a discussion thread, and an audit trail. Direct-to-main hotfixes and opaque auto-merges are how intent gets lost.
- Does this workflow apply to AI agents and MCP servers?
- Yes. Agent policies, tool allow-lists, and MCP server configs encode intent just as application code does. A finding against an over-privileged tool should become a spec ('this workflow may read tickets, not delete them') and a PR against the config or server — not a silent runtime mutation.
Remediation is a scoped POC
Request a remediation POC for Finding → Fix Spec → PR work. Gateway self-serve is separate — start free if you need runtime security and CRA-ready evidence first.