FINDING → PROPOSAL → HUMAN REVIEW
A finding gives developers a problem to investigate. A patch suggestion gives them a concrete change to evaluate. Keep the evidence, remediation guidance, and available diff together without bypassing your development process.
ARES DOES NOT PATCH YOUR SYSTEM
The output is a downloadable proposal. People review the logic, run tests, approve the change, and apply it through their normal development and release workflow.
PATCH CAPABILITIES
Connect the appropriate source, request a suggestion, and give engineering the context to evaluate it. Availability of a per-finding action is not a promise that every vulnerability has a usable patch.
TWO SOURCES OF PATCH SUGGESTIONS
Do not confuse a patch drafted during source analysis with an on-demand proposal for a linked finding.
Workflow
Context available
Developer review required
Repository analysis
The source-analysis assessment reads repository files and can produce an optional suggested patch. Selected findings may receive a bounded deeper pass.
Check the proposed change against the current codebase and required application behavior.
On-demand generation
Uses finding details and the linked repository’s identity. It does not currently fetch repository files during generation.
Verify file paths, surrounding code, and whether the diff applies before treating it as implementation-ready.
A linked repository enables the on-demand workflow, but does not mean its files were read in that generation step. Generated suggestions are not automatically compiled, applied, or tested.
REPOSITORY CONNECTION
For an API, web, or mobile target, connect the relevant repository and associate it as the target’s source. A repository assessed directly uses its own connected source context.
Situation
How to prepare
Runtime finding
Link the application target to the repository that contains the relevant change.
Existing eligible report
Connect and link source after the assessment to enable the per-finding patch workflow.
Repository finding
Review source locations, code evidence, and any suggestion produced during source analysis.
Separate client, backend, and infrastructure repositories
Select the relevant repository. Do not assume automatic multi-repository fix composition.
HUMAN-IN-THE-LOOP WORKFLOW
This responsibility map describes the workflow. It does not represent automatic approval, testing, or release.
Stage
Ares provides
Your team controls
Investigate
Finding details, supporting evidence, and remediation guidance.
The assessment scope and interpretation of the issue.
Propose
A patch suggestion when generation produces one, available as a diff.
Whether the paths, logic, and proposed scope fit the codebase.
Implement
A downloadable starting point.
Adaptation, code review, application, testing, and deployment.
Reassess
A new eligible assessment through normal launch checks.
Correct build and access, review of coverage, and the remediation decision.
01 / PROPOSED
A nonempty diff is available. It has not been proven to apply or fix the issue.
02 / APPROVED & DEPLOYED
Engineering has reviewed, tested, and released the chosen change through its own process.
03 / REASSESSED
A later assessment provides evidence about whether the original behavior remains reproducible.
REMEDIATION IS BIGGER THAN A DIFF
A focused code change can be useful for a supported code-level issue. Other exposures need credential, configuration, operational, or architectural action.
Issue type
What engineering should evaluate
Ownership or authorization weakness
Whether checks enforce the intended user’s access at the relevant boundary.
Unsafe query input handling
Whether the proposed change handles input appropriately without breaking required behavior.
Leaked credential
Rotation and exposure handling may be required in addition to removing a value from source.
Network or architectural exposure
Configuration changes or coordinated work across systems may be needed beyond a local patch.
These are illustrative review considerations, not generated patch examples or guarantees of support for every finding.
REASSESSMENT CHECKS
A proposed patch, an approved code change, and validated remediation are distinct milestones. Reassess only after engineering has tested and deployed the chosen fix.
For mobile re-runs, confirm the selected build contains the fix. For authenticated applications, confirm the new assessment reaches the affected functionality. Changed reach, access, or configuration can affect the conclusion.
FREQUENTLY ASKED QUESTIONS
Patch generation supports engineering judgment. It does not replace it.
TALK TO ASSAIL
Bring vulnerability evidence, remediation guidance, and proposed changes into the same conversation. Your developers stay in control of the fix.
Your environment. Your objectives. A mission built around both.
