Write-up
Background
A SaaS team is adding a button that sends a test webhook. A webhook is a message the application sends to another service. The feature looks small: select an integration, enter an address, and click Test.
This is an illustrative workflow, not a reported customer engagement. The figures and testimonial describe the example, not measured results or a real customer quote.
The developer and security reviewer want to answer the same question before merge: who can make this request, and where can it go?
The Missing Controls
The server accepts an integration ID from a signed-in user. It checks that the user belongs to a workspace, but not that the selected integration belongs to that workspace. Knowing another workspace's ID is enough to reach its webhook test action.
The address check has a different gap. It accepts a well-formed web address without checking whether that address leads to a private service. That creates a possible server-side request forgery, or SSRF: making the server contact something the user cannot reach directly.
A Threat Model in the Pull Request
Bravos uses GuardLink to follow the request through the code. GuardLink writes its threat model into the repository, so its annotations appear in the pull request alongside the feature.
The map connects the user-supplied integration ID to the integration lookup and the user-supplied URL to the outbound request. It marks where an ownership check is missing and where the address check may not cover the destination.
GuardLink has not proved an exploit. It has shown both reviewers exactly where to look. The developer can explain the intended behavior at the same code location where security questions the control.
Proving the Problem on a Running Build
Bravos builds a code graph and prioritizes these paths because they reach another workspace's action and an outbound network request. It then drives Cert-X-Gen against an isolated running copy of the proposed change.
Using authenticated test accounts from separate workspaces, Cert-X-Gen observes one account trigger the other workspace's integration. In a separate probe, the application fetches a private test service and returns its harmless marker.
Those behaviors confirm the two issues in this example. A suspicious code path alone would not.
Fixing the Same Paths Together
The developer scopes the integration lookup to the authenticated workspace and checks the user's permission before sending a webhook. Guessing a foreign integration ID no longer reaches the action.
For outbound requests, the team restricts destinations to the addresses the feature actually needs. The control checks the resolved destination and any redirect before making the next request, rather than trusting the spelling of the URL.
The team discusses that choice in the pull request. Allowing arbitrary external destinations is more flexible, but needs broader controls and testing. The trade-off is explicit, not silently decided by a tool.
Proving the Fix, Not Just Reading It
Cert-X-Gen repeats the probes against the updated running build. The foreign-workspace request is rejected before the webhook action. The private-service probe is blocked without fetching the marker. An authorized test to an allowed destination still succeeds.
The reviewers keep the request details and observed responses with the pull request. These results show that the tested paths are closed; they are not a promise that every possible attack has been ruled out.
Results
In this example, both issues are fixed before merge. There is no separate security document for the developer to reconcile later.
- One map: GuardLink's threat model sits beside the code under review.
- One conversation: developers and security discuss the same missing controls.
- Observed proof: Cert-X-Gen demonstrates the failure before the fix and the blocked path afterward.
- An orchestrated loop: Bravos drives the analysis and testing, and reports only proven findings.
Conclusion
Real-time collaboration does not have to mean another meeting. It can mean seeing the same path, changing the same control, and checking the same evidence before the code ships.
GuardLink and Cert-X-Gen are open source. A team can run them directly. Bravos is the product that orchestrates them end to end: it knows where to look, what to test, and when the evidence is strong enough to report a finding.