Strategic Considerations - Value Stream, Maturity, Metrics, and Supply Chain
What this domain covers
The strategic domain tests planning rather than doing: how to sequence adoption, where security work actually waits, how to measure progress honestly, how to choose and integrate tooling, and how to manage supply chain and cloud risk at program level. Questions often present an organization with many applications and few security engineers.
Core planning concepts
- Value stream mapping exposes wait states introduced by security: pen-test queues, exception approvals, architecture board calendars, ticket handoffs. Removing a queue often beats buying a tool.
- Risk-based targeting: classify applications by data sensitivity, exposure and business criticality, then apply controls proportionally. Not every repository deserves the same gate.
- Maturity models give a baseline and a target. OWASP SAMM covers governance, design, implementation, verification and operations across maturity levels; BSIMM measures observed software security initiatives. Use them to sequence, not to score vanity.
- DORA's four keys (lead time for changes, deployment frequency, change failure rate, time to restore) are delivery metrics. Security work must not degrade them; they are not security metrics in themselves.
- Toolchain strategy: integrate into the CI/CD and source control developers already use, return results where the work happens, and avoid standing up a new portal nobody visits.
- Build versus buy: buy commodity scanning; build threat modeling, architecture review and business-logic assurance.
- Supply chain: generate SBOMs (SPDX or CycloneDX), sign artifacts, verify provenance (SLSA levels, Sigstore), and restrict builds to trusted registries and pinned dependencies.
- Cloud: the shared responsibility model splits controls, but accountability for the workload and its configuration never transfers to the provider.
Worked example
An organization has 400 repositories and six security engineers. A proposal to run full SAST, DAST and manual review on all 400 is rejected. Reasoning: coverage per engineer is impossible and the first failures will be ignored, not fixed. Instead: classify repositories, onboard the top 40 handling sensitive data to SAST, SCA and secret scanning with automated pull-request comments; publish pipeline templates as a paved road so new projects start secure; set a SAMM target per business function; measure remediation time. Coverage grows by automation leverage, not headcount.
Traps that cost marks
- Buying tools before defining ownership and process.
- Chasing universal coverage while critical applications stay unassessed.
- Reporting DORA metrics as proof of security improvement.
- Treating cloud provider certification as covering your configuration.
- Ignoring brownfield legacy in an otherwise greenfield strategy.