Chapter 12 — Practice portfolio and final review | Professional Application and software supply chain security

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 12 — Practice portfolio and final review

Lesson map

Lesson 12 published. Map, example, EX056.

flowchart TD
  N0["Learning outcomes"]
  N1["12.1 Portfolio contents"]
  N2["12.2 Mapping"]
  N3["12.3 Outcomes"]
  N4["12.5 Reflection"]
  N5["12.6 Development plan"]
  N6["Assessor feedback"]
  N7["Keeping the portfolio"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX056"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["12.1 Portfolio contents"]
  N2["12.2 Mapping"]
  N3["12.3 Outcomes"]
  N4["12.5 Reflection"]
  N5["12.6 Development plan"]
  N6["Assessor feedback"]
  N7["Keeping the portfolio"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX056"]

[Learning outcomes]
    |
    v
[12.1 Portfolio contents]
    |
    v
[12.2 Mapping]
    |
    v
[12.3 Outcomes]
    |
    v
[12.5 Reflection]
    |
    v
[12.6 Development plan]
    |
    v
[Assessor feedback]
    |
    v
[Keeping the portfolio]
    |
    v
[Worked example] --> [Exercise EX056]

Learning outcomes

You will (1) assemble a portfolio of practice evidence; (2) map it to frameworks; (3) reflect on growth; (4) plan continued development.

12.1 Portfolio contents

The hl-auth finding and its resolution; the dependency source review; the triage format adopted by TrackPort; the workflow and its metrics; the case analysis; the private disclosure; the supervised lab report. Each item shows a different competence: the hl-auth finding shows investigation and communication; the source review shows method; the triage format shows working with developers; the workflow and metrics show sustained improvement; the case analysis shows judgement; the private disclosure shows ethics; and the lab report shows independent work. Priya arranges the items in the order the work happened, each with its date and a pointer to the ticket, log or test result behind it.

12.2 Mapping

Priya maps each item to SSDF practice groups and to OWASP SAMM v2 practices such as Threat Assessment, Security Requirements, Secure Build and Defect Management, showing where Harbourline's maturity rose. Mapping to recognised practices lets assessors and Harbourline compare her work with an external standard. SAMM practices show where maturity rose, such as Secure Build after the source controls and Defect Management after the workflow. Priya includes the evidence for each mapping, so assessors can judge the claim rather than accept it.

12.3 Outcomes

Internal names can no longer resolve publicly; criticals are fixed on time; findings arrive checked and ranked; releases carry provenance. Each outcome is supported by evidence in the portfolio: the weekly tests show internal names cannot resolve publicly, the next quarter's tickets show criticals fixed on time, the TrackPort team's tickets show findings arriving checked and ranked, and the deployment system's records show releases carry provenance. Priya states each outcome only as far as the evidence supports. Marcus checks each outcome against the evidence before the portfolio goes to the assessor, and notes the weekly test log as the strongest item.

12.4 Limits

Coverage is TrackPort and the shared build service; other teams have not yet adopted the triage workflow; reachability is judged manually. These limits show where further work is needed. Other teams use the shared build service but not the triage workflow, so their findings may still arrive unchecked. Manual reachability judgements depend on Priya's reading of the code. She records each limit in her portfolio, so assessors and Marcus can see what the project did not cover. Marcus agrees with her list and adds that the next teams to adopt the workflow should be chosen with their leads' agreement.

12.5 Reflection

Priya writes that her quality-engineering habits, careful reproduction and clear evidence, transferred directly to security work. Careful reproduction helped her confirm the hl-auth finding and check each scanner result before sending it to developers. Clear evidence made her tickets easy to act on. She also notes what was new: judging risk, deciding priorities and writing for managers. Marcus agrees and adds that her careful approach made the platform team trust her findings quickly. In her new role for the logistics product group, she plans to keep both habits by reproducing every finding before raising a ticket.

12.6 Development plan

Next: threat modelling with Shostack's (2014) four questions for new TrackPort features, and extending the workflow to two more teams. Threat modelling would help the team find risks in new features before they are built, which complements finding issues in dependencies and code. Shostack's four questions are simple enough for developers to use in planning meetings. Extending the workflow to two more teams tests whether it works beyond TrackPort. Marcus agrees to review progress after three months. The plan is filed with her portfolio, with dates for the threat-modelling sessions and the first meeting with each of the two new teams.

Assessor feedback

The assessor praises the disclosure handling and the measured improvements, and suggests adding a short threat model to the portfolio's next revision. Marcus adds that the triage format had the biggest effect, since it changed how developers saw security findings. Priya records both points and sets dates for each item in her plan. She also offers to present the course work to other teams, which spreads the triage format and the internal-prefix rule beyond TrackPort and gives her practice explaining security to new audiences.

Keeping the portfolio

The portfolio is kept current after the course as a living record.

Worked example

Marcus and the course assessor review the portfolio. It passes, and Harbourline appoints Priya as application security engineer for the logistics product group.

Synthetic case. People and outcomes are synthetic.

Errors and limits

A portfolio shows what was done; reviewers also look for honest limits.

Exercises

EX056 — Contents. Name four portfolio items. Rubric: 3 = finding, review, triage, workflow, case, disclosure, lab; 2 = three; 1 = one; 0 = none.
EX057 — SAMM practices. Which SAMM practices were mapped? Rubric: 3 = threat assessment, requirements, secure build, defect management; 2 = two; 1 = one; 0 = none.
EX058 — Outcomes. State two outcomes. Rubric: 3 = no public internal names; criticals on time; ranked findings; provenance; 2 = one; 1 = vague; 0 = none.
EX059 — Limits. Name a limit. Rubric: 3 = only TrackPort; manual reachability; 2 = partial; 1 = vague; 0 = none.
EX060 — Next step. What is Priya's next development step? Rubric: 3 = threat modelling; extend to more teams; 2 = partial; 1 = vague; 0 = none.

Synthesis

Evidence, mapping and honest limits make a strong portfolio.

Continue studying — chapter 12 of 12

← Chapter 11 (draft) · Course chapter index · Worked results ↓ · Next course via chapter index →