Start with the original.
Establish whether the reported issue can be reproduced. An unconfirmed finding stays unconfirmed; it doesn’t quietly become a false positive.
SECURITY REMEDIATION, REIMAGINED
Security findings.
Meet their fix.
The distance between a security report and a resolved issue is too long. We’re building Heimdall to close it—with targeted patches and evidence you can review.
MVP in development. Built and tested with owned demo applications.
THE REMEDIATION LOOPIllustration
SECURITY REPORTAn issue worth fixing.
A targeted changePATCH
function canAccess(user, document) {
− return user.isAuthenticated;
+ return user.isAuthenticated
+ && document.ownerId === user.id;
} The fix is a proposal. The checks are the gate.
A pull request. With the proof.
Your team reviews, merges and releases.
Illustrative flow and code. Not a live run or verification result.
BUILT FOR THE PEOPLE WHO CLOSE THE FINDINGS
AppSec teams/Engineering teams/Pentest partners
THE GAP WE’RE CLOSING
Finding the issue
is only the beginning.
Reports tell you what’s wrong. Engineering still has to reproduce it, understand the application, write a fix and prove the fix holds.
Heimdall is being built to carry that work forward in one accountable workflow. Less context lost between teams. A clearer path from finding to resolution.
Follow the remediation loopFROM REPORT TO REVIEW
One continuous workflow.
Clear checkpoints.
Our target: after authorized setup and report upload, Heimdall carries the work to a reviewable PR—and pauses when evidence or permission is missing.
04 / VERIFY THE CHANGE
A patch isn’t proof.
Run the same frozen security tests against the patch. Check legitimate behavior and declared contracts. Bind the evidence to the exact code and test versions.
A crash, timeout, missing route or authentication failure must never count as a verified fix.
VERIFICATION PLANIllustrative
ORIGINAL REVISIONDemonstrate the issueEstablish the baseline
PATCHED REVISIONRerun frozen checksCompare supported behavior
Security test versionFrozen before the fix
Coverage gapsNamed, never hidden
Product workflow overview. Interactive examples illustrate the design; they do not execute code or display live customer results.
THE ENGINE UNDERNEATH
AI proposes.
Evidence decides.
Generating code is one part of remediation. Knowing what that change actually proves is the harder part.
Freeze the checks first.
Validate the baseline and freeze the security and behavior checks before writing the patch. The fix must meet the tests—not reshape them.
Show what was verified.
Connect observations to exact revisions and test versions. Keep verification, PR status and release decisions separate, with limitations in view.
Automation up to the handoff. Human control at release.
Heimdall never automatically merges a patch or deploys your application.
BEYOND THE CHANGED FILEArchitecture direction
SHARED SERVICEWorkflow service
Customer portalOperations appPartner API
Affected consumers
Supported checks + visible gaps
Illustrative topology. Not a claim of complete dependency discovery.
THINK BEYOND THE DIFF
A small change.
A wider responsibility.
A shared service can support several products. Fixing one reported path is not enough to assume every consumer is safe.
Our architecture is designed to identify affected consumers, verify supported behavior and show coverage gaps. Missing coverage must affect readiness.
Initial scope: one service, one repository and declared contracts.
THE HANDOFF, MADE ACCOUNTABLE
One report.
Every finding accounted for.
The intended output goes beyond a patch: a report-level closure package showing each finding’s status, evidence, limitations and next action.
CLOSURE OVERVIEWIllustrative statuses
Verified within scopePatch, evidence and review requirements
For review ↗Partial verificationCandidate retained; required coverage missing
Not release-readyUnconfirmedObservations and a retest path
Needs evidenceUnsupportedTracked with a reason and next action
Tracked Partial progress stays useful. Missing proof stays visible.
A FEW THINGS, UP FRONT
Good questions.
Honest answers.
Where is Heimdall today?
Heimdall is an MVP in development. We have built a remediation workspace and verification engine, with controlled validation against owned demo applications. Customer-code execution is not yet enabled. Contact us to see the current build and discuss future pilot requirements.
Does Heimdall merge or deploy changes?
No. The target workflow prepares a pull request with verification evidence and named gaps. Your team reviews the changes, accepts the evidence and limitations, merges the PR and controls the release.
What makes verification meaningful?
The issue must be demonstrated against the original code. Legitimate-behavior checks must pass on the original before judging the patch. Validated tests are frozen before patching and run unchanged against the candidate. A crash, timeout, missing route or authentication error cannot count as a verified fix.
What if a finding can’t be fixed or confirmed?
It stays visible with its status, observations, limitations and next action. Unconfirmed is separate from false positive. Unsupported findings are tracked, and missing evidence or authorization pauses automation. A retest package can support follow-up with the original pentester.
LET’S CLOSE THE LOOP
Security work deserves
a clear finish line.
Building an AppSec team, running pentests, or investing in what comes next? Let’s talk about getting from findings to fixes.