When a pull request adds a new integration, check six things: what crosses the trust boundary in each direction, how the connection is authenticated, where the credentials live, how the code behaves when the other side fails or lies, what new dependencies arrive, and who owns the integration. Each one is a short question.
Why integrations deserve extra attention
OWASP's Secure Code Review Cheat Sheet lists steps for diff-based review that apply directly: identify new attack vectors, verify security at modified trust boundaries, and check new integrations. An integration is a new trust boundary by definition. Data now flows to, and from, something your team does not control.
Define the terms
- Trust boundary: the line where data moves between zones with different levels of trust. OWASP says to validate input and encode output at these boundaries.
- Outbound data: what you send. It can leak personal data, secrets or internal details.
- Inbound data: what you receive. It must be treated as untrusted, even from a partner.
The six checks
1. What crosses, and in which direction?
List the fields sent out and the fields read back. Ask whether each outbound field is necessary. Sending the whole user record when the partner needs an email address is a common overshare.
2. How is the connection authenticated?
Is the transport encrypted? Is the partner authenticated to you, and you to them? For callbacks the other service sends to you, how do you know a request is genuine? An unauthenticated callback endpoint is a public door.
3. Where do credentials live?
OWASP's checklist for configuration says there should be no hardcoded secrets and that secrets need proper storage and rotation. In the diff, look for keys in source, in config files that are committed, or in test fixtures. Ask who can rotate the credential without a deploy.
4. How does it fail?
- If the partner is slow, does your request time out or hang?
- If the partner returns an error, is the error text shown to users or logged with sensitive data?
- If the partner returns unexpected data, is it validated before use?
- Does a retry loop risk duplicating an action, such as a payment?
5. What new dependencies arrived?
Integrations often come with a client library. Check the lockfile diff, the library's maintenance status and whether you could call the interface directly with a few lines of code. Each added package is also a supply chain decision.
6. Who owns it?
Name an owner. An integration without one is the first to be forgotten when the partner changes its interface or discloses an issue.
A short template for the description
Integration: payments webhook receiver
Sends: nothing. Receives: order id, status, amount.
Auth: signature check on every request, secret in the vault.
Failure: bad signature returns 401; unknown order is logged, not retried.
New dependency: none.
Owner: payments team.
If an author can fill this in quickly, the design was thought through. If they cannot, it is better to learn that in review.
Reviewer red flags
- A new outbound call to an address the user supplies.
- A broad permission or scope requested "to be safe."
- Credentials passed in a URL, where they are likely to appear in logs.
- A client library added for one call.
- No test that shows what happens when the partner returns garbage.
Try it yourself
Open the demo to see how a dependency inventory lists each package and its source. Use it to picture what the lockfile diff for a new integration adds.
Click through it at your own pace, or open it full screen.
Safeguard's dependency scanning and SBOM generation show what a client library brings with it, and policies can flag a new package at pull request time.
Quick check
Is a partner's data trustworthy because we have a contract?
No. A contract allocates liability. It does not stop malformed or malicious data from reaching your code, so validate inbound data anyway.
Do internal integrations need the same checks?
Yes, though they may be quicker to answer. An internal service can be compromised or simply wrong.
Sources
Last reviewed: 19 October 2026.
