◇ OpenCyber Academy
Professional · Chapter 6 · English

Chapter 6 — Application and software supply chain security: operational workflow

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 6 — Application and software supply chain security: operational workflow

Lesson map

Lesson 06 published. Map, example, EX026.

flowchart TD
  N0["Learning outcomes"]
  N1["6.1 The workflow"]
  N2["6.2 Targets"]
  N3["6.3 Ownership"]
  N4["6.4 Tracking"]
  N5["6.5 Escalation"]
  N6["6.6 Exceptions"]
  N7["Weekly review"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX026"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["6.1 The workflow"]
  N2["6.2 Targets"]
  N3["6.3 Ownership"]
  N4["6.4 Tracking"]
  N5["6.5 Escalation"]
  N6["6.6 Exceptions"]
  N7["Weekly review"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX026"]

[Learning outcomes]
    |
    v
[6.1 The workflow]
    |
    v
[6.2 Targets]
    |
    v
[6.3 Ownership]
    |
    v
[6.4 Tracking]
    |
    v
[6.5 Escalation]
    |
    v
[6.6 Exceptions]
    |
    v
[Weekly review]
    |
    v
[Worked example] --> [Exercise EX026]

Learning outcomes

You will (1) design a workflow from finding to fix; (2) assign owners and targets; (3) track progress; (4) escalate fairly.

6.1 The workflow

Scanner or review finding → Priya checks and ranks → ticket in TrackPort's backlog with evidence and suggested fix → developer fixes → reviewer confirms → scanner re-run closes the ticket. Each step has an owner, so a finding cannot stall without someone noticing. Priya checks and ranks, the TrackPort developer fixes, a reviewer confirms the change, and the scanner re-run gives independent confirmation that the finding has gone. A ticket closes only after the re-run, not when the developer marks it done. Ticket dates provide the data for measuring remediation against targets.

6.2 Targets

Remediation targets by severity: critical 7 days, high 30, medium 90. Targets are agreed with the product manager so they compete fairly with features. Agreeing targets with the product manager makes them part of planning rather than a demand from security. A critical finding needs a fix within a week, which may displace feature work, so the product manager must accept that trade-off in advance. Priya measures each finding against its target from the ticket dates. The targets are reviewed each quarter. Each ticket shows its target date from creation, so developers can plan around it without asking security.

6.3 Ownership

Each ticket has one owner. Platform issues go to the platform team, application issues to TrackPort. One owner means one person is responsible for moving the ticket forward. Platform issues, such as registry settings, go to the platform team because only they can change the build service. When an owner moves teams, the ticket must be reassigned, as the late medium finding later showed. Priya checks the weekly view for tickets without an active owner. A ticket left without an active owner is reassigned within a day, which is the fix for the medium finding that was forgotten when its owner moved teams.

6.4 Tracking

A weekly view shows open findings by age and severity. The view shows Priya and the TrackPort lead which findings are approaching their target and which have passed it. Sorting by age makes old findings visible before they are forgotten. They review it in a short meeting each week, and any finding near its target is discussed so that blocked work can be raised early. The same data feeds the remediation measures Priya reports each quarter. Marcus sees the same view at month end, so he can spot findings that need his authority, such as a risk acceptance for the product manager.

6.5 Escalation

Findings past their target are discussed with the lead; repeated misses go to the product manager with the risk explained. Escalation is a way to make a decision visible, not a punishment. A finding past its target may be blocked for good reasons, such as a framework upgrade. Discussing it with the lead first gives the team a chance to explain and plan. If targets keep being missed, the product manager decides whether to change priorities or accept the risk, with the risk explained in plain terms.

6.6 Exceptions

If a fix is not possible in time, a risk acceptance records the reason, compensating controls and a new date, signed by the product manager. A risk acceptance turns a missed target into a recorded decision. In the first month, one high finding needed a major framework upgrade, so Priya and the lead recorded an acceptance with a compensating input check and a date tied to the planned upgrade. The product manager's signature shows who accepted the risk. Each acceptance is reviewed on its date, and Priya tracks it in the weekly view.

Weekly review

Each week Priya and the TrackPort lead spend fifteen minutes on the open-findings view: what closed, what is nearing its target and what is blocked. Blocked items get a decision in the meeting, either help from another team or a risk acceptance. The short regular meeting prevents surprises at the end of the quarter. Over three months, the number of findings past target falls from nine to two, and both have signed risk acceptances. The lead remarks that the meeting saves time, because questions are answered in one place instead of across many messages.

Worked example

In the first month, one high finding is blocked because the fix needs a major framework upgrade. Instead of letting it age quietly, Priya and the lead record a risk acceptance with a compensating input check and a date tied to the planned upgrade.

Synthetic case. Workflow and events are synthetic.

Errors and limits

Targets without tracking are ignored; tracking without fair escalation creates resentment.

Exercises

Synthesis

A clear workflow turns findings into tracked fixes.

Continue studying — chapter 06 of 12

← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →