Reassess your attack surface whenever a release adds a new technology, upload path, API type, or changes authentication, authorization, session handling, encryption, secrets or validation. A new field that follows an existing pattern adds little. Use a short checklist in pull requests so the decision is made every time.
What OWASP says
OWASP's guidance says to re-assess as the system changes by asking what has changed, what is being done differently, and what holes may have opened. It says adding a page or field that follows an existing pattern adds little new risk, while a new technology, a new upload path or a new API type calls for a fuller risk assessment. It lists changes to authentication, session management, authorization, roles, encryption, secrets, validation or core architecture as needing review. It also ties the work to threat modeling: surface changes should trigger threat modeling.
A pull request checklist
Add these questions to your template:
- Does this add a new way for data to enter or leave the system?
- Does it add a new external integration or dependency?
- Does it change who can do what?
- Does it touch secrets, keys or encryption?
- Does it expose anything to unauthenticated users?
- Does it add a new technology the team has not run before?
If every answer is no, merge as normal. If any is yes, request a short review.
Two sizes of review
Light review (15 minutes). The author and a reviewer walk through the questions, note the new entry points, and confirm authentication and logging.
Full review (hours). Used for new upload paths, new API types, new authentication flows or changes in architecture. Include threat modeling: who might attack, what they want, and how this change helps them.
Keep the map current
Maintain a living attack surface note per service: entry points, data stored, who can reach it. Update it as part of the pull request that changes it. A stale map is worse than none because it gives false confidence.
Dependencies count too
A new library is a new piece of code you did not write, running with your permissions. Treat a new dependency as a change worth a glance: what does it do, who maintains it, and does it add network or file access?
Reduce while you add
OWASP's advice for lowering the surface includes removing unused features and interfaces, limiting user roles, minimising stored sensitive data, and favouring deny-by-default access, which is easier to verify than allow-by-default. When you add something, ask whether you can retire something old at the same time.
For teams with fast release cycles, automate the first filter. A pull request that touches authentication code, route definitions or dependency manifests can be labelled automatically so a reviewer sees the prompt.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, reachability analysis, and policies and gates that can enforce rules on pull requests. These help with the dependency questions in the checklist.
Quick check
Does every pull request need a review?
No. Only changes that alter entry points, trust, secrets or technology. A checklist makes that call fast.
Sources
Last reviewed: 19 October 2026.
