Run Arbor like a security gate, not a toy reviewer.
This guide covers the AppSec workflow: installing the GitHub App, reading evidence packets, tuning policy, wiring branch protection, and handling unknown graph evidence honestly.
From install to first PR evidence.
Install the app
Install Arbor on the repositories you want monitored. Arbor needs code and PR read access, plus permission to post comments and commit statuses.
Open a PR
When you open a PR, Arbor analyzes the changed code and checks which security-sensitive operations it can reach. The analysis runs automatically in under 15 seconds.
Read the evidence
The PR comment shows reachable call paths, sensitive surfaces, required proof, and limitations. It should explain why the verdict exists.
Turn on enforcement
Start in monitor mode, move to review-required mode, then block only when your team trusts the policy and branch protection is wired.
Recommended launch sequence.
Start by observing, not blocking. A security gate earns trust when reviewers can see that the findings match their own mental model.
What Arbor stores and posts.
Every PR analysis normalizes into an evidence packet. The UI can render partial packets; missing evidence should become a visible limitation.
{
"verdict": "review_required",
"confidence": 0.82,
"summary": "Payment path reachable from POST /checkout",
"changedSecuritySurfaces": ["src/billing/charge.ts"],
"reachableEntrypoints": ["POST /checkout"],
"sensitiveCapabilities": ["payment", "db"],
"callPaths": [
{
"entrypoint": "POST /checkout",
"sink": "db.execute",
"risk": "critical",
"nodes": [
"route.ts:POST",
"validateRequest",
"processCharge",
"db.execute"
]
}
],
"requiredProof": [
"Security owner approval",
"Checkout integration test in staging",
"Manual review of dynamic SQL builder path"
],
"limitations": [
"Dynamic import in billing adapter was not fully resolved"
]
}Choose the merge behavior deliberately.
Make the GitHub status enforceable.
1. Enable Arbor policy for the repo in the dashboard.
2. In GitHub, open Settings -> Branches -> Branch protection rules.
3. Add arbor/security as a required status check.
4. Start with Review Required mode. Move to Block mode only after one week of clean signal.
Teach Arbor your local architecture.
The default classifier looks for common auth, payment, secrets, DB, network, filesystem, shell, and validation patterns. Use repo config to make the graph match your actual system.
# .arbor/security.yml
security:
enabled: true
mode: review
block_critical_reachable: true
require_security_owner: true
require_integration_tests: true
treat_unknown_as_review: true
sensitive_paths:
- pattern: "src/auth/**"
category: auth
- pattern: "src/billing/**"
category: payment
- pattern: "src/db/**"
category: database
- pattern: "src/workers/**"
category: network
sensitive_symbols:
- verify_admin
- process_payment
- execute_raw_sql
- decrypt_token
owner_handles:
- "@security-team"
- "@payments-owner"
ignore:
- "test/**"
- "vendor/**"
- "**/*.test.ts"
- "**/*.generated.*"What Arbor should not overclaim.
- Arbor is reachability and structural evidence. It is not a claim that every vulnerability has been found.
- Dynamic imports, reflection, service locators, generated code, and runtime dependency injection can create unknown edges.
- Macro-heavy, template-heavy, or generated source may parse partially depending on the language grammar.
- A reachable path is not the same as tainted dataflow. Treat it as security review prioritization and merge proof.
- If Arbor cannot resolve enough evidence, the correct behavior is review-required, not a silent pass.
Common launch issues.
Current integration surface.
Arbor is currently driven by GitHub App webhooks and authenticated dashboard proxy routes. Public API access is planned for teams that want to query reachability from CI, security tooling, and internal developer platforms.
POST /reachabilitySubmit a repo, commit, and security sink. Receive reachable status, call path, limitations, and suggested proof.