Write-up
Background
A healthcare software team is adding bulk attachment imports. Staff upload an archive, and a background worker unpacks it into a staging folder before processing the files.
A platform developer and a security engineer review the change together. The application handles sensitive information, but this assessment uses only synthetic attachments in an isolated local build.
This is an illustrative workflow, not a reported customer engagement or breach. The figures and testimonial describe the example, not measured results or a real customer quote.
Following the Data Beyond the Upload
The upload handler checks the archive's filename. That sounds reassuring, but the worker later uses a different set of names: the filenames stored inside the archive.
An archive can contain an entry whose name asks the worker to write outside its staging folder. This is path traversal: using a file path to cross a directory boundary the application should enforce.
The question is not just whether an upload is allowed. It is whether every file extracted from that upload stays where it belongs.
GuardLink Puts the Whole Path in the PR
Bravos uses GuardLink to follow the input from the upload handler, through the queued job, to the worker's file write. GuardLink writes the threat model into the repository, so both reviewers can see it in the pull request.
The annotation identifies the relevant gap: an archive member's name reaches a sensitive write without a control that ensures the destination stays inside the staging folder.
This is a map of a possible failure, not a confirmed exploit. It gives the developer and security engineer a shared place to discuss the intended boundary and the code that must enforce it.
The Running App Establishes the Issue
Bravos ranks the path by its reach to a filesystem write, then drives Cert-X-Gen against the running build. The test submits an archive through the actual upload flow and lets the background worker process it.
The archive contains a harmless marker file with a path that leads outside the staging folder. The worker writes that marker to the unintended test location.
That observed write confirms the issue in this example. Reading a suspicious extraction function would not be enough on its own.
A Plausible Patch Is Still Not Proof
The developer's first change tightens the uploaded archive's filename check. The security engineer uses GuardLink's map to point out that the dangerous name comes from inside the archive, later in the worker.
Cert-X-Gen repeats the test on the changed build. The out-of-directory marker still appears. The issue remains open.
This is what “cheap is untrue” means in practice. A quick answer is not worth much if it claims a state the tools have not established. A merged-looking patch, a reassuring annotation, or a test request being accepted is not proof that the boundary now holds.
Fixing the Boundary That Matters
The pair moves the control to extraction. The worker checks each member's final destination before writing. It rejects paths outside the staging root and does not allow archive entries to introduce symbolic links that could redirect later writes.
A symbolic link is a filesystem pointer to another location. Rejecting unsafe names alone is not enough if the extraction process can still follow such a pointer out of the intended folder.
The team makes the product trade-off explicit: reject archives with unsafe entries, or invest in a more isolated extraction design with broader format support. In this example, they choose strict rejection. Bravos does not silently choose that policy for them.
Closing the Tested Path Together
Cert-X-Gen tests the updated running application through the same upload and worker flow. The traversal archive is rejected, and the outside marker is not written. The test waits for processing to finish; an upload response alone does not establish what the worker did.
A second probe checks the link-based route. It is blocked too. A normal archive still imports into the staging folder successfully.
The pair records the evidence with the change and updates the in-code threat model to reflect the control. The tested paths are now closed. That conclusion is limited to the behavior and conditions actually checked, not every possible archive format or deployment.
Conclusion
Shift-left means finding and discussing the risk while the code is changing, not handing over a warning after release. Continuous collaboration means the developer's fix and the security engineer's evidence meet in the same review.
GuardLink supplies the shared map. Cert-X-Gen proves what the running application does. Both are open source. Bravos is the product that orchestrates their work and reports only proven findings.
The important outcome is not a green label. It is a boundary that both sides can explain, and a running-app test that shows it holds.