Security → Attack surface lists every way into each project's code: HTTP routes, webhooks, queue consumers and command-line commands. The red team finds them by reading the code (see Blue team and red team). You say who can reach each one, and that decides what the security audit reads first.
How the map is made
Coroid maps each connected project by reading its default branch, without an AI model. It maps once a week, and on request: Map now on the tab, or Map the attack surface in a project's Scan now menu on the Overview. Mapping is always on. Its runner time counts as agent hours, like any other work.
The same read drafts the project's threat model. Trust boundaries, sensitive data and notes stay there; entry points live here.
Exposure
Each entry point has an exposure: who can reach it.
| Exposure | Means |
|---|---|
| Internet | Anyone can reach it |
| Signed-in users | From outside, after sign-in |
| Internal | Only your other services |
| Admin only | Only administrators |
| Not deployed | In the code, not running |
| Not set | Nobody said yet. Treated as internet-facing |
The table also shows each entry point's sign-in check as the code shows it (sign-in, API key, service token, webhook signature, or none found), its findings, and when the audit last read it. Filters pick out, for example, entry points that write without sign-in, or those new this week.
Owners and admins set exposure, one entry point at a time or many at once.
Suggestions from your deployment config
When a project's repository holds its deployment config (Kubernetes Ingress, Gateway API routes or Helm values in their usual shapes), Coroid reads which hosts route to which service. From that it suggests an exposure for each entry point that is not set yet: Internet for a routed service that needs no sign-in (or only an API key or a webhook signature), Signed-in users for one that needs sign-in, and Internal for a service no route reaches. It reads the files as text; nothing is rendered or run. An owner or admin applies a suggestion or dismisses it, and can undo what they applied. A suggestion never changes an exposure a person set, and a dismissed one is not made again.
Hosts lists where the project runs, as the config says, with the file each route was found in.
Steering the audit
The audit reads internet-facing and not-set entry points first. You can steer it further for each entry point:
- Audit first: read before anything else;
- Normal;
- Out of scope: not read, with a reason you give.
Changes to the surface lists the entry points each map added or removed. Decisions about an entry point that left the code are kept, in case it comes back.
The guard on new entry points
The blue team's guard checks every pull request for entry points it adds without a sign-in check. Settle each one on the tab: say who can reach it, or put it out of scope with a reason.
Its setting is New entry points in Security → Settings, for the organization or each project:
| Mode | A pull request that adds an unsettled entry point |
|---|---|
| Off | Is not checked |
| Report | Is reported; the Coroid Security check stays neutral |
| Block | Fails the Coroid Security check until each one is settled |
Block is available once Coroid has switched it on after its readiness check; until then the setting says Block, not available here, and the guard reports.
Its rules:
- A pull request adds an entry point without a sign-in check;
- Treat "Not set" as internet-facing;
- Suggest exposure from deployment config.
Pull requests on the tab lists each checked pull request: passed, reported, blocked until settled, or not checked. A pull request too large to check within the time limit reads not checked: too large, never as passed. A changed file the scan could not read is neutral under Report and fails under Block. Owners and admins can run a pull request's check again from there (Check again), for example after settling its entry points, instead of re-running it in GitHub.