Attack Surface Mapping
Ask the Tiffin team "how could someone get in?" and they list the login page and the API. They forget the old admin panel on port 8081, the webhook, the staging site with test data, and the pipeline that deploys whatever lands on main. You cannot defend a door you have not noticed. Mapping the attack surface is how you notice.
The rule
Every way in, every way out, everyone who can change it.
The attack surface is the sum of every point where someone could send data into a system, pull data out of it, or change how it behaves. Map three groups:
- Ways in: web pages, API endpoints, webhooks, file uploads, admin panels, open network ports, message queues.
- Ways out: responses, exports, logs shipped elsewhere, backups, emails, third-party analytics.
- Who can change it: people with production access, the source repository, the pipeline, dependencies, base images, cloud consoles.
For DevSecOps, the last group matters as much as the first. The delivery pipeline is part of the attack surface: whoever can influence the build can influence production.
Tiffin pipeline surface
- pull requests (incl. forks) - third-party pipeline plugins
- package registries (PyPI, npm) - base images
- build runners - container registry
- pipeline config file - deploy credentialsOnce mapped, each item gets one of three decisions:
- Remove it if nobody needs it (the old admin panel, an unused plugin).
- Restrict it: authentication, least privilege, network rules, pinning, approvals.
- Monitor it: logging and alerts where you must keep it open.
The surface changes with every feature, so the map is a living document, reviewed when the architecture changes.
The shortcut
Draw the system as boxes and arrows, then trace every arrow that crosses a trust boundary: from the internet, from a partner, from a pull request. Each crossing is an entry on the map.
Ways in
Public site,
/api/*,/webhooks/payment, and a forgotten admin panel on port 8081.
Drills
Answer fast — trust the rule.
Which of these is part of Tiffin's attack surface?
An admin panel from an old version is still reachable but unused. What is the best decision?
Why do pull requests from outside contributors belong on the pipeline's attack surface?
When should the attack surface map be updated?
Remember
- Every way in, every way out, everyone who can change it.
- Trace every arrow that crosses a trust boundary; the pipeline counts.
- Remove what's unused, restrict what's needed, monitor what stays open.