Chapter 15 — Integration and dependencies
Lesson map
Lesson 15 published. Map, example, EX057.
flowchart TD
N0["Learning outcomes"]
N1["15.1 Dependencies"]
N2["15.2 Separate auth"]
N3["15.3 NMT's side"]
N4["15.4 Responsibility matrix"]
N5["15.5 Breaks"]
N6["15.6 Contracts"]
N7["15.7 Callback authenticity"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX057"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["15.1 Dependencies"]
N2["15.2 Separate auth"]
N3["15.3 NMT's side"]
N4["15.4 Responsibility matrix"]
N5["15.5 Breaks"]
N6["15.6 Contracts"]
N7["15.7 Callback authenticity"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX057"]
[Learning outcomes]
|
v
[15.1 Dependencies]
|
v
[15.2 Separate auth]
|
v
[15.3 NMT's side]
|
v
[15.4 Responsibility matrix]
|
v
[15.5 Breaks]
|
v
[15.6 Contracts]
|
v
[15.7 Callback authenticity]
|
v
[Worked example] --> [Exercise EX057]
Learning outcomes
You will (1) map third-party dependencies; (2) know when their testing needs separate auth; (3) test NMT's side of integrations; (4) record shared responsibility.
15.1 Dependencies
Map tiles, SMS notifier, payment deep links, cloud email.
Dependencies also include map-tile CDNs and identity providers, and Sam lists them so ENG-512 does not report a CDN timeout as a finding against NMT's API. He compares each timeout with the ENG-512 activity times before deciding where it belongs, and keeps that comparison beside the CDN ticket. The SMS notifier and payment deep links get the same treatment, because their failures appear inside NMT's rider screens. Sam records an external contact for each dependency where one is known, so a ticket can go straight to the party that can fix it.
15.2 Separate auth
Testing the SMS vendor's core needs the vendor's authorization.
In the same way, NMT's signature never authorizes a fare processor's systems; those processors need their own written authorization. Sam records such third parties as explicit exclusions in the scope table, and each exclusion row quotes the contract clause id next to the processor's name. An explicit row prevents later argument about whether a vendor endpoint was implicitly covered just because NMT traffic happens to reach it. When a vendor wants its own systems tested, it arranges that authorization directly with its own security team.
15.3 NMT's side
Sam can test how NMT handles vendor callbacks and secrets storage when those paths are in scope.
NMT's side of a dependency finding is the configuration NMT controls: redirects, API keys stored at NMT and WAF rules. Sam's tickets target those items, because NMT's owners can change them. Vendor patch schedules are recorded as notes in the finding, but they are not Sam's tickets and Sam does not own them. This keeps each remediation item assigned to someone who actually has the authority and access to make the fix.
15.4 Responsibility matrix
Who patches what is written down so findings land on the right owner.
The responsibility matrix names an NMT owner and a vendor owner for every dependency. Each dependency ticket must fill both columns before review accepts it. When either owner cell is empty, the triage bot comments that the matrix is needed, and the ticket returns to the reporter before anyone assigns work. The split prevents findings from bouncing between NMT and a vendor while both sides assume the other is responsible for fixing them.
15.5 Breaks
Vendor outages during tests are stops, not opportunities to try harder.
When a CDN path breaks during ENG-512, Sam does not claim causation until the break has been correlated with the engagement times. The ENG clock brackets are pasted into the CDN incident notes, and the claim waits for clock-aligned SOC notice that matches the window. Synchronised clocks and prior SOC notice protect both sides from false blame, whether the test caused the outage or merely happened to run while it began.
15.6 Contracts
Security contact clauses in vendor contracts speed responsible disclosure.
Contracts may also forbid testing vendor systems, so Sam reads the relevant clause before proposing any vendor-facing check. Forbid-test clauses are pasted into the ROE exclusion list, and legal review initials appear beside each pasted clause in the appendix. Without those initials the paste is treated as incomplete ROE text, because a misread clause could commit NMT to testing that the vendor contract does not allow. Any doubt about a clause goes back to legal before the proposal is drafted at all.
15.7 Callback authenticity
When testing NMT's handling of vendor callbacks, Sam uses documented test harnesses, not forged traffic to production payment endpoints.
Callback authenticity for vendor webhooks is verified with staging secrets only, never production secrets. Sam's tests never replay live rider callbacks, not even for a demonstration. The staging secret IDs used in each webhook test are listed in the evidence index, so a reviewer can confirm which credentials were exercised and that no production secret or rider data entered the test at any point.
15.8 Secret scanning scope
Secret scans run on NMT-owned repos listed in the ROE, not on every public fork on the Internet.
Secret scanning scope stays inside the NMT repositories authorized for ENG-512, and the scope text names repository paths rather than the whole internet. Scanning a vendor's public GitHub without written leave is out of scope, however tempting a quick search may be. The path allow list for the scanners is reviewed whenever new NMT repositories appear, so coverage grows only through a recorded scope decision.
15.9 Field discipline
Sam's dependency map includes a "data shared" column: what NMT sends to each vendor. If NMT should not send rider phone numbers to the map tile provider, that becomes both a privacy control and a test check: inspect outbound requests for unexpected fields during authorized staging tests.
Field discipline for dependencies is matrix, separate auth, NMT-side fixes first. Fare vendors stay out of ordinary probes. The data-shared column ties these together, because it shows which vendor flows NMT can test on its own side and which belong to the vendor.
15.10 Closing note
If a vendor asks Sam to "just quickly test" their portal using NMT credentials, he refuses and points them to their own authorization process. NMT credentials do not travel.
The dependency chapter ends where the scope table does: by stating plainly which vendor systems NMT did not authorize for testing. Sam repeats that list in the report, so readers do not assume fare-processor coverage that Northline Municipal Transit never purchased. The same list goes into the handover note, so the next technician inherits the exclusions along with the findings.
Worked example (synthetic NMT)
Sam finds an SMS API key in a staging repo. That is an NMT finding (secret storage). He does not load-test the SMS vendor.
Synthetic case — Northline Municipal Transit (NMT). The transit agency, Sam Park and all figures are invented for teaching.
Errors and limits
Live transit systems and fare equipment are never tested without a separate, specialised authorization. This book uses synthetic data only and grants no authority to test real systems.
Exercises
- EX057 — Separate auth example. Give one dependency Sam must not test without vendor auth. Rubric: 3 = SMS vendor / map tiles / payment; 2 = partial; 1 = NMT website; 0 = none.
- EX058 — NMT-side finding. Why is a leaked SMS API key in NMT staging an NMT finding? Rubric: 3 = NMT stores/handles the secret; 2 = partial; 1 = vendor only; 0 = none.
- EX059 — Vendor outage. Vendor times out during the window. What does Sam do? Rubric: 3 = stop related checks; note dependency; do not hammer; 2 = partial; 1 = retry storm; 0 = none.
- EX060 — Matrix. What does a responsibility matrix solve? Rubric: 3 = right owner for each finding; 2 = partial; 1 = vague; 0 = none.
Synthesis
Know the dependency map; test NMT's side; do not attack vendors without their authorization.
Continue studying — chapter 15 of 18
← Chapter 14 (draft) · Course chapter index · Chapter 16 (draft) →