Secure development lifecycle and DevSecOps
Decide which security activities belong in the delivery pipeline and which need human judgement
Security work is bolted onto releases late, or pipeline scanning produces findings nobody triages. The decision is which security activities belong in the delivery pipeline and which need human judgement. The work starts from where a security activity changes a decision, and where it only produces an unread artefact and ends with a secure development lifecycle design with placed controls, ownership and exception handling. It is most relevant to engineering leaders and platform teams. A useful result states what was examined, what remains uncertain and which decision the evidence can support.
Decide which security activities belong in the delivery pipeline and which need human judgement
- Delivery path
The starting condition this work depends on.
- Control placement
Where the consequence actually arises.
- Finding ownership
The finding and its open dependencies.
Decision
Frame the decision before scoping the work
Questions and the evidence each one needs
- Delivery path
- Inspect the current branching and release process.
- Control placement
- Inspect pipeline configuration and existing scanners.
- Finding ownership
- Inspect the finding backlog and its ownership.
The decision is which security activities belong in the delivery pipeline and which need human judgement. This matters to engineering leaders and platform teams when security work is bolted onto releases late, or pipeline scanning produces findings nobody triages. Name the affected product, the consequence of a wrong decision and the owner who can act. The opening conversation should establish which evidence already exists and which uncertainty is material enough to investigate.
The specific failure hypothesis is that a scanner runs on every build while nobody owns the findings it produces. It stays a hypothesis until it is examined in your own case. Existing design records, tests or operating evidence may already resolve it, so identify the uncovered question before commissioning further work.
Mechanism
Follow the relationship that carries the consequence
Where the boundary is actually crossed
- Delivery path
- The condition the design assumes.
- Control placement
- Where authority or information changes hands.
- Finding ownership
- The effect the owner must answer for.
What this specialty examines
Secure development lifecycle and DevSecOps rests on where a security activity changes a decision, and where it only produces an unread artefact. Work from the configuration that will actually ship rather than from the reference design, and record where the two differ.
The examination draws on the current branching and release process; pipeline configuration and existing scanners; and the finding backlog and its ownership. Identify the owner, revision and operating context of each source. Keep an incomplete input visible, with an explanation of what its absence prevents the owner from concluding, rather than quietly treating a gap as a satisfactory result.
The tradeoff to make explicit
The tradeoff here is a blocking gate that slows delivery against a warning that everyone learns to ignore. Compare the available options against the same intended outcome. If one option removes a control or moves a boundary, describe that difference before treating its lower effort as an improvement. The decision should expose the tradeoff rather than bury it in a single rating.
Preparation
Connect the inputs to the boundary examined
Preparation record for the engagement
Illustrative working format
- The current branching and release process
- Bounds the context.
- Pipeline configuration and existing scanners
- Supplies the material examined.
- The finding backlog and its ownership
- Exposes conditions that qualify a result.
Start with the current branching and release process; pipeline configuration and existing scanners; and the finding backlog and its ownership. Each has a different job: the first establishes context, the second supplies the material to examine, and the third exposes operating conditions that may qualify a conclusion. Sanitised examples can support early work, provided the differences from the real configuration stay explicit.
The scope also needs engineering leaders and platform teams with the authority to inspect the relevant boundary, and agreement on what evidence would distinguish the failure in which a scanner runs on every build while nobody owns the findings it produces from acceptable behaviour. Where stakeholders disagree about intended behaviour, resolve that interpretation before classifying an observed difference as a defect.
Working sequence
Carry the question through to an accountable finding
From scoped material to a decision record
- Map the delivery path
Set the conditions assumed.
- Place the checks deliberately
Apply the scoped check.
- Define triage and ownership
Record evidence and the next decision.
Map the delivery path
Follow a change from commit to production, recording every existing check, approval and manual step, with the person who acts on each result. Record what is deliberately excluded.
Place the checks deliberately
Decide which checks block, which inform, which run on a schedule, and which require a reviewer with specific expertise. Keep an unreproducible observation in the record with its reason.
Define triage and ownership
Agree severity criteria, response expectations, exception handling and the record that shows a finding was resolved rather than muted. Hand the result over with its open dependencies attached.
Indicative artefact
Make the artefact usable by the person who owns the decision
A secure development lifecycle design with placed controls, ownership and exception handling
Illustrative working format
- The delivery path with existing and proposed checks
- What was examined, and under which assumptions.
- Blocking, informing and scheduled control decisions
- Each observation, linked to evidence.
- Triage severities, owners and exception routes
- The next decision, and its limits.
The proposed decision artefact is a secure development lifecycle design with placed controls, ownership and exception handling. Depending on the agreed scope, the pack may include:
-
The delivery path with existing and proposed checks. Basis: the definitions, boundaries and assumptions another reviewer would need.
-
Blocking, informing and scheduled control decisions. Observation: the findings and their interpretation, preserving adverse results and disagreement.
-
Triage severities, owners and exception routes. Decision: what the owner could do next, and what change would justify revisiting it.
Retain the selection rationale beside the result. Without it, a bounded finding is easily mistaken for complete coverage.
Illustrative scenario
Examine the question through a constructed case
A constructed case and its decision paths
Illustrative scenario
- Delivery path
A team enables dependency scanning across every repository and accumulates several thousand open findings.
- Control placement
Which findings are reachable in a deployed configuration, and who is accountable for each?
- Finding ownership
Narrow the blocking rule to reachable, exploitable classes and route the remainder to scheduled review.
Consider an illustrative situation: a team enables dependency scanning across every repository and accumulates several thousand open findings. The example is constructed to show how the question is framed. No client engagement, executed test or measured improvement is implied.
The question to examine is which findings are reachable in a deployed configuration, and who is accountable for each. A reasonable next action would be to narrow the blocking rule to reachable, exploitable classes and route the remainder to scheduled review. The decision record should state which configuration was accepted and which limitations came with it.
Scope and next action
Keep the conclusion inside the agreed boundary
Confirm fit before the next commitment
- Delivery path
- Limited to the agreed scope and configuration.
- The current branching and release process
- The owner confirms access and conditions.
- Finding ownership
- A lifecycle design describes intended practice. Evidence that it operates comes from release records, not from the design document.
A lifecycle design describes intended practice. Evidence that it operates comes from release records, not from the design document. Any engagement depends on an agreed scope, a qualified team and authorised access.
Bring the affected product or workflow, its current configuration and the evidence you already hold. The scope question follows from the situation in which security work is bolted onto releases late, or pipeline scanning produces findings nobody triages. Confirm which missing observation would change the owner’s next action.