Triage, tooling, and an SBOM request across 1,150 repositories
Verdant Retail's OSPO tracks 1,150 repositories. Its SBOM pipeline covers 60% of production services; the rest were onboarded before the pipeline existed. Last quarter the SCA scanner opened 3,400 findings. Manual review showed 38 were reachable and exploitable in production, about 900 were in build- or test-only dependencies, and the remainder were unreachable code paths, duplicate findings, or false positives. The OSPO has 2.5 FTE and no formal response SLA. A large customer has sent a 40-question vendor questionnaire requesting a CycloneDX SBOM for the product, a documented critical-vulnerability response time, and the maintenance status of the top 20 dependencies. The VP of Engineering asks whether to buy a commercial SCA platform at $180,000 a year or add a third engineer at roughly $160,000 loaded cost, and wants an answer in a week.
1. Diagnose why the program produces 3,400 findings and design a triage model the 2.5 FTE team can run.
Read the worked answer
The 3,400 number measures scanner output, not risk, and the program is organized around the wrong metric.
- No scope filtering: build- and test-only dependencies (~900) were queued with production findings. They matter, but not at the same priority.
- No deduplication: the same vulnerable component version recurs across repositories. A component-based rollup cuts the count sharply.
- No reachability or exploitability context: CVSS alone over-prioritizes findings that cannot be triggered.
- No SLA or owner, so findings accumulate instead of closing.
Triage model: rank by (1) runtime versus build/test, (2) reachable code path, (3) exploitability evidence such as known exploitation or a public exploit, (4) exposure: internet-facing or regulated data, (5) compensating controls such as network isolation. Route tier 1 to a 7-day fix SLA with a named owner per service; tier 2 to 30 days; tier 3 to a quarterly backlog; build-only findings to a separate pipeline with a 90-day target. Deduplicate by component and version and track remediation at component level. Report 'open reachable criticals' to the VP rather than raw finding counts, and keep an exceptions register with expiry dates so accepted risk is visible instead of silently aging out.
2. The VP wants a buy-or-hire answer within a week. What recommendation follows from the setup, and on what criteria?
Read the worked answer
Frame it as capability gaps, not a binary.
- What the tool buys: reachability analysis, deduplication, CycloneDX generation at scale, policy-as-code, and auditor-ready reports. That directly addresses the noise, the coverage gap, and the questionnaire. It does not decide whether a dependency is maintained and it does not write remediation patches.
- What the engineer buys: triage judgement, maintainer outreach, exception decisions, and onboarding the legacy 40%. It does not scale to 1,150 repositories alone, and 2.5 FTE is already behind.
Recommendation with conditions: buy, but only after a two-week proof of concept on 50 repositories, scored on (a) reachability accuracy against the 38 known-exploitable cases, (b) CycloneDX output validating against the customer's required schema, (c) deduplication ratio, (d) effort to onboard the legacy 40% without per-repo manual work, (e) total cost including integration and training. If the PoC does not reduce actionable findings by an order of magnitude, the tool is a reporting layer and the money is better spent on the engineer plus open-source tooling.
Avoid the either/or: the realistic answer is a tool at a negotiated price plus a third engineer, funded by moving manual triage hours to remediation. Answer within the week with the PoC plan and the decision criteria, not a preference.
3. How should the OSPO answer the customer's three requests, and what should it commit to internally on SLA and coverage?
Read the worked answer
Answer the three requests concretely and be honest about coverage.
- CycloneDX SBOM: deliver a machine-readable CycloneDX SBOM for the specific product, not the whole estate, with component versions, hashes, and dependency relationships. If that product's coverage is complete, say so; if not, list excluded components and the date they will be included. Do not relabel a scanner export as an SBOM.
- Critical response time: publish an SLA the team can meet. For example: acknowledge a critical in a runtime component within 2 business days, provide a remediation plan or mitigation within 7 days, and patch or document compensating controls within 30 days. Define 'critical' by exploitability and exposure in the product rather than by scanner severity alone, and state the exception process.
- Top-20 dependency status: report last release, commit activity, number of employers behind recent commits, open critical issues, security-response history, and whether Verdant holds a fork and exit plan. This is a governance answer, not a license answer.
Internal follow-through: formalize the SLA in policy; onboard the remaining 40% of services in quarterly waves starting with internet-facing and regulated-data services; track SBOM coverage percentage and critical time-to-remediate as program metrics. Customer questionnaires then become an export of existing records rather than a fire drill.