Chapter 34 — Application and software supply chain security: integration
Lesson map
Lesson 34 published. Map, example, EX100.
flowchart TD
N0["Learning outcomes"]
N1["34.1 One workflow"]
N2["34.2 Aligning teams"]
N3["34.3 Avoiding duplication"]
N4["34.4 Developer experience"]
N5["34.5 Integration testing"]
N6["34.6 SAMM view"]
N7["Documentation"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX100"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["34.1 One workflow"]
N2["34.2 Aligning teams"]
N3["34.3 Avoiding duplication"]
N4["34.4 Developer experience"]
N5["34.5 Integration testing"]
N6["34.6 SAMM view"]
N7["Documentation"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX100"]
[Learning outcomes]
|
v
[34.1 One workflow]
|
v
[34.2 Aligning teams]
|
v
[34.3 Avoiding duplication]
|
v
[34.4 Developer experience]
|
v
[34.5 Integration testing]
|
v
[34.6 SAMM view]
|
v
[Documentation]
|
v
[Worked example] --> [Exercise EX100]
Learning outcomes
You will (1) integrate application security and supply-chain controls into one workflow; (2) align teams and tools; (3) avoid duplicated or conflicting checks; (4) manage the developer experience.
34.1 One workflow
Developers see one pipeline: tests, static analysis, dependency gate, build with provenance, signing, staging deploy with verification, production deploy with verification. Results appear in one place in the pull request.
Before integration, developers checked several dashboards and often missed a failing scanner because it reported somewhere they rarely looked. A single sequence, shown in the pull request, means every result is seen at the moment a decision is made about merging. The order also matters: cheap checks run first, so a simple test failure is reported before slower steps start, and signing happens only for builds that passed everything earlier in the line.
34.2 Aligning teams
The security team writes policies; the platform team runs the pipeline; product teams own fixes. A weekly meeting resolves conflicts.
Clear roles stop each team assuming another handles a problem. The security team decides what the rules are, but does not run the CI servers; the platform team keeps the pipeline healthy, but does not decide which advisories matter; product teams fix their own code, since they know it best. Conflicts, such as a policy that slows a team's releases, are raised in the weekly meeting, where the people who can change each part are present. Decisions are written down so the same argument does not repeat.
34.3 Avoiding duplication
Two tools both scanned dependencies with different advisory data, producing contradictory results. The team keeps one as the gate and uses the other only for comparison reports.
Contradictory results waste time and erode trust: developers asked which tool to believe, and some ignored both. Choosing one gate gives a single answer for merging. Comparison reports from the second tool still catch advisories the first missed, and any difference is investigated by the security team rather than left for each developer to puzzle over.
34.4 Developer experience
Messages explain what failed, why it matters and how to fix it, with links. Median CI time is kept under 12 minutes.
A message such as 'blocked: ADV-101 affects tmpl 2.0.9, upgrade to 2.0.10, see guide' lets a developer fix the problem in minutes. A bare 'policy violation' sends them to ask in chat. Keeping CI time down matters for the same reason: when builds take too long, people batch changes, which makes review harder and each failure more confusing to diagnose. Links point to the developer guide.
34.5 Integration testing
Changes to any control are tested in a staging copy of the pipeline before rollout.
The pipeline is software, and changes to it can break every later build or, worse, silently stop a check from running. A staging copy with the same configuration lets the platform team try a change against sample repositories, including ones designed to fail each check. Only when the expected failures still occur is the change rolled out. The end-to-end deployment test with flawed artifacts is part of this suite.
34.6 SAMM view
OWASP SAMM v2 (2020) maturity assessment shows Coastline rising in Implementation (secure build, secure deployment) and Verification after integration.
SAMM groups practices into business functions, each assessed for maturity. Using it shows progress in a form leadership recognises and highlights functions that lag, such as governance or operations. Coastline repeats the assessment yearly, using the same assessors where possible, so changes reflect real improvement rather than differences in how the questions were interpreted. The score is a guide for where to invest next, not a goal in itself.
Documentation
A single developer guide explains every pipeline check, what it protects against and how to fix common failures. The guide is versioned with the pipeline configuration, so it always matches the checks in force. New developers read it in their first week, and the platform team updates it whenever a check changes.
Metrics for the pipeline
The platform team tracks CI duration, failure causes and flaky tests. Flaky tests are fixed or removed within a week, since they teach developers to ignore failures.
Worked example
A developer survey after integration shows 78% find failure messages clear, up from 41%, and the number of "how do I fix this" questions in chat halves.
Synthetic case. Survey figures are synthetic.
Errors and limits
Integration concentrates risk: one pipeline misconfiguration affects all checks; protect pipeline configuration.
Exercises
- EX100 — Team roles. Who owns policies, pipeline and fixes? Rubric: 3 = security, platform, product teams; 2 = two; 1 = one; 0 = none.
- EX101 — Duplication fix. How was scanner duplication resolved? Rubric: 3 = one gate, other comparison only; 2 = partial; 1 = vague; 0 = none.
- EX102 — Survey result. What did the survey show? Rubric: 3 = 78% clear vs 41%; questions halved; 2 = partial; 1 = vague; 0 = none.
Synthesis
Integrate checks into one clear workflow owned by aligned teams.
Continue studying — chapter 34 of 50
← Chapter 33 (draft) · Course chapter index · Chapter 35 (draft) →