Chapter 13 — Application and software supply chain security: troubleshooting
Lesson map
Lesson 13 published. Map, example, EX049.
flowchart TD
N0["Learning outcomes"]
N1["13.1 Typical problems"]
N2["13.2 Method"]
N3["13.3 Rolling back"]
N4["13.4 Not weakening controls"]
N5["13.5 Vendor republishing"]
N6["13.6 Notes"]
N7["Test copies"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX049"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["13.1 Typical problems"]
N2["13.2 Method"]
N3["13.3 Rolling back"]
N4["13.4 Not weakening controls"]
N5["13.5 Vendor republishing"]
N6["13.6 Notes"]
N7["Test copies"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX049"]
[Learning outcomes]
|
v
[13.1 Typical problems]
|
v
[13.2 Method]
|
v
[13.3 Rolling back]
|
v
[13.4 Not weakening controls]
|
v
[13.5 Vendor republishing]
|
v
[13.6 Notes]
|
v
[Test copies]
|
v
[Worked example] --> [Exercise EX049]
Learning outcomes
You will (1) diagnose problems after plugin updates and control changes; (2) roll back safely; (3) find root causes; (4) keep notes.
13.1 Typical problems
After updates: pages break, layouts change, error rates rise. After control changes: a new Content-Security-Policy blocks a legitimate widget, the hash step rejects a file because the vendor republished a release, or the permission fix stops a legitimate cache folder from working. Each of these problems has appeared in the course: the appointment widget at alder-dental, the vendor republishing case, and the contact-form update that broke a form. Knowing these typical cases helps Tomás recognise a familiar pattern quickly.
13.2 Method
Tomás reads the error, checks what changed most recently, reproduces it on a test copy of the site with synthetic data, and changes one thing at a time. This method found the alder-dental fault: the most recent change was the contact-form update, and the test copy showed the new version needed a renamed setting. Changing one thing at a time on the test copy shows which change fixed the fault, so the live fix can be applied once and correctly.
13.3 Rolling back
Every update has a backup. If a customer's site is broken, rollback restores service first; diagnosis continues on the test copy. At alder-dental, Tomás rolled back the contact-form update within ten minutes, so the customer's form worked again while he diagnosed. The backup taken before every update is what makes this possible. Rollback is a service decision, not a fix, which is why a deadline to fix forward follows it. The rollback is recorded in the ticket with the time it was performed.
13.4 Not weakening controls
Rolling back an update is acceptable; turning off a control to make an error disappear is not. If a control must change, the change is reviewed. Turning off a Content-Security-Policy to make a widget work would remove protection against changed components on that site. The right response is to find the legitimate domain, as with alder-dental's appointment widget, and add it after review. Any reviewed change to a control is recorded with its reason, so an exception never happens silently.
13.5 Vendor republishing
When a vendor's hash changes, support asks the vendor through an official channel why before installing. A changed hash may have an innocent explanation, such as a vendor rebuilding a release, but it may also mean a compromised publisher. Asking through the vendor's official channel, not the mirror or a forum, gets an answer Pinecrest can trust. Until then, the file is treated like the Ferncroft mirror copy and not installed. The vendor's answer is saved in the ticket with the new hash.
13.6 Notes
Each fix is recorded with symptom, cause and fix in the support knowledge base. The alder-dental note records the symptom, a broken contact form after the update, the cause, a renamed setting, and the fix. The next technician who sees the same symptom on another site can apply the fix in minutes. Notes also show recurring causes that may justify a procedure change. Grace reviews the new knowledge-base notes every week so that wrong fixes are corrected before others copy them.
Test copies
Each customer site can be copied to a private test area with customer data replaced by synthetic records. Problems are reproduced there so that diagnosis never risks the live shop or its customers' details.
Deadlines after rollback
A rollback to a version with a known advisory gets a ticket with a fix-forward deadline.
Worked example
A contact-form update breaks alder-dental's form. Tomás rolls back within ten minutes, reproduces the problem on a test copy, and finds the new version requires a setting renamed. He applies the update with the setting on the test copy, then on the live site, and writes a knowledge-base note.
Synthetic case. Problems are synthetic.
Errors and limits
Rolling back to a vulnerable version is temporary; set a deadline to fix forward.
Exercises
- EX049 — Method. What is Tomás's method? Rubric: 3 = read, check recent change, reproduce, one change; 2 = three; 1 = one; 0 = none.
- EX050 — Rollback rule. What comes first when a site is broken? Rubric: 3 = restore service by rollback; 2 = partial; 1 = vague; 0 = none.
- EX051 — Republished hash. What happens when a vendor's hash changes? Rubric: 3 = ask vendor officially first; 2 = partial; 1 = vague; 0 = none.
- EX052 — Alder fix. What fixed the alder-dental form? Rubric: 3 = renamed setting applied; 2 = partial; 1 = vague; 0 = none.
Synthesis
Restore service, diagnose safely and keep controls on.
Continue studying — chapter 13 of 18
← Chapter 12 (draft) · Course chapter index · Chapter 14 (draft) →